Specific Bug Reports

I just grabbed a copy of BBAI to see if I could take a shot at fixing the crash issue... but here's the fun part. I compiled a new debug dll so I could see if I could pin-point the cause of the crash for Jdog, so he can get back to work quicker, but the Debug DLL didn't crash. The regular dll did. So this is one of those crashes that debug dll's avoid... making it 10x harder to trace down. :sad:

Thanks for trying Afforess.....I've switched to RevolutionDCM for now, and IIRC it uses 0.82j?

Regards,

Jeff
 
I just grabbed a copy of BBAI to see if I could take a shot at fixing the crash issue... but here's the fun part. I compiled a new debug dll so I could see if I could pin-point the cause of the crash for Jdog, so he can get back to work quicker, but the Debug DLL didn't crash. The regular dll did. So this is one of those crashes that debug dll's avoid... making it 10x harder to trace down. :sad:
Just by acident, any AI does something remotely remarkable in the IBT in the non-crash version? Say, a DoW, a DP, vassaling someone?
 
Just by acident, any AI does something remotely remarkable in the IBT in the non-crash version? Say, a DoW, a DP, vassaling someone?

Yeah, in Jeff's save, he is declared war on one turn before the crash.
 
Thanks for trying Afforess.....I've switched to RevolutionDCM for now, and IIRC it uses 0.82j?

Regards,

Jeff
The current download of RevDCM is old, can't remember the specific version. The current RevDCM SVN has an older compiled gamecore, with the latest stable version of BBAI. Unfortunately the source has been updated, so the new source code will cause a crash if a new gamecore is compiled due to the current BBAI bug.
 
Hi I have a bug simailar to stljeffbb which may be caused by betterai. Game CTD at the same point during the ai turn with 'a problem that caused the program to stop working' according to windows 7. I have gone back to the earliest autosave and the same thing happens at the same turn.

Looked for a solution for a few hours yesterday with no joy, lots of similar problems but no solutions. I also completely uninstalled and reinstalled BTS and vanilla with the same results.

The save game will not even load withour betterai or the 3.19 patch.

In event viewer a dll called ntdll.dll is linked to the crash, again google has no answers as to why.

Nothing major happened in the turns before although the map is still mostly covered in darkness. If anyone could take a look I would be very grateful.
 

Attachments

It would really help if you guys would mention what version you're using unless it's the latest, and even then it wouldn't hurt to know if you're using the 'official' one or the 'fixed' dll from LunarMongoose.

edit: for people using my Better BUG AI merge there's a new version too, at the usual plase. -> mediafire
 
Sorry, I am using the BTS 3.19 and Betterai version 0.83.

I also just tried LunarMongoose's dll and that prevents the CTD but automatically gives an ai player a cultural victory. The weird thing is that its random every time which player wins!

At least its a step in the right direction.
 
:lol::lol::lol:
No, a random false victory for the AI is definitely not the right direction.

Does that at least happen as soon as you end the turn after loading the savegame with the new dll, or is there some delay?
 
No, the automatic victory occurs at the end of the ai turn, definitely after the point where the CTD happened but before I start my turn (I think that makes sense).

Thanks for looking at this for me.
 
The checks for victory are done before player 0 ( normally, but not always the human ) plays, so there is no surprise in there. Now on what is causing it ... First, go to the basics: any of those AI was even close of a cultural win? ;)

P.S I guess that something in the code is making the game think that some/all the AI tripped the cultural win threshold ( that is consistent with not being always the same AI choosed for the win ). Any idea of what it can be?
 
No, no ai is close to a cultural win at all, the graphs at the end show that the culture of one particular ai jumps up at that turn which I assume triggers the win.

There are no usual settings with the map either. Its very odd.
 
OK, in playing around with this save my copy of civ/bts started giving me errors and options that started with TXT_BOX so I reinstalled everything again including any extra files put in there by messing about.

Applying LunarMongoose's dll to a fresh install of BTS 3.19 and betterai 0.83 allows the save to continue. Its a little shaky, the ai turn takes far too long but I am going to play through and see what happens.

Thanks for the help.
 
Hi everyone,

using BBAI 0.84 I have experienced a bug during a pillage action:
I have a helicopter with 4 MP on a enemy tile with a road and a farm.
I click one time only on "pillage" button but the helicopter pilage twice.
Same bug on tiles with cottages or towns.

