Quick Modding Questions Thread

[lfgr]

Why does the game ignore the self.X_SCREEN and self.Y_SCREEN settings?

The X_SCREEN seems to be only used for the title and date labels. Y_SCREEN isn't used at all, at least not in that file (and also nowhere else, as far as I can tell). This is probably leftover code from earlier implementations.
To change the location of the the window, try replacing "screen.centerX(0)" and "screen.centerY(0)" in line 125:

screen.setDimensions(screen.centerX(0), screen.centerY(0), self.W_SCREEN, self.H_SCREEN)

 

[Kjotleik]

To change the location of the the window, try replacing "screen.centerX(0)" and "screen.centerY(0)" in line 125:

screen.setDimensions(screen.centerX(0), screen.centerY(0), self.W_SCREEN, self.H_SCREEN)

YES! SUCCESS!
Thank you, Ifgr!

Spoiler With Ifgr's help it turned out jolly good :

You folks here at the forums are super-helpful towards a Python-noob like me.

I love you all. May you be blessed with a high Happy/Unhappy ratio of days for the rest of your lives!

 

[Elhoim]

Hi!

Does anyone know how to change the background of the tooltip on the lower left side? I saw some people posting pics with it in a darker color, but couldn't find a mod nor how to change it.



I'm quite tech savvy, so I would just need someone to point me to the texture file or xml.

Thanks!

 

[<Nexus>]

The fact that it's fast and is aggressive towards low memory usage and low disk space in savegames is a (well planned) bonus

Does it also mean that we will face MAFs later? Like one can play to the end not only a Large map but an XL too?

 

[Leoreth]

I'm investigating a null pointer exception where this happened:

Spoiler :

The asserts are my addition, if you skip the first one you run into the second one. Any ideas how to further investigate this? Afaik units can only be created from a player object so where can this have possibly come from?

 

[lfgr]

Maybe pUnitNode has been deleted and now points to garbage memory?

 

[Nightinggale]

Maybe edit IDInfo and make eOwner private. Add get/set functions and add FAssert(eOwner < MAX_PLAYERS) to set. That way you will get an assert failure if you try to write an invalid owner. It's also an argument for never using public member data.

Maybe pUnitNode has been deleted and now points to garbage memory?

Wouldn't that result in a crash? After all the memory is presumably no longer allocated and then the game will read unallocated memory, something windows is supposed to kill the application for doing due to security concerns.

Granted it's possible that the memory is freed and then the very same memory is allocated again. That sounds unlikely, but it's not impossible. The question is, can the assert failure be repeated? And if so, will the owner stay the same?

 

[lfgr]

Granted it's possible that the memory is freed and then the very same memory is allocated again. That sounds unlikely, but it's not impossible.

That's what I meant. I don't really know how modern memory allocation works, but something close to the naïve algorithm (take the first unallocated piece of memory of sufficient size) would make this behavior quite frequent, right?

 

[Leoreth]

I don't want to rule that out but that would suggest an even worse problem where invalid units are not removed from a selection group?

Using an assertion to catch that error being made is a good idea, but I am currently dealing with a submitted save file that contains this error, and it is likely that it's already in there. And it seems a rare occurrence because no other crash report ended up with this state.

 

[Nightinggale]

I don't want to rule that out but that would suggest an even worse problem where invalid units are not removed from a selection group?

You can check if you can get iID. Maybe loop players to see which one has a unit of that ID. Looping nodes in the group could also be interesting as in comparing owners. Maybe start by looping the nodes, store owners in a vector and then when it assert triggers you can read the vector.

Using an assertion to catch that error being made is a good idea, but I am currently dealing with a submitted save file that contains this error, and it is likely that it's already in there. And it seems a rare occurrence because no other crash report ended up with this state.

False assumptions results in bugs and they can also prevent locating bugs. Add an assert to IDInfo::read to confirm that the corrupted data is in the savegame. It's likely, but ideally you should know for sure.

If it's rare and not seen in other games, would be be possible that it's a flipped bit in memory? 122 - 64 = 58 meaning those two numbers are just a single bit apart. While rare, it's possible and there is a story about a server, which had corrupted data. It was sent back, fixed, ran for a while and it was fine. It then returned and it went back to corrupting data. It turned out that it corrupted data in RAM while it was in Denver, but not in California and it was due to cosmic radiation being stronger the higher you go(for those who doesn't know it, Denver is in the mountains while tech companies in California is at sea level). ECC memory was invented for a reason.

Yeah I know it's a cheesy explanation (like saying I'm not responsible and won't do anything), but since it's not impossible, then it should be considered if it happened just once and nobody can figure out how to reproduce the issue.

 

[Leoreth]

The flipped bit explanation is intriguing.

 

[PPQ_Purple]

