Fallout: Tame The Wastes bug reports

have you added the art folder to the mod? There are 3 parts to download.

 

I did and I placed it in the assests folder

 

Hmm.. The only unit that should be blob is the settler be cause I accidentally left out its art in that version..

 

I don't know but it crashes on me a great deal as well sorry

 

Ok Clean slate, new version released Alpha2!

 

Hi there,

I notice I'm still getting the city screen health TXT-KEY weirdness and the slaver problem. I've also had a persistant ctd (attached for info) it might be due to the slaver problem as I notice in world-builder that the Native capital is due to complete a slaver unit this turn. I've tried to WB the Natives some extra defensive units on the off-chance that this would prevent the ctd but no joy A few turns prior I had a persistant ctd that was due to the slaver prob and using wb removed everyones slaver units. Looks like the AI is just building them again and it's causing the ctd???

As a suggestion might it be an idea to remove the 'gets defensive bonuses' from the slaver unit in XML, I presume this would stop them fortifying on city defense missions perhaps? Judging from playtesting with my own slaver units the problem doesn't seem to be them fortifying for healing just when they fortify as city defense and when they are fortified outside in a forest or on a hill.

The problems with the tech-screen discovery and redblob units seem resolved though and I'll take this oportunity to thank you for your hard-work and say how much I love the concept (even tho I've never played fallout) and the groovy graphics and look/feel of the mod

 

Glad you are enjoying it, it is good to hear. And thanks for continuing the bug rep it is greatly appreciated, I will def remove the defends bonus from slavers, I removed the ai city defends from slavers, so they should not be fortifying in cities anymore.. Hmm I wonder what else could be done to them.. Oh yeah the health text was one of those problems I forgot to fix! Doh! I will keep chipping

 

(My only) two savegames have been wrecked by a reproducable crash, I will post the latter one of them here.

The game was Alpha2, a small-size 'great plains' map, 6 civs (I think), normal speed, custom game with only perm. all. and multiple production enabled.

 

hmmm... Well the first annoyance is that the AI is using a slaver to defend a city... It shouldn't be doing that it is set not to... the ssecond annoyance is that it still crashes even after the slaver is removed...

hmmmm....

ok so I found some more slavers being used in defence and got rid of them as well and that seems to have fixed it... But why the AI is using them for city defence I don't know... hmmm I wonder if I could add a -100% city defense to them if that would stop the AI

aaaah I may have found the culprit! I somehow left a 25% city defence bonus on it! I have changed it to -100% now. see what that does .

For anyone who wants to see if it helps the issue, add it to k-fallout/assets/xml/units and overwrite the other one

HOPEFULLY this should stop the computer using them defensively, which I think it where the issue lies, because I don't think they work as a defence unit because they are invisible... chip...chip...

 

Here's 3 more CTD-ing saves from before the above fix.
Now I'll try that and see if it works.

 

damn it! the crash continues!

hmmm ok the crash does not seem to be repeated when i reload.. although I did delete a bunch of units from cities first but none of them slavers, unfortunately I overwrote the save!! doh so WHO KNOWS!!! DOH

ok another CTD...

ok it is repeatable, now lets see if we can fix it..

hmmm... it seemed to be caused by the building of a slaver.. when I put a spy next to the city that was building the slaver the game continued for a few more turns...

 

If slavers defending a city is one cause of CTD, how can it be prevented for good ? A slaver might end up in a city as the only unit there (even if it's by accident because the AI wouldn't put him there on purpose), the slaver might still be chosen as a city defender which would produce a CTD that cannot be fixed by reloading, wouldn't it ?

 

yes this is all potentially true, I have tried my best to force the ai not to use them defensively, which I now think is working, they have no city defense strength (set to -100% bonus) the notai in the unit xml includes all city defense ais, they have no defensive bonus (like horseman and such) and I do not think they are being used defensively anymore.

There seems to be another strange issue as I said above, where I have a repeatable crash from an AI building a slaver, yet when i put a spy next tot he offending city (so it is visible when the slaver is built) the game continued for 4 more turns, I am just about to look for a possible new cause in this turn, as I have established that the CTD is again repeatable..

same thing again, same city, making another slaver, fixed by having a spy next to it...

and CTD again a couple turns later....hmmm.. this one appears more elusive

