Mod-Modders Guide to Fall Further

Spoiler :
Code:
def atRangeCitadel(pCaster, pPlot):
	iPlayer = pPlot.getOwner()
	pPlayer = gc.getPlayer(iPlayer)
	eTeam = gc.getTeam(pPlayer.getTeam())
	p2Plot = pCaster.plot()
	if eTeam.isAtWar(pCaster.getTeam()):
		if pPlayer.isHuman() == True:
			if pPlot.getNumUnits() != 0:
				pCaster.doDamageNoCaster(20, 40, gc.getInfoTypeForString('DAMAGE_FIRE'), False)
				CyEngine().triggerEffect(gc.getInfoTypeForString('EFFECT_PILLAR_OF_FIRE'),p2Plot.getPoint())
		if pPlayer.isHuman() == False:
			pCaster.doDamageNoCaster(20, 40, gc.getInfoTypeForString('DAMAGE_FIRE'), False)
			CyEngine().triggerEffect(gc.getInfoTypeForString('EFFECT_PILLAR_OF_FIRE'),p2Plot.getPoint())

Still not working. I know it's the CyEngine line specifically that is failing, as if I put it above the damage, it fails to run and the unit is unharmed.
 
WOOOOT! Got the effect to trigger. I was on the right path when I realized that pCaster.getPlot() is invalid. I changed it to pCaster.Plot() like Magister suggested, and it still failed... Turns out I left a parenthesis in there from the previous version. p2Plot().getPoint() instead of p2Plot.getPoint()..... Everything works now. :goodjob: Thank you all for putting up with me.
 
I don't suppose there's a simple way to do a python check to determine how many of a player's given cities are coastal (or even better, have water tiles they can work)?
 
From a python reference webpage:

BOOL isCoastal(INT iMinWaterSize)
bool (int) - is the city on the coast?
 
Okay, looked a little more at CvCity.cpp, and the memory leak fix is pretty straight forward - since I had to move some initialization code around, I'll just attach the new version here...
 

Attachments

Mildly curious why you didn't move Proximity Culture and Diplo along with all of the others in that change. Just because those 2 don't reserve new space in ::reset, correct? I am trying to remember if there was a good reason for me to bother with the !bConstructorCall at all on the other arrays (and subsequent re-allocation of memory space), or if I just hadn't known what precisely I was doing at the time and was just seeking to copy what I had seen elsewhere.
 
I want to start a new mod, (what a surprise now, eh?), and I need to expand the XML functionality. More specificaly, I need to allow strength increase against SpecificPromotions in PromotionInfos.XML.
As it is now, there is only an ipromotioncompatmod(IIRC).
I want to add ipromotionstrengthmod and ipromotiondefencemod as well.

Instead of trying to figure out by myself all the places I need to edit in the SDK to make this possible, I was wondering if someone could point me the standard procedure of doing this sort of thing?(Although I know it is not as easy it may sound. I would really appreciate if someone could take the effort of pointing me out how to do it.)
 
Check the Idiot's Guide. I haven't had time to write up integers yet, but the basic procedure is the same for everything you add to the XML, so the Boolean walkthrough should be plenty to show you the boring Robo-code requirements.
 
Mildly curious why you didn't move Proximity Culture and Diplo along with all of the others in that change. Just because those 2 don't reserve new space in ::reset, correct? I am trying to remember if there was a good reason for me to bother with the !bConstructorCall at all on the other arrays (and subsequent re-allocation of memory space), or if I just hadn't known what precisely I was doing at the time and was just seeking to copy what I had seen elsewhere.

Yep - m_afProximityCulture & m_afProximityDiplo are always allocated with a const size (MAX_PLAYERS), so you don't need to worry about destroying them & reallocating them in the reset() function (which they weren't). Your other newer vars, however, like m_pafPotencyAffinity, are allocated with GC.getNumBonusInfos() for their size - while this doesn't seem to change, it could in theory, hence the need to deallocate them in the uninit() and realloc them in the reset() call.
 
4 New tags in Promotions, the first 3 copied into Units as well.

<bCommunalProperty> - No Active Pieces in the DLL yet. Just placing the tag so I can test things in python to figure out precisely how I want it to work. Eventually this tag will be used to allow all players in the game limited control over the identified units.


