help! barssom needs a debug help!

[keldath]

hey all,

wow detailed analasys

I use 2010. Maybe it works better because I never had this problem when I compile myself.

perhaps ill install this on eas well.

I think it is unrelated to when the paratroopers appear. An unbuggy DLL should support them being there from the start. THe question regarding being present prematurely was more aimed at the statement that there were no paratroopers as they haven't been invented yet. If the AI thinks it has paratroopers, but haven't invented them yet, then it sounds like a bug. Is it a crashing bug? Maybe, but I prefer bugfree code, which mean even if I hunt one bug, I write about any bug I notice along the way.

so wierd, how the ai can think that para havnt been invented yet? so wierd to me.

Generally speaking it would be good not to use WB when stability testing.

i didnt know this. ok.

I think it is related to CvPlot::doTurn(), which is called for all plots each turn. However it isn't a vanilla function and I never used it myself. My guess is that it more or less doubles as the function I wrote CvPlayer::canUseBonus(), which tells if the player has invented and not obsoleted the bonus in question.

well m what ever it does - it probably wont crash the game atleast...

Still it looks like I will have to give it a try because... well who else will do it? Clearly the mod is more or less doomed if it has an unsolved crashing bug and it really deserves better than that.

thank you
i sure did pur hundreds of hours into it and i wanna develop it much much more. but i cant now ...

during the auto play - i noticed gere and there more errors - some i was accuallty been able to fix using the debug. some , not.


i have tried running the mod on pure kmod dll, and it showed no crash, so,
my guess, is that something i added over kmod screwes that up, or something in the xml wont work well with one of the componants.
although i havnt made thorou tests on pure kmod - mayve you can compare them both to have some idea (its availble in the kmod thread, ill link you up if you need)


isenchine ,
i read it, bu ti didnt know much how to implement it. and if it related to my problem. thanks anyways.

 

[isenchine]

Nighttingale, you assume there is a bug in the dll code but it wasn't changed by keldath. The only change dates back to BBAI (with the if (NO_BONUS != pLoopPlot->getNonObsoleteBonusType(getTeam())) thingy).

It might very well be that something is contradictory in the xml. The UNITAI_PARADROP is a very special one and maybe it does not accept certain combinations.

Not all 8 UNITAI_PARADROP units have the same statistics - some have:
CanMovePeak
bMechanized
bHiddenNationality
bAlwaysHostile

I would first put all these tags to normal and see if there is a problematic one. Keldath, test them all one by one. Of course, they might be OK in the end.

I don't understand C++ enough to say if other xml entries are implied: plot? bonus? This is a Sci-Fi Mod!

 

[isenchine]

i have tried running the mod on pure kmod dll, and it showed no crash, so,
my guess, is that something i added over kmod screwes that up, or something in the xml wont work well with one of the componants.

TLOTags?

 

[Nightinggale]

Nighttingale, you assume there is a bug in the dll code but it wasn't changed by keldath.

The bug might be in the DLL and it might not be. It reveals itself in the DLL, which is why it makes it a good place to investigate what goes on. If the cause is an illegal XML combo (likely), then the DLL is flawed in the sense that it crashes rather than complain about it. Generally speaking DLL files makes way too few sanity checks on XML files for my liking and we can avoid a lot of bug hunting if the DLL went out and said "no good" when you enter an illegal XML setup rather than just misbehave and possibly crash later on.

The worst XML error I have had was a missing unit and it was missing due to nameclash with another XML file. Sure it was an XML issue, but it was a broken unit and it wasn't due to the unit XML. While it wasn't the fault of the DLL, getting the DLL to complain about that has caught a few similar cases right away with nearly no work.

 

[isenchine]

Right, but the DLL does complain with the Assert: FAssert(iParatrooperCount > 0);

because it will divide something with this value and knows that it will crash if iParatrooperCount = 0. (right?)

So, how come that

int iParatrooperCount = plot()->plotCount(PUF_isUnitAIType, UNITAI_PARADROP, -1, getOwnerINLINE());

returns 0?

I don't get C++ enough. plot problem? unit problem: if yes, how?

I'm sorry if this derails the conversation than rather helping it. I also try to understand for myself...

 

[keldath]

ohh thats a nice debate growing here

i indeed added some tlo tags - but i don tuse them in the xml.

isenchine ,
you said some logical stuff, maybe theres som ebad combo in those units.


Nightinggale is probably right that the investiogation is from the sdk.

like i said - the kmod core - i think is ok and has no crash, just some python error.

you guys are both right,
isenchine dont be sorry, its good to raise ideas , with the help of the two of you, im starting to feel optimistic....maybe.....i wont have to move on

 

[keldath]

hey guys,
well, you guys are positively correct, it is the paratrooper units.

after xml manipulations, i found that once i put a drop range values > 0 - theres a crash.
i dont know why this happens - any thought? got som eleads to where in the sdk lies the problem?

 

[Nightinggale]

I did some debugging and this is what I get so far:

• There is a unit of type UNIT_PARATROOPER2, which tries to attack_move
• Attack move for paratroopers counts the number of units on the plot with UNITAI_PARADROP
• The unit in question has UnitAIType UNITAI_ATTACK instead of UNITAI_PARADROP
• The code divides with the number of attacking units (which in this case becomes 0)
• <DefaultUnitAI>UNITAI_PARADROP</DefaultUnitAI>
• UnitInfo correctly states that DefaultUnitAIType is 40 (UNITAI_PARADROP)

Now the question is why isn't it using the default AI type

Totally unrelated, but for the same unit:
<Civilopedia>Oolas are an extremlty fast units that seem like they jumpt from place to place.</Civilopedia>

 

[Nightinggale]