Please verify and fix-it in next BBAI release.

Thanks in advance.
 
I have a CTD with 0.84b. I've built a debug dll, and on the turn of the crash I get the following FAsserts:

Spoiler :
Code:
int CvPlayerAI::AI_getAttitudeVal(PlayerTypes ePlayer, bool bForced) const
{
	PROFILE_FUNC();

	int iRankDifference;
	int iAttitude;
	int iI;

	FAssertMsg(ePlayer != getID(), "shouldn't call this function on ourselves");

Code:
DenialTypes CvTeamAI::AI_declareWarTrade(TeamTypes eWarTeam, TeamTypes eTeam, bool bConsiderPower) const
{
	PROFILE_FUNC();

	AttitudeTypes eAttitude;
	AttitudeTypes eAttitudeThem;
	bool bLandTarget;
	int iI;

	FAssertMsg(eTeam != getID(), "shouldn't call this function on ourselves");

Code:
AttitudeTypes CvPlayerAI::AI_getAttitude(PlayerTypes ePlayer, bool bForced) const
{
	PROFILE_FUNC();

	FAssertMsg(ePlayer != getID(), "shouldn't call this function on ourselves");

Code:
bool CvTeam::isHasMet(TeamTypes eIndex)	const														 
{
	FAssertMsg(eIndex >= 0, "eIndex is expected to be non-negative (invalid Index)");

Code:
void CvCity::changeBonusBadHappiness(int iChange)
{
	if (iChange != 0)
	{
		m_iBonusBadHappiness = (m_iBonusBadHappiness + iChange);
		FAssert(getBonusBadHappiness() <= 0);

Code:
void CvCity::changeBuildingGoodHealth(int iChange)
{
	if (iChange != 0)
	{
		m_iBuildingGoodHealth = (m_iBuildingGoodHealth + iChange);
		FAssert(getBuildingGoodHealth() >= 0);

The last two happen just before the crash.
 
You're playing with BUG, right? The first three asserts you listed are harmless and I believe caused by the BUG scoreboard which shows your war and relationship status with yourself.

The next three spell trouble, although I can't reconstruct the causes from the asserts. I'm guessing these are from your merged mod or you would have posted a save, some ideas:

isHasMet: This might be generated by some Python function, cause otherwise it should cause a crash I think. Maybe check out Python error logs to see if anything pops up? If there's nothing in Python logs, then a trace of the functions which led to the call to isHasMet might get me enough info to track something down.

changeBonusBadHappiness: What's happened here is that the game is removing a happiness penalty either after a civ loses a bonus or building, and it's complaining because its removing a penalty which appears to never have been applied in the first place. I can't see how BBAI would cause this. Did you perhaps change some features of buildings in XML after started a save?

changeBuildingGoodHealth: Like above for buildings causing health, this is core Civ4 functionality BBAI hasn't touched. Again my hunch is some building XML changes took effect after buildings were constructed in the game.

Hope that helps.
 
Yes, I use BUG 4.2 (so not the latest version). I had a hunch the first three didn't matter much, I think I've seen them before too. There are no python errors in the log, so I'll see if I can figure out how to trace the error.

The two last FAsserts - nothing was changed during this game. It was just an autoplay, set to 500 turns. The game crashed in the year 2012, so it was actually pretty close to the end. It *could* be BULL that has tinkered with this, I'm not sure. Would it be possible for isHasMet to crash the game, but for the two final FAsserts to trigger before the game actually crashes?
 
Neither BUG nor BULL change gameplay or game values, so they have no reason to call changeBonusBadHappiness() or changeBuildingGoodHealth(). All BULL does it call the getXXX() functions to display values in hover text.

I'll run BUG with a debug DLL again, but I think I'm checking to avoid calling those functions on team X for team X.
 
<Define>
<!-- Better BTS AI: Turns defensive pacts into something more like an alliance, the pact does not break on war declaration. (Def: 0) -->
<DefineName>BBAI_ALLIANCE_OPTION</DefineName>
<iDefineIntVal>1</iDefineIntVal>
</Define>

Can you please change this? At the moment this is also an offensive pact. When I declare war on X with defensive pact to Y, Y will also declare war on X. This is not the behavior listed in the description.

Can you add the option: "Defensive Pact does not break on war declaration, but it's no Offensive Pact (your partner will NOT declare war if you are the aggressor)"?

Is that possible?
 
Back
Top Bottom