Mod-Modders Guide to Fall Further

[Sephi]

yeah, that's the tricky part. I would keep the 5% damage formula and add a diminishing returns mechanism.
if current xp < 20:
xp gain = xp gain * (20-current xp)/20
elif
xp gain = 0.1

It guess it would be a bit more like passive xp gain from training then. The idea to also base it on handicap sounds interesting. A tag rangedcombatxpcap or so could be added to CIV4HandicapInfo. Now I just need to figure out how to do that

 

[Thunder_Gr]

Is there a way to test for a specific promotion from within the .DLL?
My searches so far have only found itterations through the list of promotions and checks against a specific field.
What I want to do is find out if pLoser has "PROMOTION_ELF" and, if he does, I want to give the winner "PROMOTION_ELVEN_OFFENCE_VETERAN".

I have found a few occurances of giving a promotion to a unit, and I was surprised to find out that the promotions' name were reversed(?). For example, instead of "PROMOTION_MUTATED" it was "MUTATED_PROMOTION"...I can say I also tried this method, but no luck so far...

It hurts when you do not have a complete API at hand...

 

[Vehem]

Is there a way to test for a specific promotion from within the .DLL?
My searches so far have only found itterations through the list of promotions and checks against a specific field.
What I want to do is find out if pLoser has "PROMOTION_ELF" and, if he does, I want to give the winner "PROMOTION_ELVEN_OFFENCE_VETERAN".

I have found a few occurances of giving a promotion to a unit, and I was surprised to find out that the promotions' name were reversed(?). For example, instead of "PROMOTION_MUTATED" it was "MUTATED_PROMOTION"...I can say I also tried this method, but no luck so far...

It hurts when you do not have a complete API at hand...

It's possible, but it's against the design convention that has been adopted for both FfH and FF (basically - no hardcoding of elements in the DLL to rely on anything in the XML).

===

To do it however, just use GC.getInfoTypeForString("PROMOTION_NAME") as you would in Python.

===

The example given (MUTATED_PROMOTION) is the work around used - the only things the DLL truly relies on are defined as GlobalDefines - MUTATED_PROMOTION will have a value referring to "PROMOTION_MUTATED", so when the game asks the XML what the MUTATED_PROMOTION is, it can get an actual promotion back, without ever actually referring to it directly.

	<Define>
		<DefineName>MUTATED_PROMOTION</DefineName>
		<DefineTextVal>PROMOTION_MUTATED</DefineTextVal>
	</Define>

It's a bit weird, but it's a good way to do it in principle.

===

Personally I'd say what you're suggesting would be far better implemented as a PostCombat Python script attached to PROMOTION_ELVEN

 

[Thunder_Gr]

It's possible, but it's against the design convention that has been adopted for both FfH and FF (basically - no hardcoding of elements in the DLL to rely on anything in the XML).

===

To do it however, just use GC.getInfoTypeForString("PROMOTION_NAME") as you would in Python.

===

The example given (MUTATED_PROMOTION) is the work around used - the only things the DLL truly relies on are defined as GlobalDefines - MUTATED_PROMOTION will have a value referring to "PROMOTION_MUTATED", so when the game asks the XML what the MUTATED_PROMOTION is, it can get an actual promotion back, without ever actually referring to it directly.

	<Define>
		<DefineName>MUTATED_PROMOTION</DefineName>
		<DefineTextVal>PROMOTION_MUTATED</DefineTextVal>
	</Define>

It's a bit weird, but it's a good way to do it in principle.

===

