Mod-Modders Guide to Fall Further

[Valkrionn]

Found it!

I had already found a place in Assets/Resources that referenced the mod path... Apparently that same path is ALSO referenced in ArtDefinesMisc. Fixed, working fine without FF installed.

Unfortunately, due to the size of the installer I don't have the time to upload it anymore today... Will get it uploaded either late tonight or tomorrow morning.

 

[xienwolf]

Aye, the .thm and the ArtDef Misc both have to know where to look. Was a HUGE pain to figure that one out back when I redesigned FfH's interface because I could get things to work in the main mod, but the exact same things in my modmod would have no effect. Then when I started doing FF I accidentally made the exact same mistake after giving up and maintaining both the "untouched" public release folder and my own working one

 

[Valkrionn]

Alright, I'm wanting to change a few things for the Animal civ. FFPlus has added quite a bit of variety there, but they've become rather top-heavy... Too many strong animals, too early.

To fix that, I'm thinking of these changes... Any chance you could tell me if these are feasible, and if so, where to start? The main points are 1, and 2.2. Strength gain for civs at peace with the animals, while nice, is just icing... Not as important.

1. A few very strong animals will be limited via techs. Mostly looking at Dragons, Cave Bears, Elks. Maybe Wyrms.... But I like them.
   • What might be better, would be to allow small numbers of them to spawn throughout the game... But increase those numbers with specific techs. Will need to talk to Xienwolf about where to start with that, however.
2. Revamp the animal civ's Strength Gain mechanic.
   1. For one thing, I'd like to apply the same mechanic to animals owned by civs at peace with Cernunnos... As in, Doviello/Archos. Might add Ljos in there for variety.
   2. I'd like animals over a certain strength limit (Say, 4 points over the base for that particular animal?) to become Beasts, making them slightly harder to tame... But more palatable to fight. If I'm going to lose a third of my army taking out a bear, the thing needs to be a Beast.
   3. To go with that, certain animals will be made Beasts naturally. Cave Bears/Elks already are, and I believe the Dragons are... I think the Wyrm could stand it, the Dragon Tortoise, and maybe a few others.

 

[xienwolf]

Limiting by tech, or even controlling raw quantity by tech, is pretty trivial. You can add an <iAppearanceProb> field to unitinfos, and use that as a weighting factor in deciding which animal to spawn in a tile when multiple animals are available. If this value is 0 or negative, the unit is considered invalid and skipped, even though the Terrain/Feature Natives worked.

Then you add an array of <TechAppearances> which can modify the iAppearanceProb based on anyone in the world knowing the tech listed. This value can be positive or negative, allowing you to increase the chances of finding an animal, authorize an animal (by making it now non-negative), or even de-authorize an animal (by making it negative).

-------------------------------------

The problem with allowing animals not in the animal civ to gain strength is that right now it is set up to simply allow a point to be gained on the turn which the unit becomes old enough for the gain. Thus the unit must have uninterrupted ownership by a civ which allows growth. Since Cernunnos has no way to capture units, this isn't an obvious complication with just the animal civ allowing growth. But if other civs can grow animals as well, then it becomes an issue.

You could probably come up with a new system to bypass this limitation without much effort. I just didn't see the value in it personally as I intended the mechanic to symbolize the banding together of animals, or the growth and development from fighting for survival, each of which stop when "domesticated"

------------------

You could make a new prereq for promotions which is based on StrBoost of the unit, then have an AutoAcquire promo to swap unitcombat. Or you could rewrite the DLL routine which grants strength to also apply a special promotion on the 4th run (promo set by global define and changing unitcombat), or just to flat out change the unitcombat. Or you could cheat and since you know what age the unit will be when gaining the fourth boost, have an AA MinAge, CIV_ANIMAL promotion (not MustMaintain, so that the unitcombat remains beast after capture)

------------------------------------------

I don't understand the issue with 3. If you want a unit to always be a beast, just make it a beast in unitinfos. The ONLY requirement for something to spawn for the animal civilization is that it has TerrainNative and/or FeatureNative entries in unitinfos, and is listed for Cernunnos in CivInfos. They can be any unitcombat you want them to be.

 

[Valkrionn]

Limiting by tech, or even controlling raw quantity by tech, is pretty trivial. You can add an <iAppearanceProb> field to unitinfos, and use that as a weighting factor in deciding which animal to spawn in a tile when multiple animals are available. If this value is 0 or negative, the unit is considered invalid and skipped, even though the Terrain/Feature Natives worked.