Quick question. I am working on some units using a custom kfm and whilst they work fine in game in the pedia I get nothing. As in this:


Anyone have any ideas what might be causing it? For extra detail the unit and its art are in one folder and the kfm along with a spare nif is in another because multiple units shall share the same kfm.

 

[<Nexus>]

Quick question. I am working on some units using a custom kfm and whilst they work fine in game in the pedia I get nothing. As in this:
View attachment 537675

Anyone have any ideas what might be causing it? For extra detail the unit and its art are in one folder and the kfm along with a spare nif is in another because multiple units shall share the same kfm.

Something is probably wrong with the kfm or the nif file.
Had same problem with the MegaPack and I was totally clueless untill Vokarya pointed to the error and iirc he fixed it too.

 

[PPQ_Purple]

The kfm in question is literally just a Frigate kfm that I've modified by adding one extra bone and some animations. I'll upload the whole thing for you guys to look at.

 

[SaibotLieh]

The kfm in question is literally just a Frigate kfm that I've modified by adding one extra bone and some animations. I'll upload the whole thing for you guys to look at.

The upload misses the texture files, but seems to be working fine otherwise. I used the frigate xml entry and just replaced the <NIF>, <KFM> and <SHADERNIF> lines. All the files were in one folder.

Maybe there is a problem with your xml entry?

 

[PPQ_Purple]

Here is my XML. Maybe you can see something I didn't.

Note that I am keeping the actual kfm in a different folder than my actual model because I intend to share the kfm between several models and want to keep the file size down. But that was newer a problem before as long as I keep a copy of the nif in my kfm folder which I do. And it is what every non custom unit does. The upload I made was of the kfm folder (it has a spare nif in it as presented).

So to duplicate my setup just put that folder as the KFM folder and make a separate folder with just the nif. You will end up with two folders that have a nif and one that has both the nif and kfm.

Also, the Modules/NormalModules thing is because it's a module for RiFE.

        <UnitArtInfo>
            <Type>ART_DEF_UNIT_FRIGATE_KHAZAD</Type>
            <Button>Art/Interface/Buttons/Units/Tradeship.dds</Button>
            <fScale>0.2</fScale>
            <fInterfaceScale>0.5</fInterfaceScale>
            <bActAsLand>0</bActAsLand>
            <bActAsAir>0</bActAsAir>
            <NIF>Modules/NormalModules/PPQ_NAVY/Art/civs/KHAZAD/Units/Ships/Frigate/frigate_split.nif</NIF>
            <KFM>Modules/NormalModules/PPQ_NAVY/Art/animations/Steam_Frigate/Frigate.kfm</KFM>
            <ShadowDef>
                <ShadowNIF>Art/Units/01_UnitShadows/FrigateShadow.nif</ShadowNIF>
                <ShadowAttachNode>BIP Pelvis</ShadowAttachNode>
                <fShadowScale>1</fShadowScale>
            </ShadowDef>
            <iDamageStates>4</iDamageStates>
            <TrailDefinition>
                <Texture>Art/Shared/water_ship_wake.dds</Texture>
                <fWidth>1</fWidth>
                <fLength>180</fLength>
                <fTaper>1</fTaper>
                <fFadeStartTime>0.2</fFadeStartTime>
                <fFadeFalloff>0.35</fFadeFalloff>
            </TrailDefinition>
                <fBattleDistance>0.35</fBattleDistance>
                <fRangedDeathTime>0.31</fRangedDeathTime>
                <bSmoothMove>1</bSmoothMove>
                <fAngleInterpRate>720</fAngleInterpRate>
                <fExchangeAngle>25</fExchangeAngle>
                <bActAsRanged>0</bActAsRanged>
                <TrainSound>AS2D_UNIT_BUILD_UNIT</TrainSound>
            <AudioRunSounds>
                <AudioRunTypeLoop>LOOPSTEP_OCEAN2</AudioRunTypeLoop>
                <AudioRunTypeEnd>ENDSTEP_OCEAN2</AudioRunTypeEnd>
            </AudioRunSounds>
            <SelectionSound>AS3D_UN_OCEAN_END1</SelectionSound>
            <ActionSound>AS3D_UN_OCEAN_END1</ActionSound>
        </UnitArtInfo>

 

[Vokarya]

The kfm in question is literally just a Frigate kfm that I've modified by adding one extra bone and some animations. I'll upload the whole thing for you guys to look at.

This KFM file works for me under these conditions, using RiFE 1.4:

