Quick Modding Questions Thread

Yeah, good points. I have worked with githooks before, in projects that use linting and autoformatting. It's pretty useful to abort a commit if the code does not comply with an externally defined linting standard. Unfortunately it is more limited if you want to mess with how git itself works, i.e. manipulating the commit being created.
 
Is there a way to make it so that researching one tech disables your ability to research another creating branching paths through the tech tree? I know it'd be DLL work if possible and that's fine.
Also you don't need to give me an actual solution because that would spoil the fun. I just want to know if anyone has ever done something like this and if it is even possible.

Also is it possible to code a building such that it removes all great person growth from that city?
 
Last edited:
IIRC, check python hooks, canResearch and canNotResearch.
Not sure about GP query. You could use python onBuildingBuilt to wipe GP progress. If you’re asking about blocking GP growth into the future, I’m not sure.
 
Changes to tech requirements should not involve the EXE at all, so I'd say everything is possible. Challenges:
• Not sure if reqs are checked (canResearch) while a tech is being researched – or only once, upon starting research. Well, adding an end-of-turn check shouldn't be much trouble.
• The AI and UI (when a target tech to bee-line to is chosen on the Tech Advisor) need to be able find paths through the tech tree. Those paths will have to avoid techs that block the target.
• AI tech evaluation should subtract some utility when the evaluated tech will block another tech (opportunity cost).
 
Thank you. Now I know it can be done I can put it on my list of potential mechanics.
 
Changes to tech requirements should not involve the EXE at all, so I'd say everything is possible. Challenges:
• Not sure if reqs are checked (canResearch) while a tech is being researched – or only once, upon starting research. Well, adding an end-of-turn check shouldn't be much trouble.
• The AI and UI (when a target tech to bee-line to is chosen on the Tech Advisor) need to be able find paths through the tech tree. Those paths will have to avoid techs that block the target.
• AI tech evaluation should subtract some utility when the evaluated tech will block another tech (opportunity cost).
I tried changing both to no effect.
Code:
    def canResearch(self,argsList):
        ePlayer = argsList[0]
        eTech = argsList[1]
        bTrade = argsList[2]
   
        if eTech == gc.getInfoTypeForString('TECH_HUNTING'):
            return False
   
        return False

Code:
    def cannotResearch(self,argsList):
        ePlayer = argsList[0]
        eTech = argsList[1]
        bTrade = argsList[2]
   
        if eTech == gc.getInfoTypeForString('TECH_HUNTING'):
            return True   
        return False
I tried both of these separately but neither blocked the research either in the interface or at all. I could still research hunting just fine.

Also, the following just makes the game bug out and the interface vanish:
Code:
    def canResearch(self,argsList):
        ePlayer = argsList[0]
        eTech = argsList[1]
        bTrade = argsList[2]
   
        if eTech == gc.getInfoTypeForString('TECH_HUNTING'):
            return True
   
        return False

This said, I found the solution whilst looking through the FFH DLL and the required religions for tech feature there. But I still wanted to post things here for posterity.
 
Last edited:
May need to enable the respective Python callbacks in PythonCallbackDefines.xml. Vanished interface: Likely a Python exception, stack trace should be in PythonErr.log if logging is enabled in CivilizationIV.ini (can also get a popup through HidePythonExceptions=0). But imo implementing this rule change (partly) in Python only complicates matters, considering that you'll mod the DLL in any case.
 
Hi,

I'm trying to animate a model in blender. Unfortunately the limbs of the model seem to rotate twice as fast as the bones. Actually, one of the meshes seems to move at twice the bone's rate while the other meshes stay in sync with the bone. Any ideas what causes this and how I can fix it?
 
I do not know either. But I would suggest you check the skin binding and worst comes to worse reskin the model.
 
I am having an issue where my game gets stuck during an AI player's turn. I have determined that CvPlayerAI::AI_unitUpdate() completes with some units still having moves left, which isn't supposed to happen. Due to that, the turn of that player never completes, and the game does not advance.

I haven't changed CvPlayerAI::AI_unitUpdate() or CvSelectionGroupAI::AI_update(), but it's possible that the AI of a specific unit can fail in some way that it does not make a decision and the unit just never uses its moves.

Looking into the actual game state, it affects multiple units of different types, including Riflemen, Grenadiers, and Spies, and I cannot think of an obvious commonality/change that I made that this might point to.

Is there a feasible way to detect what kind of decisionmaking of the AI leads to this phenomenon? I am at a loss of where to look.
 
If you can obtain the ID of one of the units whose moves don't get spent, you could set a conditional breakpoint in CvUnitAI::AI_update, step into the AI_...Move subroutine, see if a missions gets pushed and, if so, how CvSelectionGroup processes that mission (startMission, continueMission). Or maybe straight away a breakpoint in those CvSelectionGroup functions (if the group ID is known) instead of bothering with CvUnitAI. If no mission is pushed and CvUnitAI::AI_update doesn't get called ... one could still check CvSelectionGroupAI::AI_update. I don't really see what could go wrong in CvPlayerAI::AI_unitUpdate itself.
I haven't changed CvPlayerAI::AI_unitUpdate() or CvSelectionGroupAI::AI_update(), but it's possible that the AI of a specific unit can fail in some way that it does not make a decision and the unit just never uses its moves.
There's BtS code for detecting when a group indefinitely fails to push a mission:
CvSelectionGroupAI::AI_update
Don't know who commented out the assertion in your codebase; doesn't seem prudent to ignore those issues. That said, the code still (silently, apart from a log entry) forces the group to finish its moves, so it's apparently not able to catch whatever bug you're dealing with. I've had an infinite loop once where a unit was not pushing a mission and also kept changing its group membership, and I added a test to CvGame::updateMoves to identify such problems in the future. But it seems unlikely that you would've introduced a bug like this affecting both Spies and Riflemen.