Then you add an array of <TechAppearances> which can modify the iAppearanceProb based on anyone in the world knowing the tech listed. This value can be positive or negative, allowing you to increase the chances of finding an animal, authorize an animal (by making it now non-negative), or even de-authorize an animal (by making it negative).

That's exactly what I want. Where should I look to get an idea of how to do this? Still at the 'Copy & Tweak' stage in the DLL.

The problem with allowing animals not in the animal civ to gain strength is that right now it is set up to simply allow a point to be gained on the turn which the unit becomes old enough for the gain. Thus the unit must have uninterrupted ownership by a civ which allows growth. Since Cernunnos has no way to capture units, this isn't an obvious complication with just the animal civ allowing growth. But if other civs can grow animals as well, then it becomes an issue.

You could probably come up with a new system to bypass this limitation without much effort. I just didn't see the value in it personally as I intended the mechanic to symbolize the banding together of animals, or the growth and development from fighting for survival, each of which stop when "domesticated"

This one isn't important at all, honestly. Would be nice, but if it causes issues like this then it's not needed.

You could make a new prereq for promotions which is based on StrBoost of the unit, then have an AutoAcquire promo to swap unitcombat. Or you could rewrite the DLL routine which grants strength to also apply a special promotion on the 4th run (promo set by global define and changing unitcombat), or just to flat out change the unitcombat. Or you could cheat and since you know what age the unit will be when gaining the fourth boost, have an AA MinAge, CIV_ANIMAL promotion (not MustMaintain, so that the unitcombat remains beast after capture)

I think the StrBoost prereq would be best, as it's the most versatile. Can set exactly how many boosts it takes to alter the combat...

I'm assuming I should be able to do this the same as any other promotionPrereq tags?

I don't understand the issue with 3. If you want a unit to always be a beast, just make it a beast in unitinfos. The ONLY requirement for something to spawn for the animal civilization is that it has TerrainNative and/or FeatureNative entries in unitinfos, and is listed for Cernunnos in CivInfos. They can be any unitcombat you want them to be.

It's not one. I simply copy/pasted a post I made in the FFPlus forum, and forgot to remove that.

 

[xienwolf]

Well, adding an array you can look at quite a few locations for how to do that one. Just make sure to look at one which loads an integer, and not one which loads as booleans, they act very differently Once you get your integer and array, I think that the code is pretty close to what you want for animals already, it should (not looking at it now, going on memory), loop over all units, and if they are valid for the tile to spawn on it assigns a random number to them. Where this happens you instead want to grab the appearance probability of the unit (maybe also add in a small random though, so you have to decide on the size of each value yourself). This will require a loop over all technologies and a check to see if the tech has been discovered yet. Sample of how to check that would be in CvTeam probably, wherever it checks to see if a Holy City should be made, or a free great person handed out.

Opera can probably help guide you through most of it if you catch her on #erebus, I'll try to be on there tomorrow if I can manage to offer some assistance as well.


The PrereqStrBoostSize tag (or whatever you call it) would be exactly the same deal as any other prereq, correct. Can probably copy MinLevel almost exactly line for line to do it.

 

[Valkrionn]

Well, adding an array you can look at quite a few locations for how to do that one. Just make sure to look at one which loads an integer, and not one which loads as booleans, they act very differently Once you get your integer and array, I think that the code is pretty close to what you want for animals already, it should (not looking at it now, going on memory), loop over all units, and if they are valid for the tile to spawn on it assigns a random number to them. Where this happens you instead want to grab the appearance probability of the unit (maybe also add in a small random though, so you have to decide on the size of each value yourself). This will require a loop over all technologies and a check to see if the tech has been discovered yet. Sample of how to check that would be in CvTeam probably, wherever it checks to see if a Holy City should be made, or a free great person handed out.

Opera can probably help guide you through most of it if you catch her on #erebus, I'll try to be on there tomorrow if I can manage to offer some assistance as well.


The PrereqStrBoostSize tag (or whatever you call it) would be exactly the same deal as any other prereq, correct. Can probably copy MinLevel almost exactly line for line to do it.

Well, the Array will be interesting to add. At the least, I'll learn as I do it... Which is always a good thing.

PrereqStrBoostSize should be easy to add then... At the moment it won't do much other than change the unitcombat, but I could see having it grant higher-strength abilities as well....

 

[Opera]