• Copy the module into a separate folder under NormalModules (so filepath Modules\NormalModules\SteamFrigate)
• Alter the beginning of the Frigate art definition to this:

        <UnitArtInfo>
            <Type>ART_DEF_UNIT_FRIGATE</Type>
            <Button>Art/Interface/Buttons/Units/Frigate.dds</Button>
            <fScale>0.2</fScale>
            <fInterfaceScale>0.5</fInterfaceScale>
            <bActAsLand>0</bActAsLand>
            <bActAsAir>0</bActAsAir>
            <NIF>Modules/NormalModules/Steam_Frigate/Frigate.nif</NIF>
            <KFM>Modules/NormalModules/Steam_Frigate/Frigate.kfm</KFM>

That gives me textureless but working Steam Frigates in both the Civilopedia and in-game.

What happens if you copy your texture files to your KFM folder and point the NIF and KFM tags at the same folder?

My suspicion is that since it works in-game but not in the pedia, the problem is really in the pedia files. Your Civilopedia screenshot looks different than what I have. What version are you actually using?

 

[SaibotLieh]

Here is my XML. Maybe you can see something I didn't.

Note that I am keeping the actual kfm in a different folder than my actual model because I intend to share the kfm between several models and want to keep the file size down. But that was newer a problem before as long as I keep a copy of the nif in my kfm folder which I do. And it is what every non custom unit does. The upload I made was of the kfm folder (it has a spare nif in it as presented).

So to duplicate my setup just put that folder as the KFM folder and make a separate folder with just the nif. You will end up with two folders that have a nif and one that has both the nif and kfm.

Also, the Modules/NormalModules thing is because it's a module for RiFE.

        <UnitArtInfo>
            <Type>ART_DEF_UNIT_FRIGATE_KHAZAD</Type>
            <Button>Art/Interface/Buttons/Units/Tradeship.dds</Button>
            <fScale>0.2</fScale>
            <fInterfaceScale>0.5</fInterfaceScale>
            <bActAsLand>0</bActAsLand>
            <bActAsAir>0</bActAsAir>
            <NIF>Modules/NormalModules/PPQ_NAVY/Art/civs/KHAZAD/Units/Ships/Frigate/frigate_split.nif</NIF>
            <KFM>Modules/NormalModules/PPQ_NAVY/Art/animations/Steam_Frigate/Frigate.kfm</KFM>
            <ShadowDef>
                <ShadowNIF>Art/Units/01_UnitShadows/FrigateShadow.nif</ShadowNIF>
                <ShadowAttachNode>BIP Pelvis</ShadowAttachNode>
                <fShadowScale>1</fShadowScale>
            </ShadowDef>
            <iDamageStates>4</iDamageStates>
            <TrailDefinition>
                <Texture>Art/Shared/water_ship_wake.dds</Texture>
                <fWidth>1</fWidth>
                <fLength>180</fLength>
                <fTaper>1</fTaper>
                <fFadeStartTime>0.2</fFadeStartTime>
                <fFadeFalloff>0.35</fFadeFalloff>
            </TrailDefinition>
                <fBattleDistance>0.35</fBattleDistance>
                <fRangedDeathTime>0.31</fRangedDeathTime>
                <bSmoothMove>1</bSmoothMove>
                <fAngleInterpRate>720</fAngleInterpRate>
                <fExchangeAngle>25</fExchangeAngle>
                <bActAsRanged>0</bActAsRanged>
                <TrainSound>AS2D_UNIT_BUILD_UNIT</TrainSound>
            <AudioRunSounds>
                <AudioRunTypeLoop>LOOPSTEP_OCEAN2</AudioRunTypeLoop>
                <AudioRunTypeEnd>ENDSTEP_OCEAN2</AudioRunTypeEnd>
            </AudioRunSounds>
            <SelectionSound>AS3D_UN_OCEAN_END1</SelectionSound>
            <ActionSound>AS3D_UN_OCEAN_END1</ActionSound>
        </UnitArtInfo>

Still works fine if spread over two folders. I can get a similar error when I remove the frigate.nif from the kfm folder, but you said you have that there, right?

Only other thing I see at the moment would be that you have "frigate_split.nif" instead of "frigate.nif" and that you are missing the <SHADERNIF> line, which should still be fine though. Could you probably be missing a "units" in between "animations" and "Steam_Frigate", and it should really be like "Modules/NormalModules/PPQ_NAVY/Art/animations/units/Steam_Frigate/Frigate.kfm"?

If nothing else works, maybe try the unit with an unmodded pedia. But that is really grasping for straws.

 

[PPQ_Purple]

Thanks you guys. I reviewed what you said and decided it was most likely an XML error so I just went and rewrote the whole XML from scratch and now it works. You two are my heroes. Now I can keep on making more steam warships for the dwarves.

 

[SaibotLieh]

Thanks you guys. I reviewed what you said and decided it was most likely an XML error so I just went and rewrote the whole XML from scratch and now it works. You two are my heroes. Now I can keep on making more steam warships for the dwarves.

No worries, glad that it is working for you now.