Mod-Modders Guide to Fall Further

since doTurn doesn't push any Missions I think it only covers it if the Summons are created in the doTurn loop.
 
Most lair spawns do consider the terrain, since they are handled in python. Those few which don't yet can be tweaked easily. Unless you mean the actual spawning OF the lairs, not FROM the lairs. That one I also had planned on.
OF is the one I meant. Still, even without it lair spawning is a great thing.

Unfortunatell, I have run into a few more problems.

Does BarbarianCivilization tag need any other code to work properly? I have imported every instance of 'BarbarianCivilization' from CvInfos.cpp, CvInfos.h, CvPlayer.cpp and CyInfoInterface2.cpp. It compiles fine, I have added required schema and info in Goodyinfo.xml, but still if I get any goody that wants to spawn barbarian unit, I get CtD.

Also, I did not test it in FF, but bExplorable tag makes AI explorers coming to the marked improvement. That is intended I think, but as lair exploration is limited both in sdk and in python for security reasons, explorers are stuck near the improvement...
 
I had crashes on that one for quite a while myself. The final wording is fairly rigid in being written as it is (ie - I fiddled with it a LOT and suddenly it worked fine for me)

Main functions that were important for this were:
CvPlayer::doGoody
CvPlayer::canReceiveGoody
CvPlayer::receiveGoody

If you have everything relevant from each of those, then something else must be wonky... Do you have WinDbg set up to analyze your crash reports? Really comes in handy as SOMETIMES it tells you exactly where the code broke. Alternatively, if you can reliably reproduce a crash, load up a Debug DLL and it should let you go to the broken code location instead of crashing.

The bExplorable Tag is SUPPOSED to only act as a lure when the lair fits the requirements to allow the AI to explore them. But I have also seen some scouts get caught moving back and forth on a lair, so something isn't quite kosher in the end. Probably an easy fix of just reminding one portion of the code in the DLL what limitations I set up in Python. Mostly it works by messing with CvPlot::isRevealedGoody() (Which only UNITAI_EXPLORE units actually bother with, so the other function I slipped in there... picking up dropped equipment... doesn't always work so well since eventually the AI doesn't bother to maintain any UNITAI_EXPLORE units, or they might all just be too far away, thus Orthus's Axe sits 1 tile outside a city...)
 
Is there something in the dll that could force Bhall units to seperate groups? I let some Bhall dragonslayers spawn and they sometimes seperated their group. When I changed their Owner to Agares the dragonslayer group didn't seperate again.
 
They were standing on a mana node (I don't think that counts as a lair). It was pretty weird as it happened only for Bhall and only for living units (monks, dragonslayers, but no elementals). They used a custom UNITAI all they should do is to push a SKIP MISSION. Probably some secrets in the dll I haven't figured out yet :lol:
 
If you have everything relevant from each of those, then something else must be wonky... Do you have WinDbg set up to analyze your crash reports? Really comes in handy as SOMETIMES it tells you exactly where the code broke. Alternatively, if you can reliably reproduce a crash, load up a Debug DLL and it should let you go to the broken code location instead of crashing.

It seems I got everything :(. Thanks for the tips, I will try to find the cause.
Unfortunatelly I can't make a debug dll - file limit exceeded warning during debug compilation. No idea how to fix it
 
Apinterface is fine, it is cityinterface that gives that error

But I have just replaced it with base FfH file (do not need stop growth function for goodies)

Here is what I got at the goody hut crash
Code:
Assert Failed

File:  e:\orbis\sdk\cvgamecoredll.041\cvglobals.cpp
Line:  1213
Expression:  eCivilizationNum > -1
Message:
And then it crashes...
Checked cvglobals.cpp and this part is the same in FF and in Orbis
:confused:
 
Would need to see what your CvGlobals is at that point, but I bet you haven't touched that part of the code. Something called TO that part of the code with an invalid number. I am guessing that is:

Code:
CvCivilizationInfo& CvGlobals::getCivilizationInfo(CivilizationTypes eCivilizationNum)
{
	FAssert(eCivilizationNum > -1);
	FAssert(eCivilizationNum < GC.getNumCivilizationInfos());
	return *(m_paCivilizationInfo[eCivilizationNum]);
}

So you need to see your stack trace so you can know who tried to get Civilization Information for an invalid Civ and it will probably become pretty obvious (so when that assert fires, choose to debug it (with debugger attached) and then look for a tab called "Stack" and the top line should be CvGlobals::getCivilizationInfo, look at the lines just below that to see where this function was called from, click on them to look for a point in the code which might have selected an invalid Civ.
 
So, i was looking through the UnitInfos and found that both bears (polar and normal) have no UnitTier. Is that just an oversight or does it serve some function?

And if you don't set a tier, to what does it default? 1? Or zero?
 
Finally found it :)

I did not include a new goodyinfo reference in CvXMLLoadUtilitySet.cpp
Thanks a lot for all the help, Xienwolf !!!!
Goodies work, I know a few more things of debugging and fixed a few small bugs as well. :D:D:D
 
Back
Top Bottom