I can only see two ways to change the default UnitAIType from UNITAI_PARADROP to UNITAI_ATTACK. One is grouping the unit together with another unit, which has UNITAI_ATTACK type (I'm not completely sure about this one). The other involves the menu in World Builder.

I would go as far as to say this bug too is a result of WB. Try starting a new game, don't use WB at all and see if it will ever crash again.

with the help of the two of you, im starting to feel optimistic....maybe.....i wont have to move on

Maybe I shouldn't try to fix this. If you have to move on, then there will be a free modder to lure into colonization modding

 

[keldath]

hey man,
it seems, that the drop range causes the error, ive ran more turns without it, seemed fine.

i starting to think that its one of the things i added in, i will start striping parts form the sdk.

tlo tagsadds something that has to do with drop range, maybe its related.

i will make more tests without the wb, and upload save game if i still have ctd.

i wonder how did you understand that its the paratrooper2 unit... i need to learn how to debug.


hehehe, tell you the truth, i never enjoyed colo, it board me, i will either continue here or civ5,

thank you for all the help so far,
i will report back after some more tests, and if you get some more insights ... that would be awesome as well.

 

[Nightinggale]

i wonder how did you understand that its the paratrooper2 unit... i need to learn how to debug.)

Once you have the pdb problem solved, you gain access to the variables as well. The window locals shows the local variables and the first one is this, which is the object in question. This makes it a question of just opening this and follow the pointers until you access the data you want. In this case it is this->CvUnit->m_pUnitInfo->CvHotKeyInfo->CvInfoBase->m_szType. That variable is a clone of Type from XML.

Yeah you really should learn how to debug. It is quite useful and in the simple form, you see content of variables. A bit more advanced you edit content of variables and look at how the game run line by line to see how it behaves at if statements and such. It really reveals everything, but it might take a bit of skill to make full use of it.

hehehe, tell you the truth, i never enjoyed colo, it board me, i will either continue here or civ5,

It was a joke. To tell the truth, vanilla made me forget about colonization for quite a while and I haven't played vanilla in ages. It doesn't live up to the quality of civ4 itself. However it has amazing modding potential and the few active mods today are quite interesting.

 

[keldath]

bahh another crash paratroop related, very very late in game, but still.

maybe ill install vcs 2010,
right now civ5 bnw, is starting to lure me. maybe time to tell civ4 bye bye.
im tired of constant ctds



ye i had very high expectation of col, i played it, but i got board of the ai there. to bad.


maybe ill play civ 3

i gave so much time on barsoom, makes me very sad to abandon it.

 

[Nightinggale]

i gave so much time on barsoom, makes me very sad to abandon it.

Then don't abandon it. If nothing else, then edit CvUnitAI::AI_paradrop()

int iParatrooperCount = plot()->plotCount(PUF_isUnitAIType, UNITAI_PARADROP, -1, getOwnerINLINE());
if (iParatrooperCount == 0)
{
    return false;
}

That will shield the game from this crash. I'm not sure about AI behaviour, but at least it will not crash.

Most likely the real solution would be to look at CvUnitAI::AI_setUnitAIType(). It's working perfectly, but something is calling it incorrectly. Insert a breakpoint, which triggers if old type is UNITAI_PARADROP and it will reveal where in the code the AI decides to change the type. Possibly it would make sense to add an assert here for just that purpose.

 

[keldath]

well,
ill see what happens buddy.

ill try to implement this.

i think ill take a break of a few days and go play some civ5

on the week end ill give it a go and recompile it .

thank you for all youve done my friend, much much appriciated . you have indeed helped me a lot.

 

[isenchine]

I'm refering to what you said in the Barsoom thread. Can you be more specific about what you found out concerning the bug(s) or are you being superstitious about it?

 

[keldath]

hehehe .. hi, nope not supersticious,

after i removed the paratrooper units, i ran a few games - and i noticed a ctd, extremley late in the game, pasr 100+ future techs.

on the debug, it refered me to the defines.globals.
i compared the code to vanila - the file globaldefines - and i noticed a few parts (1-2) were missing, also i changed some attributes. and after that, i was able to ran a full game.

today, ill try to figure out which line was missing and caused a crash, my guess is, that its some tag about global warming perhaps.

either way, i need to ran further tests to be sure. besdies that, there are stil lsom assert errors in the dll, but none game breakers.

we shall see today.

 

[Nightinggale]

Speaking of playing a lot of turns and wait for asserts: have you considered trying my makefile? It can make assert DLLs, which are DLL files, which asserts like debug builds, but are optimized like release builds. You can't debug with them, but they run around 10 times faster than debug builds, hence a quick way to find places where the game asserts. I often do that and autosave every turn. That way if it asserts, I can switch in the debug DLL, load the newest autosave and debug the assert. I also play normally using the assert DLL as it is fast enough for that, which is quite useful for improving stability.

 

[keldath]

he night,
well, last time i tried , i wasnt succesful in implementing your nmake - since you now have the cvgamecoredll with my mod - can you upload me an adapted nmake? (im still on vcs 2008 express).
that would help me

indeed the debug i slow paced, harder to test, your would be great.


the only way for me to truly debug is through the pdb right?

 

[isenchine]

hehehe .. hi, nope not supersticious,

after i removed the paratrooper units, i ran a few games - snip...

Oh, removing the paratrooper units is not good. Especially when you were saying that k-mod runs Barsoom with paratroopers and without CtDs. I thought you would have experimented by adding other dll components one by one.

 

[Nightinggale]

Ok, I will see if I can set up a project file to use the new makefile. It will be for vs 2010 as I'm not installing 2008 just for this

the only way for me to truly debug is through the pdb right?

Yeah, but you don't have to select it or anything. It is supposed to happen automatically. In fact it is supposed to just work even without knowing where the file is. With the right project file you should be able to just compile and then debug without considering file placement at all.