<bBlind> - Prevents the unit from granting visibility on any tile (even the one they occupy). You lose control of the unit if you lose sight of it, and cannot willingly move it into a tile you cannot see. As long as OTHER units grant sight to any given tile, this tag has no real effect. Right now I placed this on Fireballs so they can't scout anymore. Eventually I imagine someone will attach this to BlindingLight (could be effective, makes it a very defensive spell too, since it is useless to blind someone in their own territory). Would be interesting attached to a worldspell as well.


<bNeverHostile> - The unit can NEVER wind up in combat. All units in the game will happily share a tile with it. I slapped this on Loki. Now they only way to kill him is with magic, not sure if there are any spells which you can be assured of doing enough damage to kill with though, most have damage limts. His puppet gets the same tag unless somoene changes that before we release. But the puppet is now permanent (sorta), so you won't get spammed by Loki puppet summon sounds all the time.


<PythonOnRemove> - Python function is called before the promotion is actually removed from the unit, but only when it successfully SHOULD remove. Return a value of 1 to prevent removal of the promotion. Warning: If the promotion HAD a duration, it will now have a duration of 0, so needs a new one assigned if you intend to leave the promotion on the unit and want it to continue acting by delay. You can use pUnit.safeRemovePromotion(iPromotion) to prevent this python call from being made (as well as preventing DamageOnRemove and PromotionDegrade)



Seems I also never posted the iDamageOnRemove tag. It just does the listed quantity of damage (percentage basically) to the unit when the promotion is lost. It can kill units
 
<bNeverHostile> - The unit can NEVER wind up in combat. All units in the game will happily share a tile with it. I slapped this on Loki. Now they only way to kill him is with magic, not sure if there are any spells which you can be assured of doing enough damage to kill with though, most have damage limts. His puppet gets the same tag unless somoene changes that before we release. But the puppet is now permanent (sorta), so you won't get spammed by Loki puppet summon sounds all the time.

Making Loki Immortal? :confused: And the puppets permanent just to get rid of the sound? :confused: Just changing the sound for the puppet summoning shouldn't be enough? :confused::confused::confused:

EDIT: OK, I 've just read the post in the FFH forum that, propably, led to this solution for the puppets(I read the FF forum first)...However, if they cannot be killed...Oh, my..I think I will start removing the Balseraphs from my games...
 
The sound thing is a nifty side-effect. The main reason for changes on the puppet is quite different.

And Loki has always been effectively immortal. It just wasn't done right up till now. Killability isn't the primary aspect which has changed for him.

Unrelated to anything in the main FfH forums unfortunately, still haven't the time to catch up on all the posts out there.

I am curious why you are pluralizing "puppets." Only Loki's Puppet was affected.
 
The sound thing is a nifty side-effect. The main reason for changes on the puppet is quite different.

And Loki has always been effectively immortal. It just wasn't done right up till now. Killability isn't the primary aspect which has changed for him.

I see. You are right. He was effectivelly immortal, but you could, at least, force him out of the way...

Unrelated to anything in the main FfH forums unfortunately, still haven't the time to catch up on all the posts out there.

Really? A fine cuincidence, then! Anyone ready for any statistic calcuations proving the theories of propability wrong, again? ;)

I am curious why you are pluralizing "puppets." Only Loki's Puppet was affected.

Yes. Well, it seems I have connected puppets with Loki, mainly. You are, of course, right.
 
Is only Loki's puppet a permanent summon? I'd rather they all were. Fighting Keelyn gets really annoying otherwise.
 
Making the other ones permanent would be more balance junk which I don't care to get too involved with. But to highlight another piece of code I implemented quite some time ago I did assign all illusions and puppets a 15% chance to miscast (the piece of code I implemented was to cause miscasting to block your ability to cast for up to 3 turns afterward). Seems fairly fitting and potentially balanced.

Making other puppets permanent seems like a PITA to me though, as once you gain a new promotion on your mage you'll want to delete the puppet he summoned to provide the new upgrade to him as well. Though with the Master/Slave buttons it is trivial to figure out WHICH puppet to kill I suppose. It would also be a bit of a newb-trap since a new player (even some experienced ones) wouldn't realize that you WANT to kill the puppets on a semi-regular basis to get the Feedback XP.
 
I'm not sure Feedback XP is mentioned anywhere in the pedia, readme, etc. I'm still not sure what summons give Feedback.
 
Back
Top Bottom