Mod-Modders Guide to Fall Further

Code:
for i in range(pUnit.countHasPromotion(iProm)):
    pUnit.setHasPromotion(iProm, false)

That strips all of the stacked promotions from a unit

Actually..... It does not. Here's the code I used (mostly, it's on a different comp)

Code:
for i in range (pCaster.countHasPromotion(iMechanosAffinity)):
      pCaster.setHasPromotion(iMechanosAffinity, false)

for i in range iNumRefinedMana:
      pCaster.setHasPromotion(iMechanosAffinity, true)

Necessary to strip/readd the promotions to account for lost/traded/gained mana.

Now, this appears to work... The promotion correctly applies the number needed. However, the EFFECTS of the promotion are never stripped... Leading to a rapidly escalating ranged combat on the unit. Going to try a While loop next, but any idea why the promotion is not removed correctly?

Edit: Alright. The While loop has the same issue, as does using the countHasPromotion tag to set the number to a variable, and use a For loop to remove the promotion once for each value in the variable... All methods APPEAR to work, but do not wipe the stats. Interestingly, while I have 3 mana in the test I am gaining 5 strength a turn... This implies to me that even via python, you can only remove one stack effect promotion a turn. Just to be clear, I got the display working through 5 different methods... A While loop, a For loop using the tag, the one Xienwolf posted, and two different ways telling the function to jump to a different function, remove the promotion, and jump back to the first one... Hence running over the jump tag if the promotion is still there. ALL methods had the same issue, so I'm pretty sure it's inherent in the code.

Looks like I'm going to have to revert to my initial system, kludge though it is.
 
Fun times. Just ran a simple test, and removing the stacked promotions results in ADDING the promotion, all except the last removal which properly subtracts it.


And the offending line?

iChange = ((isHasPromotion(eIndex)) ? 1 : -1);


Some genius decided to use a check if you have the promotion instead of the boolean value passed into the function for this vital portion of the code.
 
Is there any way to tell a unit's age in python? I want to use age instead of level to determine cultural boundaries for my fort commanders mod, but I looked in CyUnit.h, didn't see anything there...
 
Hey stars,

I'm looking for a way to make a summoned Tear become a minion of its summoner.
I'm planning on using the getSummoner() function, but it seems to gives an int. Then I would like to use the attachMinion function but it requires a real unit object to do so.

How can I convert the int into pUnit ? (please...)
 
The getSummoner() is Kael's field. Not sure why I bothered to import it at all. You want to use getMaster() and getSlave()

I checked these but they do not seem callable from python:

Code:
   CvUnit* getMasterUnit() const;

EDIT : 2 more questions:
+ Is Vehem still around (seems a very long time since seeing him) ?
+ Do you know what the game does in the Initialising phase when starting a new game ? Since I released the Tears the game sometimes hang until crash in this phase but I cannot see why...
 
Code:
        .def("getMasterUnit", &CyUnit::getMasterUnit, python::return_value_policy<python::manage_new_object>(), "CyUnit* ()")

THIS is the code that tells you something is exposed to python (CyUnitInfterface1.cpp), as well as what you need to include with the command. A comment in CvUnit.h doesn't mean anything at all (//Exposed to Python), it is just a handy reference, IF used correctly. I personally prefer not to spend the time writing those because they get in my way when editing things later (END key takes me far too far from where I want to edit)

LOTS happens during initialization. Figuring out a crash in that location is generally only done with a debug DLL
 
Code:
        .def("getMasterUnit", &CyUnit::getMasterUnit, python::return_value_policy<python::manage_new_object>(), "CyUnit* ()")

THIS is the code that tells you something is exposed to python (CyUnitInfterface1.cpp), as well as what you need to include with the command. A comment in CvUnit.h doesn't mean anything at all (//Exposed to Python), it is just a handy reference, IF used correctly. I personally prefer not to spend the time writing those because they get in my way when editing things later (END key takes me far too far from where I want to edit)

Ho.
That explains a lot ! :)
I'll check then.
I thought it was not the comment (please, I'm not THAT stupid ;)), but the red part:

Code:
	[B][COLOR="Red"]DllExport [/COLOR][/B]int getSubUnitCount() const;

My mistake.
LOTS happens during initialization. Figuring out a crash in that location is generally only done with a debug DLL

But I only changed XML and Python. Is any Python called in that phased ? Actually it seems to be a problem only for some mapscript.
 
Usually, a crash in Initializing relates to the mapscript, not to anything else you've changed. I suggest looking at the code for the mapscript that gives the error.

Actually, I guess theoretically code placed in onGameStart might cause errors during the loading of the mpa, but probably not at this stage.
 
DllExport exposes things to the EXE, opposite direction from python :)


Any XML data not shown in the Pedia is loaded while initializing the map, as well as the mapscript itself, and between those some python is called.

Ideally, if you haven't modified the DLL it is a simple matter of fixing some python changes or choosing a different mapscript (which is a funny way to say the same thing twice). But to figure out precisely what is causing things is where a debug DLL comes in handy, so you can fix instead of just avoiding.
 
DllExport exposes things to the EXE, opposite direction from python :)

Ok, fixed in my mind now :)


Any XML data not shown in the Pedia is loaded while initializing the map, as well as the mapscript itself, and between those some python is called.

It indeed depend on the map script.. But I would like the civ to work on all mapscripts.


Ideally, if you haven't modified the DLL it is a simple matter of fixing some python changes or choosing a different mapscript (which is a funny way to say the same thing twice). But to figure out precisely what is causing things is where a debug DLL comes in handy, so you can fix instead of just avoiding.

And comes the question : do you have a debug DLL ? :)
 
Yes, but just the debug DLL alone isn't the REALLY useful part, it is having your compiler linked to it so you can walk through the code. For that you need to have VS set up on your computer. It really isn't too hard though, just follow Refar's guide, but use the Makefile we distribute instead of his (guide linked in my Idiot's Guide thread)
 
I'll try to review the mapscript python first, and i'll go into debug if I have some long hours of free times...

Another issue, about the iCommandLimit tag. Is there a special restriction about using it ? As soon as I add it in one of my unit, the game crashes on game start, while without it works fine.
Do I need another tag along with this one in order not to crash ? :)

EDIT : ok it is the iCommandRange which is not defaulted ok when used in Module. Once I add the CommandRange it is ok
 
Back
Top Bottom