Big changes over the weekend. I added in many of the promotions from the design contest thread. (Note they might need to be balance tweaked, most of them pump recon and require a travelling zoo to be overpowered so I feel it balances out the metal weapon promotions). And most of them have good pics (pulled from the unit icons that provide them)

Also a major lightbulb went off I pulled all the variables into the class and set them as global variables to do all the gc.getInfoTypeForString() commands only once. This let me dramatically speed up the code so that on a large map it played much faster than a standard map before. This let me pull out most of the for i in (0, len(x)): code and replace it with if y in x: doubling the speed gains. This did cause me to pull all three major functions into one class so that all the variable would be set in one place.

I am still having trouble with the field commander creating an outpost. Everything seems to work, but I am having difficulty selecting a city for the commander unit to init in. I have left the code in, but commented it all out in case anyone has suggestions.

Still looking for good suggestions for promotions, but that is in the other thread. Cheers

PS, the files contain the code that should be inserted into the original files of the same name, and the pointers for where to insert it. The XML files can just be added below all the current unit/promotions.

For my own personal game of FFH I setup two python event functions that trigger onUnitMove and onUnitKilled:

1. Defensive Fire from archers and siege weapons. When an enemy unit enters your cultural borders, any archers or siege units in an adjacent fort (tower, citadel, etc) or city will fire and do damage equal to their level up to 30 points of damage. This is to improve the functionality of archers for defending cities.

2. By editing the two variables at the top of the file moveaid.py file you can have units give promotions to any units in the same tile as them. In my own game I setup Great Commanders to give a promotion I made that increases the XP gained from combat and reduces upgrade costs. Other examples could be to have rangers give a reduced movement cost or forest defense bonuses. Or setting up a flagbearer unit (like the Bannor one) that gives a morale like promotion or immunity to fear to units in it's own stack. The sky is the limit with units giving promotions.

Feel free to use these if you want. If you need help adjusting it for your game I can help you with modifying the code. Cheers.

Very nice - just looked at the code and it looks like a very simple to use, useful modcomp, that can easily be tailored to a lot of different purposes. That's my favourite sort of Modcomp :goodjob:

EDIT: Having looked a little closer, would it be better to change "PromotionList" and "PromotionGiver" to be a list of lists? More along the lines of

[[COMMANDER, PROMOTION_LED],[UNIT_ARCHER, PROMOTION_RANGED_SUPPORT]]

etc. rather than two lists that rely on their index. Might make it more readable and safer to mod with.

Pseudocode for accessing the list variables
if unittype = PromotionList[i][0]
ApplyPromotion(PromotionList[i][1])

Can moveaid.py also be used to give promotions based on terrain/features/improvement/cities on the tile? That would make it very useful.

Very nice - just looked at the code and it looks like a very simple to use, useful modcomp, that can easily be tailored to a lot of different purposes. That's my favourite sort of Modcomp :goodjob:

EDIT: Having looked a little closer, would it be better to change "PromotionList" and "PromotionGiver" to be a list of lists? More along the lines of

[[COMMANDER, PROMOTION_LED],[UNIT_ARCHER, PROMOTION_RANGED_SUPPORT]]

etc. rather than two lists that rely on their index. Might make it more readable and safer to mod with.

Pseudocode for accessing the list variables
if unittype = PromotionList[i][0]
ApplyPromotion(PromotionList[i][1])
I will try that out tonight. I am new to Python (just read a byte of python last Wednesday but have a background in VBScript for administration) so thanks for the tip.

For the terrain modification, it could be expanded to include a third variable in the list of lists i.e. [[COMMANDER, PROMOTION_LED, FORREST],[UNIT_ARCHER, PROMOTION_RANGED_SUPPORT, HILLS]] and throw in an additional if statements in the loop. I might play around with that. Also I am open to any suggestions for increasing the opp fire damage based on if it is a city, or having city defender and in a city, etc.

Neat. The only thing I'd worry about is that anything which is called onUnitMove can get pretty processor-intensive given the number of moves which are made (especially by the AI, which is a fan of totally unneccessary movement).

Neat. The only thing I'd worry about is that anything which is called onUnitMove can get pretty processor-intensive given the number of moves which are made (especially by the AI, which is a fan of totally unneccessary movement).
Unless you actually have a bunch of promotions setup it shouldn't get too bad (or you just need a faster computer) until much later in the game. I actually think the Ancient Forest/Treant mechanic has a similar cost on the processor. The logic flow for the treants is to check to see if the tile is an ancient forest, then rolls the dice, then checks to see if there is a temple in the nearby city, and only after that point checks to see if the tile belongs to an enemy.

Unfortunately I don't have the desire (or ability to download) to mess with the SDK at this point to attempt to speed things up.


NOTE: I updated the files in case anyone else wants to look at the changes.

NOTE: I updated the files in case anyone else wants to look at the changes.

Very nice idea adding the additional restrictions for unit-type and plot. I can see a lot of potential use for this now (even with the performance hit as mentioned - it's not ideal, but I think it's worth it).

Minor update today, changed the opp fire to properly alert the player on screen as well as the combat log. Also fixed programming error that gave city promotions everywhere.

