Bug Reports

Thanks for taking a look at it. One more thing, if I put it as a world builder save, it sends up the pathfinder, with a single samuri, but that doesn't trip the fatal hang, only does it when it sends the whole attack stack (Which it'll only do if all the minor details like city production are still acounted for which is lost in a WB save)... That I don't understand, how can it and a samuri with UNITAI_ATTACK_CITY, not cause the fatal hang, but if it sends 2 samuri like that with 2 other samuri running UNITAI_COUNTER, it trips?

Edit:
Oh and Zappara said one other thing that might be part of this (not sure). I took a look at UNITAI_ATTACK, and one function I found odd was this wieght the AI put on units with withdraw and collateral damage. I couldn't really see anything else that seemed to tie UNITAI_ATTACK with withdraw. Zap said he was getting reports of the same hang like issues by giving melee units collateral damage, and the hangs went away after taking away collateral damage from those units.
 
Background in this thread. I have taken the current pure revdcm mod from post 1 of this thread, and added one feature. This feature is basically a clone of oasis. I start a revdcm game using all defaults, and use WB to add this feature to a plot. I can tell it is there, by mousing over the plot. It lists "Wind Trap Water" as the terrain type, and also this plot and the adjacent plots show "Fresh Water". That is the point.

Now I click "next turn", and boom! My feature is deleted. When I mouseover the plot and adjacent squares, the fresh water is gone.

Why is revdcm deleting my feature?

Please install the attached zip over a clean revdcm installation to reproduce the problem. Start any game, add the feature in WB, and go to the next turn.
 
jdog5000 said:
Very odd indeed ... I'll see if I can figure it out.
Click to expand...

I appreciate the help. However, jdog has also said in another thread he has a lot of things on his plate. Is anybody else interested to take a look? This is going to be a major improvement to the Dune "feel" of the mod.
 
davidlallen said:
Why is revdcm deleting my feature?
Click to expand...

Well, I did some more experiments, and found an ugly hack which will work. But somewhere revdcm must be hardcoded with a list of the vanilla features, and it deletes anything else. Here is an even simpler way to reproduce the problem. In an unmodified revdcm, edit civ4featureinfos.xml. Pick any feature you like, say forest. Copy the featureinfo to the end of the file. Give it a unique <Type> such as FEATURE_FOREST_CLONE. Change the Description so you will recognize it, for example "Forest Clone". Now start a game, and use WB to put down a feature of this type. Now end your turn.

Bang! It gets deleted.

Given this, the hack is clear. Take one of the original features which I do not need too badly, such as FEATURE_FALLOUT, and put my special behavior on it. This works fine. I took away the fallout penalties and added the bAddsFreshWater flag, and now I can use fallout to do what I want. This is not a real solution; everybody will be confused in a late game when their nuclear missiles explode and provide fresh water!

Can anybody see where revdcm keeps a private list of valid features? I can't think of any other way it can know which features to delete.
 
Replacing the fallout feature could be pretty funny since spies can plant nuclear devices in SuperSpies ...

It looks like DCM introduced a new XML variable called NUM_GAME_FEATURES in GlobalDefinesAlt.xml ... I don't know why that's needed since you could use GC.getNumFeatureInfos(). Try bumping this XML variable up to see if that fixes it, but the real solution should be to remove this strange XML variable altogether.
 
phungus420 said:
Thanks for taking a look at it. One more thing, if I put it as a world builder save, it sends up the pathfinder, with a single samuri, but that doesn't trip the fatal hang, only does it when it sends the whole attack stack (Which it'll only do if all the minor details like city production are still acounted for which is lost in a WB save)... That I don't understand, how can it and a samuri with UNITAI_ATTACK_CITY, not cause the fatal hang, but if it sends 2 samuri like that with 2 other samuri running UNITAI_COUNTER, it trips?

Edit:
Oh and Zappara said one other thing that might be part of this (not sure). I took a look at UNITAI_ATTACK, and one function I found odd was this wieght the AI put on units with withdraw and collateral damage. I couldn't really see anything else that seemed to tie UNITAI_ATTACK with withdraw. Zap said he was getting reports of the same hang like issues by giving melee units collateral damage, and the hangs went away after taking away collateral damage from those units.
Click to expand...

Alright, I finally got time to download and install LoR, trying to build a debug DLL now ...
 
That save is from the LoR test build, I linked it in the thread I reported it, but that might have been lost a few posts back <.<

I have a debug dll already if you want it... Not sure if that works though, since you probably need to build it yourself to examine the source (or can MSV 2005, examine source from a debug dll without building one itself?). The LoR test gamecore is the same as RevDCM except for Leonardos workshop code, and the Enlightened trait, but yeah, it can't load a savegame without those. One last thing, the bug does not trip a failed assert, it just hangs.

This is the LoR test build:
http://www.moddb.com/mods/legends-of-revolution/downloads/legends-of-revolution

If you are using the test build, I suppose it's possible I didn't include all the necessary source code... If that's so let me know and I'll doublecheck.
 