Animals are limited by techs in Orbis, you might want to take a look.
(sorry, didn't read the whole conversation, maybe xien already answered )

 

[Valkrionn]

Yes, but I thought that was ALL animals?

In any case, I'll look into it tomorrow morning.

 

[Opera]

I believe it works the same way as it does for a normal player: the animal player gets techs which allow some new units. You could say that wolves are like warriors, available from the start but that Griffons are like Horsemen; but they don't require anything else but a tech.

(Techs are, I think, slowly given to the animal player)

 

[Valkrionn]

That's something I want to avoid. You can see with the Barbs that they generally lag behind in unit types, because they get the techs too slow... With the animals, I want the new one popping as soon as ANYONE knows the tech. Which needs the Array Xienwolf described.

 

[Opera]

Hey, xienwolf, how would I make it so I can allow some civs to build a specific improvements on a terrain? Basically, I would like to be able to set a TerrainMakesValid in CivilizationInfos depending on an ImprovementType. The issue I ran into was that I need it to be boolean, so I though I needed a TagPair thing but I saw you mentioning boolean arrays...

So I could do something like 'getImprovementTerrainMakesValid[j]' where 'i' would be the Improvement and 'j' the terrain and it would return true if specified in the CivilizationInfos file and false if not?

Not sure how to code it though, especially how to store the values... Is there some example of this kind in the code?

 

[xienwolf]

You want to allow a normal improvement in a new location? The more easily documented, but possibly harder to code, approach may be to add PrereqCivilization and ExtraTerrain arrays to BuildInfos. Then the basic improvement can maintain the same issues it always had, but the build order can bypass and allow special application rules. But of course the way that the AI is built to plan their land may cause issues with that approach, I can't remember if they look at build orders or improvements, but doing it by build orders makes more sense, which is why I say that this approach SHOULD be easier (if all the AI is by improvement instead, then your way is probably as good as any).


I don't much care for the Firaxis TagPair booleans. If you listed the damn thing, you want it on. The extra lines and framework are thus useless for a boolean. Instead I like just doing them as a list, and if I find it easier to keep to an array inside the DLL, I just flip the booleans on the array where needed.


If you don't go through buildorders, it might be easiest to approach this like UU/UBs. Load all of the improvement TerrainMakesValid data into the civilizationInfos as defaults, then augment it with whatever extra information is listed (just add to the existing though instead of overwriting the existing. Unless you go with the TagPair approach but this time the 0 actually means you REMOVE the ability to place the improvement on specified terrain types)

 

[Opera]

Yeah, actually, I did it this way for BlockCivilizations... If there is a civ, it's on by default, I'm not using booleans. I think I'll go this way. Hopefully, someday, I will code a UniqueImprovements thing...

 

[Afforess]

Yeah, actually, I did it this way for BlockCivilizations... If there is a civ, it's on by default, I'm not using booleans. I think I'll go this way. Hopefully, someday, I will code a UniqueImprovements thing...

Interjecting here,

Unique Improvements would really be interesting. It could give some serious advantages/disadvantages to civs.

 

[odalrick]

It seems that converting a unit in a PythonOnRemove of a promotion causes problems. I tried and somehow got six units from one conversion.

I figured out a different way to accomplish the feat, but it seems worth mentioning.

 

[xienwolf]

You need to use safeRemovePromotion early in your function because when you run .convert on a unit it will kill the unit, and thus trigger the removal python again during the death process (though I should have set it up NOT to trigger such functions during ::kill from conversion, so maybe that won't work because it is already being done and failing)

 

[sylvain5477]

EDIT : ok my mistake, just read the first post and everythig is there.

 

[Opera]

Interjecting here,

Unique Improvements would really be interesting. It could give some serious advantages/disadvantages to civs.

Yes, it would be
But it will also be a tad cumbersome to code

 

[odalrick]

You need to use safeRemovePromotion early in your function because when you run .convert on a unit it will kill the unit, and thus trigger the removal python again during the death process (though I should have set it up NOT to trigger such functions during ::kill from conversion, so maybe that won't work because it is already being done and failing)

I tried to do it without custom python, so the PythonOnRemove tag contained only pCaster.cast(gc.getInfoTypeForString('SPELL_BECOME_IRON_GOLEM')). The SPELL_BECOME_IRON_GOLEM does the heavy lifting of converting the unit and removing promotions.

But I don't think that PythonOnRemove is run when the unit is destroyed.

I figured out another way to accomplish my goals, but a ConvertOnRemove tag sounds possibly worthwhile.