• Civ7 is already available! Happy playing :).

[MODCOMP] - XML Cleanup & Expansion

I tried merging the dlls of this modmod, UnitStats, and Broader Alignment, but I keep getting 3 errors in CvUnit.cpp. It can't find isDieAfterCombat, isApplyBuildingDefense, or is Mortal in CvUnit. Looking though both by files and the original ones I can't find them either.
 
All 3 of those got cut before the currently posted version.

I had completely forgotten about the Die After Combat tag. Cut that quite a while ago when I realized that you can just set <iKamikaze> to 100 and achieve the exact same effect (actually that was when I realized I should consider doing Percentages instead of Booleans for most of the tags. Though I don't know if any of these ones are really fitting as percentages instead, so I didn't feel the need to scrap all of my work and start over)
 
Ok, so I should just cut them from CvUnit.cpp? I assume that the files you released and the ones you compiles aren't the same?

I'd decided to try compiling you changes alone (put into the main mod dll source files, unaltered). It seemed to be going fine, but then my laptop crashed. I'm a little nervous about compiling the dll again.
 
The ones I released ought to be the latest ones I compiled. I'll re-upload with my latest copies right now though.

Just cutting them out of CvUnit will probably lead to a cascade of faults, as other areas might reference them. But a search for those keywords would find all cases in all files, then you could remove all of that and it should be fine.

New file is called Modcomp26a.zip, so that you know when it is the new one available.


EDIT: Found a minor Typo with the Territorial setup. So uploaded latest version is actually 26b. If you already downloaded 26a, just remove Territorial, or fix the typo (in the loading from XML section I had it loading bRivalTerritoryExplore instead of bTerritorial)
 
I cut them from just CvUnit.cpp and I got errors, but then I cut them from CyUnit.h too and it almost turned out fine. But the problems were in CyUnitInferface1.cpp, which isn't even included in the new files. I compared all the new files to mine, but don't I really don't feel like starting the 3 mod merge all over again. Hopefully there were no references to these in other files in the old version that aren't in the new version.

Ok, It seems to be working. I haven't tested any of your tags specifically, but the compile worked and the alignment bar and the unit stats screen seem to be working fine.
 
Xienwolf, the promotion ability I have wanted was for a promotion to allow a unit to get gold from combat. i.e. a promotion that lets a unit act as a privateer and get 10 gold post combat. I think it would be a good upper level Runes promotion.
 
Strange that you'd get issues in CyUnitInterface, I did not modify that one. But it could be something to do with the mixing of the mods. But glad to hear it wound up working eventually.


I like the sounds of it mtagge :) And it is planned for the next phase :)
 
Hmm...I was sure I'd already mentioned it, but I'm not seeing it here so I'll repeat one request that is essential to my modmod: Allow promotions (and maybe also individual units) to effect the duration of the units summoned by the unit. (In my modmod, I'm removing the Summoning trait and making each Dimensional promotion boost duration, and probably adding some equipment with the effect too)


I'd also like the gold from combat tag. Of course, I was thinking more along the lines of the Piracy and Letters of Marque promotions granting cold from combat, and the mercenary promotion costing you gold.

I still think that exposing canPromote to python is essential.
 
Actually I already planned to add an <iChangeDuration> value. You can use it for lots of things.

Delayed Death attacks from Assassins (Ha, now all your units will die in 10 turns unless you cast Heal to remove the Delayed Death Promotion!)

Summon Perk Promotion to add 1 or more Duration

Summon Perk to REMOVE duration (you can use Negative Values to bring the duration down to 0, thus making it permanent)


And upon removal of the promotion, the original duration will be restored.
 
When would the promotion boost the duration? Only when given (or removed)? If you made it instead happen every turn it could really throw things off.

It seems like it would be easier to just make the promotion grant duration to its summons directly. Besides, I'd rather have the ability to grant some other promotions at the same time (without just making up new promos that combine the two effects). Plus, fewer promotions means less clutter.
 
Yes, it would only provide the boost when given. Every turn would make absolutely no sense at all.

If my only goal was to allow longer summons, yes it would be easier to do it more directly. But you could also just do that with Python in unmodded FfH quite easily. This field will be (as mentioned in the examples) much more versatile.
 
How could I do this with just python, without needing to require every xml-only summoning spell instead have a python result to create the unit and change its duration based on the caster's promotions?

I was also wondering: Is there a way to block certain summons from getting all the summon perks? I was thinking that the spell xml should have a boolean tag determining if the summon will get the free promotions from the caster's promotions. Fireballs and meteors shouldn't get the extra duration (I don't think they get it now, but I'm not sure what stops this). Of course, you'd still probably want the empower promotions...hmm. There are few more summons I was thinking shouldn't get the bonuses though. Combat bonuses don't make a lot of sense for my non-combat summons (like tesseract), and getting the summon perks on fleshgolems before you give them the promos of the units grafted into them seems a bit strong.
 
In the onunitcreate function you could declare that if the unit has a duration > 0 to increase the duration by 1 if there is a caster on the tile with the appropriate promotion who has cast this turn. Doesn't flawlessly tie it together, but I'm not devoting much thought or time to it or I'd probably get something better fairly easy.
 
Hmm...you didn't include the work rate modifiers here, did you? I just tried adding the promotions from the worker modmod to my modmod and its causing problems.

I can't decide whether I should delete them for now or go ahead and try merging the SDKs again.

Edit: wait... it is included. Maybe I made some other mistake.
Edit2: ok, its working now. I didn't realize that the tags weren't in the same order