jdog5000 said:
It looks like DCM introduced a new XML variable called NUM_GAME_FEATURES in GlobalDefinesAlt.xml ... I don't know why that's needed since you could use GC.getNumFeatureInfos(). Try bumping this XML variable up to see if that fixes it, but the real solution should be to remove this strange XML variable altogether.
Click to expand...

That seems like an excellent explanation. But, I put back the original featureinfos and added my windtrap feature at the end; then I increased NUM_GAME_FEATURES by 1.

Sadly, the behavior is the same. The new feature vanishes as soon as I hit "next turn". Using the fallout feature is disturbing, but it will be a late game bug, so I can live with that for now. Any other leads?
 
Oh well, no matter for now. Thanks for trying. RevolutionDCM 2.10 has already been released just now, but next week there is always a 2.11 or a 2.1111 or a 2.111111111 update we can do :)
Cheers.
 
jdog5000 said:
I did download and install the test version ... so maybe there's something missing from the sources like you suggest?

It runs okay, but can't load the save ... a discrepancy in source code would definitely cause that kind of issue.
Click to expand...
Damn. Thought for sure I'd checked the source I uploaded with the build... I'll look into this and report back. Can you use a precomiled debug dll (with it's big text document), or is this something you need to build yourself?
 
I forgot to change CvDefines.h to a 50 civ dll. That's most likely the cause, as a 34civ dll wol't accept a 50 civ save :blush: Somehow I also managed to use CyCity.cpp and CyCity.h from RevDCM 1.02. So yeah, totally my bad with the source code. Here is the updated source:

Edit:
Also in case you can use a pre made debug gamecore and pbd here they are (Crazy compression rate, goes from 80MB to 13MB when compressed):
http://files.filefront.com/LoRTest+debugstuffzip/;13851081;/fileinfo.html
 
Just got a save uploaded with a critical bug from LoR (not the test build this time, it's the 0.8.2 release). Fatal hang, here is the failed assert:

Assert Failed

File: CvUnitAI.cpp
Line: 9866
Expression: pLoopUnit != this
Message:
Click to expand...
This assert will keep popping up as long as I say ignore once, and then if I choose always ignore, fatal hang.

Going to work with this a bit, see if I can isolate it. It's doubful that I can convert this to a pure RevDCM save, since it's AI related, but I'll see what I can do.


Edit:
When cycling through the civs in an effort to narrow down the cause of the fatal bug to the civilization it occurs in, and hopefully locate the offending unit(s), I ran into this failed assert, I've never seen before:
Assert Failed

File: CvPlayerAI.cpp
Line: 11197
Expression: AI_getNumAIUnits(eIndex) >= 0
Message:
Click to expand...
Just hit "ignore" and it went away. But figured I'd note it. Also this assert was not thrown when I hit enter to simply end the turn to reproduce the fatal hang reported above. Seems odd this would trip when cycling through the civs one by one, but not when the game was running through an entire turn. (also how is it possible to return -1 when trying to retrieve the number of units?)
 
OK, this was strange. So I cycled through all civs. The assert, and subsequent hang didn't trip. So I figured this was some extremely rare bug, and having me cycle through the civs, even though I wasn't doing anything (once I took control, I immediatly switched to the next, allowing the AI to do whatever it was going to do anyway) was enough to get it not to trip. So I saved the game, with the intent to upload the save for the person that reported it, so they could continue their game. I figured I'd just check with AutoAI to make sure it didn't trip again, and lo and behold, assert tripped with failed hang :hmm:

So since this keeps cycling through I figured I'd use the step into function of the debugger, and this is what it comes up with:

CvUnitAI.cpp
Spoiler :
Code: 
											if (pLoopUnit->isWaiting())
											{
												FAssert(pLoopUnit != this);
												iCount++;
											}
Code: 
									else
									{
										if (pLoopUnit->getGroup()->getMissionType(0) != MISSION_SKIP)
										{
											iCount++;											
										}
									}
Code: 
				while (pUnitNode != NULL)
				{
					pLoopUnit = ::getUnit(pUnitNode->m_data);
					pUnitNode = pPlot->nextUnitNode(pUnitNode);

CvGameCoreUtils.cpp
Spoiler :
Code: 
CvUnit* getUnit(IDInfo unit)
{
	if ((unit.eOwner >= 0) && unit.eOwner < MAX_PLAYERS)
	{
		return (GET_PLAYER((PlayerTypes)unit.eOwner).getUnit(unit.iID));
	}

	return NULL;
}

CvPlayerAI.h
Spoiler :
Code: 
  static CvPlayerAI& getPlayer(PlayerTypes ePlayer) 
  {
	  FAssertMsg(ePlayer != NO_PLAYER, "Player is not assigned a valid value");
	  FAssertMsg(ePlayer < MAX_PLAYERS, "Player is not assigned a valid value");
	  return m_aPlayers[ePlayer]; 
  }
Code: 
CvUnit* getUnit(IDInfo unit)
{
	if ((unit.eOwner >= 0) && unit.eOwner < MAX_PLAYERS)
	{
		return (GET_PLAYER((PlayerTypes)unit.eOwner).getUnit(unit.iID));
	}

	return NULL;
}

CvPlayer.cpp
Spoiler :
Code: 
CvUnit* CvPlayer::getUnit(int iID) const
{
	return (m_units.getAt(iID));
}

FFreeListTrashArray.h
Spoiler :
Code: 
CvUnit* CvPlayer::getUnit(int iID) const
{
	return (m_units.getAt(iID));
}
Code: 
	iIndex = (iID & FLTA_INDEX_MASK);

	assert(iIndex >= 0);
Code: 
	if ((iIndex <= m_iLastIndex) && 
		(m_pArray[iIndex].pData != NULL))
	{
		if (((iID & FLTA_ID_MASK) == 0) || (m_pArray[iIndex].pData->getID() == iID))
		{
			return m_pArray[iIndex].pData;
		}
	}

CvUnit.cpp
Spoiler :
Code: 
int CvUnit::getID() const
{
	return m_iID;
}

Return to the FreeTrash one
Spoiler :
Code: 
	if ((iIndex <= m_iLastIndex) && 
		(m_pArray[iIndex].pData != NULL))
	{
		if (((iID & FLTA_ID_MASK) == 0) || (m_pArray[iIndex].pData->getID() == iID))
		{
			return m_pArray[iIndex].pData;
		}
	}
Code: 
	return NULL;
}

And back to CvPlayer.h
Spoiler :
Code: 
CvUnit* CvPlayer::getUnit(int iID) const
{
	return (m_units.getAt(iID));
}

And back to CvGameCoreUtils.cpp
Spoiler :
Code: 
CvUnit* getUnit(IDInfo unit)
{
	if ((unit.eOwner >= 0) && unit.eOwner < MAX_PLAYERS)
	{
		return (GET_PLAYER((PlayerTypes)unit.eOwner).getUnit(unit.iID));
	}

	return NULL;
}

And back to the start of the Assert Message in the Source Code.


I"m out of ideas on how to debug this, since It wol't let me cycle through the civs to isolate it.... Any ideas? The save game this is occuring in is found here:
http://rapidshare.com/files/240677764/BeforeBlock.CivBeyondSwordSave
Unfortunately it's for the 0.8.2 build instead of the test build which you've already picked up. I also am not fully comfortable asking you to check out bugs in my mod. I was a little more OK with it with the last fatal hang reported, as I isolated the cause, and it wasn't an issue with LoR, and instead is either a problem with default BtS, betterAI, or RevDCM. This one, since I can't isolate I can't be so sure. But figure I should report it and see what you decide to do with the report.
 
jdog5000 said:
It looks like DCM introduced a new XML variable called NUM_GAME_FEATURES in GlobalDefinesAlt.xml ... I don't know why that's needed since you could use GC.getNumFeatureInfos(). Try bumping this XML variable up to see if that fixes it, but the real solution should be to remove this strange XML variable altogether.
Click to expand...

davidlallen said:
That seems like an excellent explanation. But, I put back the original featureinfos and added my windtrap feature at the end; then I increased NUM_GAME_FEATURES by 1.
Click to expand...

Actually this code must be even stranger than you thought. I have it working now. In addition to hard coding the number of features, they have also introduced an order dependency within the featuresinfo file. All of the game features must come first, and then all of the battlefield features. If you add a new game feature at the end, it will be deleted. Instead, you must add it into the right place in the file. It must go before the first battlefield feature, in the middle of the file.

Apart from this thread here, is there some other place I should report this, now that we have completely analyzed it?
 
davidlallen said:
Actually this code must be even stranger than you thought. I have it working now. In addition to hard coding the number of features, they have also introduced an order dependency within the featuresinfo file. All of the game features must come first, and then all of the battlefield features. If you add a new game feature at the end, it will be deleted. Instead, you must add it into the right place in the file. It must go before the first battlefield feature, in the middle of the file.

Apart from this thread here, is there some other place I should report this, now that we have completely analyzed it?
Click to expand...

Ah, thank you! Good detective work.

If you could write a short description in the "For Modders and Mergers" thread, that would be helpful I think.
 
You must log in or register to reply here.

Similar threads

Laurana Kanan
  • Sticky
Guidelines for Reporting Bugs at Civfanatics
Replies
0
Views
2K
Laurana Kanan
Laurana Kanan
Barbarian King
[1.1.0] Mexican Revolucionario Bug
Replies
0
Views
297
Barbarian King
Barbarian King
sylkachan
Treasure pick-ups stopped working.
Replies
2
Views
180
sylkachan
sylkachan
Laurana Kanan
  • Sticky
Reporting Bugs and Technical Issues to Firaxis
Replies
0
Views
3K
Laurana Kanan
Laurana Kanan
ossi
Garuda statue memento bug
Replies
0
Views
498
ossi
ossi
Back
Top Bottom