Ok this one seemed to be related to a slaver in an enclave city... I got rid of it and the game worked fine for more turns. (I don't know what the slaver was doing in there, whether he was fortified or what...He may have been selling lsaves but I do not know..).

Another CTD, about to explore the cause.. hmmm.. not repeatable game continued for a couple more turns.

new CTD.... seems to be repeatable..

 

I noticed the .dll in Assets/debug and swapped it with the original .dll file in hope that it would give some better debugging infos on CTD.

It gave me some failed assertion right on starting the game up (but I ignored it, seemed unrelated, can't remember right now what it was).
On clicking on 'next turn' in the save I gave you (so far without your XML-fix) I get another assertion:

Code:

Assert Failed

File:  CvInfos.cpp
Line:  4821
Expression:  iRouteType > -1
Message:  Index out of bounds

Unfortunately, when looking inside the sources in
...\Civilization 4\Beyond the Sword\CvGameCoreDLL\
I don't see a related line of code. So it must be in your changed version of the sources, there the line number should be pointing at the correct place.

EDIT:
when I "always ignore" the printed assertion, I get more assertions following that:

Code:

Assert Failed

File:  CvUnit.cpp
Line:  16053
Expression:  iOurStrength > 0
Message:  Combat strength is expected to be greater than zero

Code:

Assert Failed

File:  CvUnitAI.cpp
Line:  15623
Expression:  iParatrooperCount > 0
Message: 

Code:

Assert Failed

File:  CvCity.cpp
Line:  1257
Expression:  GET_PLAYER(getOwnerINLINE()).getFreeCityCommerce((CommerceTypes)iI) >= 0
Message:  

Then the game crashes for good

 

Yes I have a whole collection of assert fails in a file.

here it is for anyone who wants the current list of errors I have found.

Code:

Assert Failed

File:  CvUnitAI.cpp
Line:  12891
Expression:  false
Message:  

AI_ejectBestDefender failed 

to choose a candidate for 

AI_guardCity.

This one in particular I have not seen till now.

Also for anyone that is interested in looking through the .dll/SDK/Source Files I have added a download link to the MonkeydoGames Page, so if you want to play hunt the errors you are welcome to join me. Some errors are not actually errors, they are just oddities of civ, for example negative values in certain city commerces, but I have been told this is not actually a problem.

I still haven't found the error with my latest save game which I have also attached if anyone feels like cassting a fresh pair of eyes over it for something I have missed!

That route type error refers to Jroute code:

Spoiler :

Code:

// < JRouteNative Mod Start >
bool CvUnitInfo::getRouteNative(int iRouteType) const
{
	FAssertMsg(iRouteType < GC.getNumRouteInfos(), "Index out of bounds");
	FAssertMsg(iRouteType > -1, "Index out of bounds");
	return m_pbRouteNative ? m_pbRouteNative[iRouteType] : false;
}

bool CvUnitInfo::getRouteImpassable(int iRouteType) const
{
	FAssertMsg(iRouteType < GC.getNumRouteInfos(), "Index out of bounds");
	FAssertMsg(iRouteType > -1, "Index out of bounds");
	return m_pbRouteImpassable ? m_pbRouteImpassable[iRouteType] : false;
}

bool CvUnitInfo::getRouteIgnore(int iRouteType) const
{
	FAssertMsg(iRouteType < GC.getNumRouteInfos(), "Index out of bounds");
[COLOR="Red"]	FAssertMsg(iRouteType > -1, "Index out of bounds");[/COLOR]
	return m_pbRouteIgnore ? m_pbRouteIgnore[iRouteType] : false;
}

int CvUnitInfo::getRouteSubstitute(int iRouteType) const
{
	FAssertMsg(iRouteType < GC.getNumRouteInfos(), "Index out of bounds");
	FAssertMsg(iRouteType > -1, "Index out of bounds");
	return m_piRouteSubstitute ? m_piRouteSubstitute[iRouteType] : -1;
}
// < JRouteNative Mod End >

I don't think this is the crash issue, I don't think I have used Jroute code yet for anything, but I plan to in the future.

Also those other errors occur repeatedly throughout the game, without CTD so I do not think they are the crash issue. They made need fixing (possibly) but I do not think they are linked to the CTD issue..

 

I have also contacted the Mod maker archid, who is going to do his best to help. He mentioned he had once experienced a crash issue, but could not reproduce it. So maybe I have created some kind of monster situation that brings this issue to the surface more often DOH!!

 

I ran the game with a debugger attached to the process and when pressing on 'next turn' I got an unhandled division-by-zero exception during the function doOpportunityFire().

I changed the line 16055 of CvUnit.cpp from

Code:

iUnitDamage = std::max(1, ((GC.getDefineINT("RANGE_COMBAT_DAMAGE")) * (iOurStrength) / (iTheirStrength)));

to

Code:

iUnitDamage = (iTheirStrength > 0 ? std::max(1, ((GC.getDefineINT("RANGE_COMBAT_DAMAGE")) * (iOurStrength) / (iTheirStrength))) : 0);

(So my fix is just a lame check wether iTheirStrength is non-zero in this place. If it isn't it will simply set the resulting damage to zero instead, opportunity fire is still displayed, nonetheless)

The unit causing this issue is a slaver, btw. And the unit taking the opportunity fire hit was a ranger.

I don't know if there is an XML-variable to deny them the opportunity fire (I also don't know if that would be necessary or even undesirable). But having an unchecked division-by-zero in the code is no good either way so some kind of fix should be applied at this location, imho.
We should think of a solution that prevents opportunity fire for units with zero strength one way or the other. As the slavers have a base strength of 3, I'm not sure why iTheirStrength was zero on this occasion.

I will also attach the compiled .dll file from the change, in case somebody has the same problem and wants to continue playing.

 

Ah ok this makes sense, I think. I think what is happening is that opportunity fire uses ranged strength damage and slavers among others have no ranged strength hence the zero issue, so it wil need some kind of if zero skip function. I don't know how to right that though, maybe I can ask in the SDK forum. Well figured though.

 

Well, this whole part about the opportunity fire is kind of weird, anyways.

Firstly, we get:

Code:

iOurStrength = airCurrCombatStr(pDefender);
FAssertMsg(iOurStrength > 0, "Combat strength is expected to be greater than zero");

(I think opportunity fire was meant for airborne units as the function call suggests)

But for the slaver doing the opportunity fire, the result is zero, which triggers the assertion.
But the problem here is not the slaver, but his target, the sheriff (in my case, the save which I posted earlier).
Because this call

Code:

iTheirStrength = pDefender->maxCombatStr(pPlot, this);

also results in zero.

And as the sources barely use any exception handling, there should be a check if this value is zero.

As far as I can tell, up until that point the function hasn't changed any status of the game and it is void, too. So it should be safe to just jump out of it in our case, like so:

Code:

iTheirStrength = pDefender->maxCombatStr(pPlot, this);
if ( !iTheirStrength ) return;

Which would be a little better than my previous solution because we don't do any unnecessary opportunity fire calculations which would lead to nothing because I set the damage value to 0.

Since this fix, I didn't have any CTD while playing for 2 hours or something.

Edit:
Btw, is the ability to do opportunity fire mentioned for each unit in some xml file ? I looked in civ4unitinfos.xml, found the entry for the slaver but nothing about opportunity fire in the entire file.

 

No the basic concept is that it is attached to iairdamage (or something like that) basically we use the iairdamage to do ranged bombardment damage, i.e. with units that have ranged guns, I added opp fire mainly as an aid for the ai, so that if it has a a fortified ranged unit, that unit will not simply wait to be attacked but will fire on an approaching enemy.

the original opp fire code used a new code system, that we did not use (it comes from realism invictus I think) so we had to change the reference to work with our system, which was the iairdamage value.

I have obviously coded the itheirstrength bit wrong, because it is supposed to reference their combat (melee) strength not their air(ranged) strength. So that it should never be 0, but it is obviously referencing the ranged strength for some reason..

I guess what the code really needs is two things:
1. A check at the beginning to state that if a units ranged damage (iairdamage) (or whatever the proper name is) is greater than 0 run opp fire, if not then skip.

2. to make sure the defensive unit is referencing its icombat value not its ranged strength value.

I am no coder, so I am not very good at translating into code language, we kind of chipped away at this code till we got opp fire working, but I was never convinced that we had it right, especially because melee units were getting opp fire as well.

EDIT: it is iaircombat (not iairdamage)