Bug Reports

The game also failed one time when I tried to shift-move some goods from the Silk Road to my cart. I was trying to buy 25 weapons. [/COLOR]
Also, it will prevent you from shift clicking while in trade screens as this causes a crash.
I am not sure even how to correct that issue as the crash happens outside of our source code. It crashes because the Unit's travel state is Not UNIT_TRAVEL_STATE_IN_EUROPE. I can create a Hack where I temporary change the units travel state to IN_EUROPE and then change it back right after they load the units. Not sure if there is a better solution or not.
First of all I see no fix/hack/workaround for this in git, yet it looks like the fix is in the DLL (which I didn't test). I would really like to see that workaround to get into what goes wrong.

From what I gather about the bug:
-Shift buy is hardcoded to work on units in Europe only
-Silk road is not Europe

Sounds like a design flaw, either in M:C or in the exe (the non-modable part of vanilla). Obviously this can be fixed without hacking, but the question is how? If trading in Europe is as hardcoded as you say (that would surprise me), then we can decide not to trade in Europe at all and make our own trade function where we can control what happen. It's not like it's a really complex task. Besides the issue only appear when using shift, right?

I wonder if "the crash happens outside of our source code" mean it happens in the part of the exe, which handles python code, meaning the cause of the crash is not in the DLL, but in python. I hate python when it comes to this because I haven't figured out how to debug it or if it is even possible to debug. I made some "print to log" debugging sort of thing, but that's very far from a proper debugger.
 
I'd say it happens in the inner workings of the code where we can't reach. We would have to create our own spin control which should be easy. We may have to use a key other than shift though if we can't high jack it.
Err I'm pretty sure the dialog to handle spin buttons and stuff like that works well if they are called with the correct arguments. The crash could be that the arguments are invalid or they write the result in an invalid location or something like that, but that's all arguments, not the function itself.
 
Err I'm pretty sure the dialog to handle spin buttons and stuff like that works well if they are called with the correct arguments. The crash could be that the arguments are invalid or they write the result in an invalid location or something like that, but that's all arguments, not the function itself.

Well, I fixed it, I guess because I was in a hurry this morning I missed that the code that was causing the problem "was" editable. Debug Fail:cry:

Anyway, I figured out also that the SpiceRoute python screen was left out of the update so I added this to the new update. Update 2.0f can be found in the Downloads page in a few.
 
The game just dropped when I changed a heavy infantry at ? to a master butcher. Savefile from two or three turns earlier attached. 2.0f game.

Ok, trying to check this out. I am guessing the city in question was Nuremburg as it is the only city with a Butcher? I wasn't able to reproduce the bug. Could you give me a bit more information on what happened. Did you select the unit and then choose his profession, or was you in the city screen when it happen?

I can see why that game is over run with Marauders as it is a Huge map and you are the only "Europe" player so they are attracted to commerce and sense you are the only player producing commerce then they all flock to you. To answer one of your questions in the Suggestion forums you may can edit the CIV4WorldInfo.xml to adjust how many Natives appear. On huge the Default is 8 of the 16 allotted players so naturally if you only choose 8 players then all 8 will be native.

Also, I forgot to add in a change we have in the Git version that slows down the production of Saracen so they can't be produced back to back like they are now. I'll add this to 2.0g.

Sorry, for all the updates but you keep pointing out bugs and such, good job :goodjob:
 
Ok, trying to check this out. I am guessing the city in question was Nuremburg as it is the only city with a Butcher? I wasn't able to reproduce the bug. Could you give me a bit more information on what happened. Did you select the unit and then choose his profession, or was you in the city screen when it happened?

I documented as best I could and moved on. All I remember was that I had heavy infantryman who was a master butcher, and when I tried to change his profession back to butcher the game dropped. If you find a butcher-infantryman, he's the one.
 
Forget this one. I don't think the failure can be replicated.

Heh, yeah, I was just trying this one out and didn't get a crash. I did however notice you was playing on THE_NEW_WORLD map. These newest updates require that you use the Medieval maps that come with the download in order for the trade system to work correctly. In that saved game you could not travel on The Silk Road because of this.

Edit: working maps are posted here http://forums.civfanatics.com/showpost.php?p=12650232&postcount=1

I documented as best I could and moved on. All I remember was that I had heavy infantryman who was a master butcher, and when I tried to change his profession back to butcher the game dropped. If you find a butcher-infantryman, he's the one.

K, I'll check this out some more.
 
I have a new assert :(

Code:
FAssertMsg(i < GC.getUnitInfo((UnitTypes) j).getGroupDefinitions((ProfessionTypes) m), "Index out of bounds");
This is at the start of the function
Code:
const char* CvUnitArtStyleTypeInfo::getArtDefineTag(int /*Mesh Index*/ i, int /*UnitType*/ j, int /*ProfessionType*/ m) const

i = 1
j = 24
m = -1

i comes from CvUnit::getArtInfo(int i) const
j comes from GC.getInfoTypeForString(getType()) where szType is UNIT_TRADER
m is hardcoded in CvUnitInfo::getArtDefineTag()

GC.getUnitInfo((UnitTypes) j).getGroupDefinitions((ProfessionTypes) m) returns -1, which mean the assert ends up as (1 < -1)

The unit causing this was built in turn 22 (30 turns ago, not a new unit) is UnitType 24 and has profession 5. It is facing south west. It belongs to player 14, though I haven't digged out which civ that is.

I have no idea what caused this. It happens during the AI's turn and it happens every time. In fact it asserts when I load the savegame. However I never encountered this assert before. However based on what I wrote here I suspect it has something to do with AI and its usage of peddlers. Also it may very likely be caused by incorrect XML settings.

It appears to be a question of getting the right graphics and I can continue to play. Still it would be really nice to figure out what is wrong. Also each assert should be a bug report, meaning we shouldn't have asserts, which can be ignored.
 
It appears to be a question of getting the right graphics and I can continue to play. Still it would be really nice to figure out what is wrong. Also each assert should be a bug report, meaning we shouldn't have asserts, which can be ignored.

This bug appears when anyone changes a Wily Trader to a Merchant profession. And yeah, it has something to do with his graphic. It didn't crash the game so I didn't stop to fix it yet :p And I agree all the asserts need to be dealt with. Some of the asserts however are simply from new features we have added and are not really bugs and some I believe are from vanilla like when you attempt to buy something in the trade screen when you don't have enough gold you get an assert saying you don't have enough gold, duh!
 
Maybe we should have a list of known issues. It's not the first time I debug something you already know about. If the list has enough details, somebody else might come up with a solution.

That is a good idea. mastrude pointed out this one a few pages back actually. I've been testing the AI mostly and playing 200 - 300 turns on autoplay. I have encountered several failed asserts but if they do not crash the game I haven't taken the time to deal with them yet as I don't have much time to even code lately. When I can make sometime ill update the first post with a list of all known failed asserts.
 
Post bug reports here. Please make note of what version you are playing, either the Git version or Official version. I'll post some other bug hunting related info later.

List of known Failed Asserts:

Boring I know, but list list would be quicker to check if the asserts were listed in numerical order by line. I have sorted your list and attached a copy of the sort result.

Attachment to come right away.
 

Attachments

Some of the assert failures are clearly chained. I am reporting those by the line number of the first assert. Here&#8217;s the first new one:

Assert Failed
File: CvPlayer.cpp
Line: 15109
Expression: eYield < NUM_YIELD_TYPES
Message:
Assert Failed
File: CvPlayer.cpp
Line: 15101
Expression: eYield < NUM_YIELD_TYPES
Message:

This chain is included in the uploaded file above.
 
Some of the assert failures are clearly chained. I am reporting those by the line number of the first assert. Here’s the first new one:

Assert Failed
File: CvPlayer.cpp
Line: 15109
Expression: eYield < NUM_YIELD_TYPES
Message:
Assert Failed
File: CvPlayer.cpp
Line: 15101
Expression: eYield < NUM_YIELD_TYPES
Message:

This chain is included in the uploaded file above.
Line 15101
Code:
int CvPlayer::getYieldTradedTotal(YieldTypes eYield) const
{
	FAssert(eYield >= 0);
	FAssert(eYield < NUM_YIELD_TYPES);

	return m_aiYieldTradedTotal[eYield];
}
Line 15109
Code:
void CvPlayer::setYieldTradedTotal(YieldTypes eYield, int iValue)
{
	FAssert(eYield >= 0);
	FAssert(eYield < NUM_YIELD_TYPES);

	if(iValue != getYieldTradedTotal(eYield))
	{
		m_aiYieldTradedTotal[eYield] = iValue;
	}
}
Something called setYieldTradedTotal() with an incorrect argument. Sadly the assert itself fails to tell who called it. However as it is used as an index to an array it mean it will read/write outside the allocated array.

Can you provide a savegame where this happen?
 
Back
Top Bottom