Personally I'd say what you're suggesting would be far better implemented as a PostCombat Python script attached to PROMOTION_ELVEN (though that would require that you enable post combat python for promotions, which isn't a bad thing to have really)...

Thank you for the information. I am glad that you pointed out the suggested way to go for the idea. I also prefer to impement it in python, rather than hardcode it in the .dll.

Having to code the xml tags and the combat-related adjustments should be enough for now. Since there is a way to leave something out of the .dll, I will gladly go with it!

I just hope I can access the winner from the PostCombat of the loser...

 

[Vehem]

Thank you for the information. I am glad that you pointed out the suggested way to go for the idea. I also prefer to impement it in python, rather than hardcode it in the .dll.

Having to code the xml tags and the combat-related adjustments should be enough for now. Since there is a way to leave something out of the .dll, I will gladly go with it!

I just hope I can access the winner from the PostCombat of the loser...

Just looking at it at the moment, I can't see the PromotionPostCombat tags in the Schema. I know they were initially added with the Broader Alignment code and the Python appears to be there, but not sure what the state of things is with the XML. Might be one for Xienwolf to comment on more than me...

 

[xienwolf]

They are in the schema, just not in the TestDummy promotion layout. And not arranged in my standard method (alphabetized near the top). So you can use them now, but if you do I'd advise you move them up with the other new fields alphabetized, because next patch that's how the default schema will be set up.

 

[Vehem]

And not arranged in my standard method (alphabetized near the top). So you can use them now, but if you do I'd advise you move them up with the other new fields alphabetized, because next patch that's how the default schema will be set up.

That might be what threw me, though I suspect I was just being dense. Looked through the PromotionInfos list, didn't see them. Did a search for "PostCombat" and only saw the other ones for some reason.

They are actually there though - so no idea what was wrong with my eyes

 

[Thunder_Gr]

Anyway, I will have to either go as it is now, or wait for the next patch. I would have to adjust after the patch anyway, since I have added 2 tags and changed 5(or 6) methods of CvUnit, including changes in the parameters(and thus in the header file).

However, I will have to either go with the Global Defines or python, but in order to do it in python I will have to be able to manipulate the winner unit from the defeated unit's post combat event...
I haven't yet modded anything in python, so, I am blind there for the time being.

 

[Vehem]

However, I will have to either go with the Global Defines or python, but in order to do it in python I will have to be able to manipulate the winner unit from the defeated unit's post combat event...
I haven't yet modded anything in python, so, I am blind there for the time being.

For the PostPromotionCombat python entries, you get "pCaster, pOpponent, eProm" to work with (the unit with the promotion, the opponent and the promotion itself).

 

[Thunder_Gr]

For the PostPromotionCombat python entries, you get "pCaster, pOpponent, eProm" to work with (the unit with the promotion, the opponent and the promotion itself).

Thats great! Exactly what I needed. One more problem solved!

Now, I don't suppose you have implemented a counter of sorts that lets you know how many units of each race the unit has killed....So, it seems I have to implement this, also .

 

[Valkrionn]

Feats apply separately to each civ, correct? Want to make sure before I put in my event.

 

[Vehem]

Feats apply separately to each civ, correct? Want to make sure before I put in my event.

Each Player - which is pretty much the same thing in most cases.

 

[Valkrionn]

Actually what I meant, so that works. Now I just have to figure out how to make it give you a choice between options... Gotta look at the way other events are coded.

 

[Sephi]

Is there a way in python to find out if a unit is summoned or not?

 

[xienwolf]

check if getMasterUnit() provides a valid unit pointer would probably be easiest. That covers you for permanent and temporary summons alike. If you don't mind ignoring permanent summons, check if the getDuration() response is non-zero.

 

[Sengir]

Sorry, posted in wrong thread.

*mutters to self about too many open tabs*

 

[Sephi]

check if getMasterUnit() provides a valid unit pointer would probably be easiest. That covers you for permanent and temporary summons alike. If you don't mind ignoring permanent summons, check if the getDuration() response is non-zero.

thanks

 

[Thunder_Gr]

Can you please tell me why only 68 out of 189 .cpp and .h files are included with the latest patch of FF?
The dll folder of the FF directory contain only these files. Is this intended? Shouldn't this folder always contain the full FF build?

 

[Thunder_Gr]

Two questions.
1)Is it possible to have a unit summoned by a spell that will die if the caster leaves the tile? Basically, what is done for the buildings in a city, but for units instead.
2)I have created diverse lines for the spell spheres. The choice(offensive or normal) is done at level 1. Everything works perfectly, as long as there are no multiple mana for the specific sphere. If there are, e.g. 2 mana sources for fire mana, the newly created adept gets Fire I automatically, and does not allow for Fire I Offensive to be selected... Any suggestions for a way around it?

 

[xienwolf]

The DLL folder wasn't included as part of the initial download (050 unpatched), but was in our repository. So the automated packing program used to generate the patches didn't include any of the files which weren't changed since that release I imagine.

I'll post the current repository source code, pretty sure nobody has committed any changes since the patch released.