Quick Modding Questions Thread

[Vokarya]

How exactly do <iCityAttack>, <TerrainAttacks>, and <FeatureAttacks> interact? I am looking at RoM:AND's cavalry units and the modifiers aren't acting the way I am expecting them to.

In this mod, Chariots have the following modifiers:

• <iCityAttack> -25.
• <TerrainAttacks> for Grass, Plains, and Desert +25 each.
• <FeatureAttacks> for Forest, Jungle, and Swamp -25 each.

So when I am attacking with a Chariot towards a city on a grassland or a unit on a forested grassland, I would expect that the bonuses and penalties to cancel out. From the screenshots, it looks like they do for cities but not for units. Why is that?

 

[f1rpo]

@Vokarya: Seems that modifiers based on the terrain type don't apply for tiles that have a feature: CvUnit::maxCombatStr (due to the else)
Oh, this is for defense. But it's the same logic for attack a bit farther down.

 

[<Nexus>]

@Vokarya: Seems that modifiers based on the terrain type don't apply for tiles that have a feature: CvUnit::maxCombatStr (due to the else)
Oh, this is for defense. But it's the same logic for attack a bit farther down.

And why is that so? Does it make any sense?

 

[f1rpo]

For the Chariot, it's perhaps helpful – if the idea is that it fights well in open terrain and badly in dense vegetation. Don't know if that could be accomplished just as easily if feature and terrain modifiers were added up. The tags were added by the BtS expansion, apparently, just for the sake of the bundled "Defense" mod (and maybe for modders in general). The units in that mod have only either a terrain or a feature combat modifier.

Hard to say what the original intention was, but the "else" doesn't strike me as an accident. Maybe not thought through – after all, it's unexpected that an attack modifier for Grassland doesn't apply to a tile labeled "Grassland Forest".

 

[Vokarya]

OK, I understand the code now. What I think is happening here, though, is a case of trying to apply too many modifiers and it just gets confusing.

 

[Leoreth]

What is in the PythonCallback argsList for Events?

Like, some of the methods in CvRandomEventInterface.py have this:

iButton = argsList[0]
iData1 = argsList[1]
iData2 = argsList[2]
iData3 = argsList[3]
szText = argsList[4]
bOption1 = argsList[5]
bOption2 = argsList[6]

and others have this:

iEvent = argsList[0]
kTriggeredData = argsList[1]

So, how do we know what is in argsList in general, if we are making our own Event Callback?

Without looking into the code, are you sure those are the same type of callback? First there is a distinction between "event triggers" (which is the actual event popup with multiple choices) and "events" (which is one of the choices associated with an event trigger). But then IIRC each of these also has multiple callbacks for whether it can be chosen/triggered and actually making the outcomes happen when chosen etc.

I think if you see callbacks with different arguments it is because they are different types of callbacks being called from different places. Can't give you a full list of callbacks and what their arguments are but at least once you know the type you can generalise a callback to others of the same type.

 

[f1rpo]

OK, I understand the code now. What I think is happening here, though, is a case of trying to apply too many modifiers and it just gets confusing.

Maybe that's what the Firaxis code is trying to tell us – not intended to be used on the same unit. In theory, penalties for rough terrain should suffice – along with a high base strength. (Though it might be difficult to hit just the right power level this way.)

 

[Vokarya]

Maybe that's what the Firaxis code is trying to tell us – not intended to be used on the same unit. In theory, penalties for rough terrain should suffice – along with a high base strength. (Though it might be difficult to hit just the right power level this way.)

I'm agreeing with that, although I prefer the base strength to be the minimum coupled with bonuses. That results in fewer "trap" situations where you lose because of something you overlooked..

 

[PPQ_Purple]

Is there a way to suppress XML errors when loading a mod? I know I have errors in my code because I am still working on it. And I just want to still load it up without having to click through 1000 messages.

Also is there any editor program for tech trees? Adding it all by hand is annoyingly boring.

 

[tvbowman]

Is there a way to suppress XML errors when loading a mod? I know I have errors in my code because I am still working on it. And I just want to still load it up without having to click through 1000 messages.

I think that is handled by the core, probably in CvXMLLoadUtilitySet.cpp or something.

Also is there any editor program for tech trees? Adding it all by hand is annoyingly boring.

The only thing that comes to mind is the FfH Editor Excel file for Fall from Heaven.

 

[PPQ_Purple]

I think that is handled by the core, probably in CvXMLLoadUtilitySet.cpp or something.