Having skimmed through diffs of your CvSelectionGroup classes, the "possible loop fix" by Rhye in CvSelectionGroup::canDoCommand, setupActionCache, canEverDoCommand, canMoveThrough, CvSelectionGroupAI::AI_seperateNonAI and AI_separateAI looks suspect. Couldn't hurt to insert assertions or breakpoints to rule out that this hack – rather than prevent an infinite loop – is hiding or even causing one.
(And I see that your mod adds loop detection in CvSelectionGroup::groupMove. Just mentioning this for completeness' sake; this one contains an assertion - so is clearly not involved with the present problem. Oh, perhaps this supersedes the BtS loop detection, or at least most of the time, and hence the removal of the assertion in CvSelectionGroupAI::AI_update.)
 
Yeah, I tried the assert you found commented out (who knows why - I am about as likely responsible as Rhye is) but it didn't trigger. The strange extra check by Rhye is something worth looking into though. Thanks!
 
Playing Realism Invictus 3.57, I'm trying to make new custom traits with a bonus/malus to military unit production. In the CIV4TraitInfos XML there's an option for <iMilitaryProductionModifier>, which hasn't been used for any other trait. Plugging values in seems to do nothing, however. Is there deeper modding that needs to be done to make this feature useable?
 
Looks like no semantics have been implemented in the (GameCore) DLL for this this tag. That is, RI's XML schema file allows (actually: demands) it to be present
CIV4CivilizationsSchema.xml#l490
but the DLL doesn't access the XML data. Would expect that to happen after
pXML->GetChildXmlValByName(&m_iLevelExperienceModifier, "iLevelExperienceModifier");
in CvInfos.cpp (because iLevelExperience precedes iMilitaryProduction in XML). Also doesn't get processed after the various
changeLevelExperienceModifier(kTrait.getLevelExperienceModifier());
calls in CvPlayer.cpp. A full implementation for this tag might exist in some other mod, but, in Realism Invictus, only the XML-side appears to be present (which isn't much). Same for the iLevel tag btw.
 
Can I somehow generate resources automatically for a custom map?
 
The Europe scenario sets
Randomize Resources=true
in the map description. The effect (cf. CvWBDesc.py) should be that all resources placed through plot descriptions get cleared and that CvMapGenerator::addBonuses is called. I haven't tested whether that actually happens, i.e. whether resources are random or as specified in the plot descriptions of the Europe scenario.
This works! Thank you very much! Now I can finally play a decent Middle-earth map (after spending hours painting the whole map with grassland, rivers, forests, everything, I really couldn't be bothered to also put down the resources while obeying the rules of where they are allowed to be). :)
 
Looks like no semantics have been implemented in the (GameCore) DLL for this this tag. That is, RI's XML schema file allows (actually: demands) it to be present
CIV4CivilizationsSchema.xml#l490
but the DLL doesn't access the XML data. Would expect that to happen after
pXML->GetChildXmlValByName(&m_iLevelExperienceModifier, "iLevelExperienceModifier");
in CvInfos.cpp (because iLevelExperience precedes iMilitaryProduction in XML). Also doesn't get processed after the various
changeLevelExperienceModifier(kTrait.getLevelExperienceModifier());
calls in CvPlayer.cpp. A full implementation for this tag might exist in some other mod, but, in Realism Invictus, only the XML-side appears to be present (which isn't much). Same for the iLevel tag btw.
Thanks. As someone who has only ever fiddled around with the XML, can you tell me anything about how this feature could be implemented, or point me to a guide? Probably a lost cause for me, but I'd like to know how it might be done.
 
For any DLL changes, an environment for re-compiling the DLL needs to be set up. This guide should help with that. The RI source code is available here on SourceForge. I think you'd really need a way to run a full-text search on the RI codebase, searching e.g. for "LevelExperienceModifier", to find all the places where trait effects get processed. Searching for "MilitaryProductionModifier" should also be helpful; civics and buildings can already have this effect, so no novel program logic should be needed, just single lines in 10-20(?) different places. To figure out how exactly to mimic the existing code, you'd probably have to be familiar with some imperative programming language (if not with C++ itself). The forum might be able to help with compile-time errors, but it could also turn out that your code compiles but behaves unexpectedly at run time, and, in that case, you may have to either experiment a lot or configure the Visual Studio debugger to get to the bottom of the problem.

Rise of Mankind has lots of new modifiers, but not this one, apparently. Well, it wouldn't help all that much to find an existing implementation because one would still have to find all the relevant lines and RI might handle trait effects a little differently than the mod whose code is being adopted.
 
As far as compiling the DLL goes the hardest part is getting your hands on an ancient copy of visual studio.
 
Back
Top Bottom