Mod-Modders Guide to Fall Further

That would actually be a ridiculously powerful spell. And would need a rather large amount of limitations, to prevent it from stripping races, equipment, and other such promotions that shouldn't be lost.

Plus it would really suck to have your hero just suddenly "unmanned". XD

Now I would REALLY love for there to be a way to make a unit temporarily ~lose~ promotions. I have been trying forever, for example, to find a way to code a spell that causes all casters in the radius to temporarily lose 50% of their spell promotions. But I imagine that one would be a hell of a lot harder to manage.
 
Is it possible to have (or add) NOT requirements on spells? If so, you could do that by having a blocking promotion for each sphere and making all its spells require, say Death II and NOT Deathblock (or whatever). Then you grant a random set of those promos to affected units (including the caster I imagine, more fun that way :)) with a chance to wear off on each. I'm pretty sure you could force it to only apply ones for spheres which the target has at least one rank in if you wanted, but that might get a little processing-heavy. Of course, not doing that allows the spell a chane to backfire horribly, having no actual effect on your enemies and blocking most of the caster's own spells :)
 
lose any promotion they have had for more than 50 turns

Why the old ones and not the newer ones? Just wondering.

(And, btw, could someone remind me what "Entropy" in FFH is supposed to be? Is it simply disorder/randomness/loss, or something else?)
 
You can already do Beef's idea with some of the newer fields I added. the PromotionExclusive set will let you strip a promotion off of a unit (by applying a promotion which excludes it), and the PromotionDegrade can re-apply the promotion. So, you could have anti-Death, which excludes (removes) Death 1/2/3, and then degrades into Death 1/2/3. In order for the degrade to work properly you'd need a seperate promotion for each possible sphere, and have to make sure you only apply a promotion which is needed (if you block death 2 on a unit that does not HAVE death 2, then the block will still degrade to grant them the promotion!)


As for the idea on Entropy III, it is still just an idea, so would obviously need some tweaking or additional mechanisms attached. Taking away the more recent promotions would probably work better (any promotion which the unit has only had for 1/3 of the time it has been alive would be interesting. Almost useless against a new unit, but priceless against an older unit who just came off defender duty and gained some levels). Either way though you would be taking a gamble with hoping that you can remove anything at all.
 
Another random idea: Would be nice if promotions could have a tag so that they must be "maintained", the same way magically created buildings are. The basic idea would be that if any unit in the stack can cast the spell that applies the promotion, then the promotion persists. As soon as no valid caster is in the stack, the promotion is lost.

I was thinking that a mechanic like this would be great for spells like Haste, Blur, and Dance of Blades, to greatly reduce micromanagement.
 
Aye, I am intending to make the "Maintain" function just be that the duration of a building/promotion won't count down while a valid caster is on the stack. So all current spell-by-building would work exactly the same way they do now if you give them a duration of 1. The intention is that you should be able to apply a duration to a promotion/building via the spell which creates it. So you could create a 10 turn forge by spell, but still build normal permanent forges if you want to (without needing to duplicate the forge in XML and make the copy have a duration).
 
Awesome. That is EXACTLY what I was hoping for. ^_^

...Of course, with my luck, by the time you release it, I'll have forgotten everything I wanted to do with it. ^^;
 
First post updated a little, can't help but feel I am forgetting to do that too often. PrereqLevel removed from PromotionInfos (using Kael's MinLevel now instead, does exactly the same thing). Added bUnique to BuildingClass & UnitClass to identify UUs & UBs so that the Dawn of Man screen & Civilopedia are far better documenting the Civ's true capability.

Also added documentation of the 2 new game options, Civ Selector (not really a gameoption technically), and an option to disable automatic gain of Worker XP (they still have a unitcombat and can gain promotions, but it is nearly impossible for that to happen, would need spirit guide to hit a worker, or to choose to give a worker some equipment and go hunting with it)

Minor tweaks I don't think I have posted an update on (other than updating above) would be that Twincast capabilities from promotions can now stack (though I have not yet made it an Interger value), meaning a unit could have 5 different promotions granting Twincast, and thus be able to cast 6 spells per turn. Also, Twincast doesn't mean "Dual-Summon" it means you get to cast twice each turn (I cannot remember, but I think I made it so that you only regain a single casting from breaking a spellstaff. Otherwise if you have Twincast and Spellstaff you could cast an unlimited number of times in a turn)

As a request by the MP community, I have made all Kuriotates cities start as settlements (except the first one) in MP games, thus allowing you to decide if they are City or Settlement for yourself. AI continues to settle nothing but cities till the limit is met.

City Art Styles are maintained based on the City Civilization type, so the map should wind up looking pretty interesting, and if Decius has a good eye, he will know that the city he is about to take from Sabathiel is actually going to give him Balseraph UUs/UBs instead of Bannor ones.
 
As a request by the MP community, I have made all Kuriotates cities start as settlements (except the first one) in MP games, thus allowing you to decide if they are City or Settlement for yourself. AI continues to settle nothing but cities till the limit is met.