Edit3: I tried what you suggested for the extra duration from the promotion, but it isn't working. I may just stick to a "reinvoke" metamagic/dimensional spell for now.
 
Would have to check the DLL then. It might be that it is calling the Python before it is setting the duration. If that is the case then your check for Duration > 0 would never be true, and any changes in the duration would wind up getting overwritten anyway.
 
New version uploaded with another MODCOMP added to FfH which I absolutely ADORE!


Dom Pedro's Dynamic Unique Units allows you to assign Unique Units to a Player mid-game. The current fields which can make these additions are attached to Technologies (First to Discover only), Buildings & Events. More can be added in the future fairly easily (like on Civics & Religions. Though those ones are a tad trickier as you will want to remove the UUs upon changing out of that Religion or Civic. But that is easily done as long as you are careful to remember not to remove a UU for the same unitclass that WASN'T granted by the Religion).


Actually, if you tied it to religions then you could make all priests be the same unitclass, and then changing your religion would just change your priests to the new religion's priests automatically. Could be cool to do it that way indeed...


You can customize how the Unique Units will behave in the Global Defines a little bit, but overall these customizations aren't too fitting for FfH IMO.
You can limit the total number of UUs which a Civilization can have (which won't work well for FfH since everybody has a UU version of every other Hero in the game to block it).
You can limit the number of UUs which can be gained by being the first to research a tech (well, this one is a bit fitting for FfH still, it helps you to keep a person with a demanding Tech Lead in check).
You can decide if units which are already built/existing are changed to the new unit type when you unlock it. (For now I have it set so that they are. But if you did the stated example of making all priests be the same unitclass, having this set means you cannot save priests of a different religion when you swap over, which I know some people are fond of doing).




There is a LOT you can do with these 3 fields really. The sample I included with the completely new units is just a small taste really. You can reward people for being the first to a Tech with a UU version of the unit that is normally unlocked there (like first to BronzeWorking gets Axemen which cost 1/2 as much :hammers:, or have 1 more :strength:), or you can penalize people who are too advanced in one Tech Line (like first to Sorcery gets a UU version of Axemen who have 1 LESS :strength:, so that they are crippled in Melee if they didn't advance beyond Axemen in preperation).

You can also be creative with this: Like the first one to Research Guilds gets a UU version of Horsemen which can upgrade to an Adept. I don't know a good way to justify that one... I just thought it was a funny example :)

Also you can use this kind of like Hero Units. Instead of gaining Baron Duin with Commune with Nature, you could instead have them gain the ability to flat out build Werewolves (well, you could even do both if you really want to). If you want to allow ALL players access to building them, you can make the Grove building unlock access to Werewolves. Then as soon as you build your first Grove (or capture one) you can begin making Werewolves directly with :hammers: instead of having to spawn them with other Werewolves.


Remember though that as it is written, a new UU can only be gained if the Civilization currently has NO UU FOR THAT SLOT. Thus if you create a UU version of the Warrior, the Doviello & Calabim cannot get it, because they already have Beastmen & Bloodpets. A UU version of the Adept wouldn't be available for the Infernals, because they already have the Imps (and so on.. I think you get the point easily enough).
 
Uploaded again. Only change this time is a cleaned PromotionInfos.xml. Removed all the '0' or 'NONE' and blank fields. I haven't sorted things alphabetically yet, because that'd be a bit of a pain, and I have more enjoyable things to program right now :p


The changes require the Scema, and most likely need the DLL as well. I added default values for the fields which are NONE, as well as the <Sound> field, since all of them use the same one thus far.


Button, Type & Description are the only non-optional fields. To get things in the proper order you can look at Woodsman II. All fields are listed on that Promotion to function as a template.
 
Uploaded a new version of the MODCOMP, 2 more works borrowed from other Modders out there. You can now gain Resources through Civics and buildings can improve (or degrade) as you gain new technologies.

Also switched to a version number system instead of saying how many fields are added. I lost count.


Eventually I will reformat the first post since I am now working on areas other than just PromotionInfos (well, not working, but borrowing). I'll aim to sort it by XML files changed, and move the credits of borrowed work to the second post or something.


Many more annotations in the SDK now as well. So if you are interested in starting to mod the DLL yourself, feel free to browse. And if you already know how to mod the DLL and you are incorporating this MODCOMP, please leave feedback on how I am wrong ;)
 
Still quite a ways off from making an actual MOD, but just got a new idea for what I will be doing in it which I think is worth putting out there for other Modders.

Dyanmic Unique Units can have FAR more impact than previously envisioned in a simple way:

In each branch of the Tech Tree, offer a UU version of the Settler which will allow you to construct new cities with Population > 1, and free Buildings. This will flavor your entire Civ toward the Tech Tree portion you focus on. Additionally, it can reward people who are slower at climbing the tech tree to allow them a chance to catch up in the lategame (if they manage to settle new cities still). That happens by offering multiple new Settler UUs in the same branch. Someone quick at Tech will get the early one, while someone moving slower will get the next, and someone dragging arse will get the third or later.


Thus at Knowledge of the Ether, all of your new cities could start with 2 Population and a Mage Guild. But at Strength of Will they could all start with 5 Population, Mage Guild, Obsidian Gate & Academy, meanwhile if instead you went down the Melee Path, at Bronze Working you get Population 2 with Training Yard, but at Mithril Working you get Population 6 with Training Yard, Siege Workshop, Courthouse & Palisade.... Things like that.
 
Could you make it so that settlers' city sizes are determined by their level/promotions? or so their religion and promotions effect the religion and cities in the cities they found?
 
Top Bottom