I see. If anyone has details about just what to look for please tell me. Recompiling the DLL to temporarily switch it off is not an issue for me.

The only thing that comes to mind is the FfH Editor Excel file for Fall from Heaven.

I see. Well that ain't very convenient. Unless someone has something else to suggest I guess I'll just have to roll my own.

 

[PPQ_Purple]

Meanwhile can anyone just explain to me how the grid system works for the coordinates of a tech? Like, is each unit X pixels or X% or something? If I say a tech is in position 3,5 for example what does that actually mean?

 

[f1rpo]

I see. If anyone has details about just what to look for please tell me. Recompiling the DLL to temporarily switch it off is not an issue for me.

The XML schema gets checked by the EXE; I don't think those error popups can be disabled through the DLL. But the DLL also contains several dozen MessageBox calls in CvXMLLoadUtility.cpp and (more so) CvXMLLoadUtilitySet.cpp. While MessageBox is implemented in the EXE, nothing stops the DLL from replacing that function:

Spoiler :

// (CvDLLUtilityIFaceBase.h)
// Linked to CvUtility::MessageBox in the EXE through the v-table ...
//virtual void MessageBox(const TCHAR* szText, const TCHAR* szCaption) = 0;
// ... regardless of how we rename the pure virtual function.
virtual void MessageBoxExternal(const TCHAR* szText, const TCHAR* szCaption) = 0;
// DLL-internal definition (not virtual)
void MessageBox(const TCHAR* szText, const TCHAR* szCaption)
{
	// Uncomment to re-enable error message boxes
	//MessageBoxExternal(szText, szCaption);
}

This should at least get rid of some of the error popups.

I'm agreeing with that, although I prefer the base strength to be the minimum coupled with bonuses. That results in fewer "trap" situations where you lose because of something you overlooked..

Then an open-terrain modifier would be desirable. Too bad that TerrainAttacks is going to confuse players in the case of e.g. Grassland Forest. Or, if the "else" is removed in the DLL, it'll have to be accompanied by a FeatureAttack penalty. Might be best to add a new XML tag that applies to all flat non-city tiles that have no defensive feature or improvement. "+25% from Open Terrain" should be pretty clear. Well, I guess, with just fewer modifiers per unit overall, players will figure out that "+25% Grassland Attack" does not work against Grassland Forest – and that this is intentional.

 

[tvbowman]

I see. Well that ain't very convenient. Unless someone has something else to suggest I guess I'll just have to roll my own.

Found this one:

https: // forums.civfanatics.com/threads/tech-tree-editor.193618/

Remove the spaces for the url to work.

*EDIT* not sure that one works, but this next one does work - I am testing it now and it looks promising:

https: // forums.civfanatics.com/threads/technology-creation-program.182186/

Once again, to prevent the moderation delay, I have added spaces in the URL.

 

[tvbowman]

Meanwhile can anyone just explain to me how the grid system works for the coordinates of a tech? Like, is each unit X pixels or X% or something? If I say a tech is in position 3,5 for example what does that actually mean?

This may help. You probably already know this, but here is what the coordinates look like in the tech tree:

 

[PPQ_Purple]

I am asking because basically my observations tell me that each unit on that list equals one tech sized box. So like fishing and the wheel are 1,1 and 1,3 implying that their position is such that you could fit another tech in between at 1.2. Is that correct?

 

[LPlate2]

You could have a tech at 1,2 but if you’ve also tech at 1,1 or 1,3, there’ll be an overlap on the screen.

 

[PPQ_Purple]

So vertically each tech is 2 units tall. Got it.

 

[tvbowman]

So vertically each tech is 2 units tall. Got it.

From CvTechChooser.py:

PIXEL_INCREMENT = 7
BOX_INCREMENT_WIDTH = 27 # Used to be 33 #Should be a multiple of 3...
BOX_INCREMENT_HEIGHT = 9 #Should be a multiple of 3...
BOX_INCREMENT_Y_SPACING = 6 #Should be a multiple of 3...
BOX_INCREMENT_X_SPACING = 9 #Should be a multiple of 3...

TEXTURE_SIZE = 24
X_START = 6
X_INCREMENT = 27
Y_ROW = 32

If you use different graphics or a mod, these might be different numbers to reflect the size of the graphics for the tech tree, but I think these values are all in pixels.

 

[PPQ_Purple]

Ok. Thanks. That is cool. Now I know.