Thanks for the change. That said, it occurs to me that it could be advantageous for the AI to always settle as Settlements. That way you could give the spell Promote Settlement some AI requirements that would prevent the AI from making cities too close together. The Kuriotate AI really tends to spam cities closer together than they should be, and a bit of code that only lets them upgrade settlements that are a certain distance from a real city might help them quite a bit.
 
True, would be a good idea overall, especially since then we would have to make sure that the AI actually DOES promote settlements. Last I heard someone was complaining that the AI doesn't do so and can be reduced to having tons of settlements, but only the Cap as a city.
 
True, would be a good idea overall, especially since then we would have to make sure that the AI actually DOES promote settlements. Last I heard someone was complaining that the AI doesn't do so and can be reduced to having tons of settlements, but only the Cap as a city.

They should upgrade any settlement that has a unit in it, whenever that unit is considered for movement. I think the problem may lie with the AI skipping over some units that it considers "purely defenders" and leaves them fortified in place rather than considering casting the Settlement-Upgrade spell.

(I toyed around with this one a while ago when I was trying to play Kuriotates in MP)
 
Further reduced animal spawn rates in the water, and also split iWeaponTier into iWeaponTierMax & iWeaponTierMin. This allows you to generate new weapon tiers more easily. So you could have Melee using metals from tier 1-5, Mounted using Mounts from Tiers 10-15, Archers using Bows from 20-25, and Arcane using Staves from 30-35. Should someone want to that is ;)
 
Had some time between classes, so I programmed something that I wanted to do a LONG time ago, but hadn't gotten around to (unfortunately that means I didn't program the thing that I really want, the thing that I really like, or the thing that I really need).


Also, the first post has finally broken the character limit, so I clipped the Mods from other users into the second post. Will probably have to move even more the next time I do a major update, or clip a lot of the information, but I would rather avoid that if I can.


Anyway: The new fields/abilities are....

PROMOTION DURATION!

This can be set via PromotionInfos, SpellInfos, or Python. Spellinfos overrides any value set in PromotionInfos, and python does whatever python wants.


Duration will not count down while a valid caster is in the stack, and if the promotion has a chance to expire, that chance becomes active only after the duration hits 0 (otherwise when duration hits 0 the promotion is removed). Currently you cannot refresh a promotion before the promotion fully expires (so if you set a promotion with duration of 10, you cannot restore the promotion when the duration is only 2, you have to wait for it to expire, then restore it)


The current test promotions I set up to use this are Hasted being set via SpellInfos to use a Duration of 1, meaning that if the caster hits a stack and they go walking off like normal, the spell works just like now. But if the caster stays with the stack, they stay hasted forever. Obviously this means that the Adept who has Body I will always be hasted as he is always in his own stack. Anyway, this one is set by spell because Hasted is also applied to Centaurs with the spell Sprint. That one doesn't set a duration, so for them Hasted still only lasts for the single turn. But I modified Sprint a bit as well (more later).

The other trial promotion is Dance of Blades. This one I set by PromotionInfos, so now anything that grants Dance of Blades will grant the promotion for a single turn, unless a unit on the tile is able to cast the buff, then it remains till a turn when that unit is not around.



So, more on Sprint. I removed the application of Fatigued that this spell included. Instead I made Hasted apply Fatigued naturally as a <PromotionDegrades> field. So now ANY unit that loses Hasted will gain Fatigued, even if you gained Hasted by the spell Haste, and even if you lost Hasted by the spell Slow. I feel this is justified because now a unit could be hasted for 50 turns running without micromanagement, so having to deal with a 50% chance to wear off per turn -10% strength is quite worthwhile. And I wanted to use the new field :p


THINGS YOU CAN DO:

So, nifty things you can do with this new field:

Have a spell apply a Promotion that doesn't actually do anything, but has a duration of 10, and degrades to a spell that DOES do something.

Have a spell provide a promotion that already exists (like an item) for a limited period of time. Thinking of that... I need to block promotions with durations from being treated like normal equipment... that could be a bit tricky. So just don't use items in this manner for the time being :p I guess the best approach would be to make certain that the unit which spawns has the same duration as the promotion had, and that when the unit is "picked up" that the duration goes with it. Last part is in python though, which is what makes this a messy thing to clean up. Eventually I intend for all Equipment to move out of python, as it is a HUGE chunk of code for a relatively simple function.



Anyway, new toy... have fun playing with it when next version is out.
 
This just occured to me: Is there a way to make a promotion-granting spell target differently than the prereqs for the promotion? For example, if I wanted to make a Charm Animal spell that worked like Charm Person but only targeted Animal and Beast units, would there be a way to do that without python or making a new promotion?

If not, is that something that could be added?
 
I think a tag that made a spell only effect units with certain promotions could be very useful. It could make spells like Destroy undead and revelation be xml only.

I also think that there should be a tag that makes the caster immune to any effects of the spell.

I still think it would be cool if the xml could pass a list of valid targets to python to avoid the need for complex loops in python, but that might be a bit difficult.
 
Agreed, agreed, and agreed. :)
 
Top Bottom