I was thinking about a comment that someone made about workers providing a significant amount of the total moves in a given turn (at least mid game). I think I am going to put in code at the top of the chain to prevent it from starting if a worker unit is the one moving, but then I have to make workers immune to the promotions in the body of the code.

This should be my final release, yesterday I finished cleaning up, optimizing, and documenting the code and even ran two test games on a standard size map with four promotions setup to trigger.

I am not completely sure if the event notification works perfectly in multiplayer, but it works in single player mode. The rest of the code is bug free AFAIK.

At this point just for fun I will run a design competition on the main forum thread to ask for submissions for unit promotion combos. Then open it up for polling to bring some user input into the game.

Is anyone interesed in the further updates to these files? If anyone is interested I will put up the tweaked files. I did some further tweaking and playtesting over the holiday weekend (needed a three day weekend to get to it). It ran fine on my comp on a large map. P4, 4GB RAM Vista (hence I didn't setup modular loading).

Some of the further tweaks was fixing the same problem for oppfire I had with the promotions (i.e. it would give the fire if the unit was in a terrain with the same number designation the game gave to an approved improvement), and tweaked it so it wouldn't work for barbs at all.

Right now I am focusing my efforts on another modcomp. Namely I use the GG counter to generate a new unit "field commander". The number is changed by the traits the leader has (defenders get them sooner, raiders later) and I might make more modifications later (now that I think about it I should do one for mapsize and game length, but I only play epic and few map sizes). He gives off the promotion I used to have the GC give off and can transform into an outpost (a new improvement kills the field commander). I am still working on it, but it provides resources, will have another new unit that is only used to defend the outpost (cannot move and want to give it a bombard like ability, but I might just give it Fire II and Sorcery) and extends culture (ala final frontier starbases).

While I like the concept of stack promotions a lot, I'm not a modder myself and have no use for mod components. Still I'd hope that your ideas get incorporated into a module or different modmod (or your own, but I'm not quite aware of which one you are doing - have to take a look at the thread list again ;) ).

Is anyone interesed in the further updates to these files? If anyone is interested I will put up the tweaked files. I did some further tweaking and playtesting over the holiday weekend (needed a three day weekend to get to it). It ran fine on my comp on a large map. P4, 4GB RAM Vista (hence I didn't setup modular loading).

I've got my eye on these for a later stage of a new mod that I'm part of creating, so if you've got any updates - I'd love to steal them too :goodjob:

(well - steal with credit given :D)

I've got my eye on these for a later stage of a new mod that I'm part of creating, so if you've got any updates - I'd love to steal them too :goodjob:

(well - steal with credit given :D)
NP I'll put them up later today. I really want to try out some of the other people's mod-mods, but I have to wait until I am in a country where I can download things off the Internet (Ahh, only three more weeks until a vacation in Germany).

Good news, major speed update in the code over the weekend. I was able to replace most of the for x in loop statements with if x in y statements. Also pulled the gc.getInfoTypeForString() calls into global variables at the beginning of the game loading.

More details are in the initial post.

I'd like to try this mod but don't look forward to all the editing, especially since it would have to be done over for each patch. Could the XML files, at least, go into a Module? And the Event Manager has undergone so many changes that I would hate to have to make the six insertions over and over. How about giving us a file that's already got the edits?

I'd like to try this mod but don't look forward to all the editing, especially since it would have to be done over for each patch. Could the XML files, at least, go into a Module? And the Event Manager has undergone so many changes that I would hate to have to make the six insertions over and over. How about giving us a file that's already got the edits?

AFAIK the python has to be inserted each time, at least into the event manager. I am familiar with the modular loading concept, and will try to set it up as modular over the weekend, but from what I heard, it doesn't work with Vista. OTOH, there is no way to find out unless I try.

Once Kael has a final version out, I will likely release a full pack that includes the python files already modified. With how often Kael does updates it would be silly to release one now. (I don't even have access to the latest version).

AFAIK the python has to be inserted each time, at least into the event manager.

I think what you've done - provide the code to be cut-and-paste - is almost as good as a module. Maybe provide a "for dummies" readme file, though, spelling out exactly what needs to be done? Something stating what each file does, suggesting where it be inserted - or making explicit that it doesn't matter...

I haven't looked at exactly what you have done, but I would venture that your XML is best off not being Modular. Since people have to edit files already anyway they may as well edit a couple more. Some of the tags don't work right with Modules, and in general they are the more flavorful ones which Kael added to FfH (so for example, all of the Pre-reqs in a promotion, as well as the Combat Apply and Random Apply).

I think what you've done - provide the code to be cut-and-paste - is almost as good as a module. Maybe provide a "for dummies" readme file, though, spelling out exactly what needs to be done? Something stating what each file does, suggesting where it be inserted - or making explicit that it doesn't matter...

No doubt I qualify as a dummy, but the instructions are perfectly clear to me. I just don't look forward to having to redo the changes every time a patch comes out.

I suppose I'll go ahead and make the edits, just to try out the mod. When the next patch comes along, I'll decide whether it's worth it to redo them. If not, I'll just wait for something like a final version.