v19 bugs and crashes

Traceback (most recent call last):

File "CvScreensInterface", line 86, in showTechChooser

File "CvTechChooser", line 135, in interfaceScreen

RuntimeError: unidentifiable C++ exception
ERR: Python function showTechChooser failed, module CvScreensInterface

 

I hate that sort of error. There is nothing in interfaceScreen at that point that can be possibly wrong. (It is in the initialisation area.) This means it has to be something in the code that calls this routine.

 

Rev 1504 OOS. Happened when my buddy captured an enemy city. I'm only adding the OOS-log currently because we played 700 turns the other logs are quite big (180MB for each PC), if the other logs are needed I can probably split them into multiple archives.


View attachment 311686
View attachment 311687

 

According to the OOS log the RNG is desync so I will need the random log (which will show which computer used the RNG while the other did not and for what).
It should compress well but I really only need the last part of each file.

 

Here it is:

View attachment 311752
View attachment 311753

Thx for your help.

 

Thank you for your report.
I have found the issue (the CityAcquiredAndKept event was sometimes local but used to do game state changes in some Python code).
Fixed it by adding a message in between so keeping the city is reported properly on all computers.

 

Still can't get thru Industrial Era with version 1480 build 1495. Random CTD just hit again.

JosEPh <sigh>

 

I'm working on some memory reductions which I'm hoping may help your issue, but to be honest it's more likely a graphical asset problem of some sort with one of the unit types you're starting to get in the industrial era. Sadly that's just trial-and-error to pin down and withou being able to reproduce it basically a needle in a haystack problem. If it is that then the best way to try to find it is to remove one unit at a time and play enough turns to be confident it's gone away, to figure out which unit type is causing it.

 

I know, and I'm grateful for your and AIAndy's efforts. Just frustrating to spend $80 on a new Vid card and still no better off than I was. And it's a Much better card too.

But as for removing units en mass, I got to figure that out. Once I see how, to then I can start testing.

JosEPh

 

While looking thru CIV4UnitClassInfos I found 2 instances for Sharpshooter:

<UnitClassInfo>
<Type>UNITCLASS_SHARPSHOOTER</Type>
<Description>TXT_KEY_UNIT_SHARPSHOOTER</Description>
<iMaxGlobalInstances>-1</iMaxGlobalInstances>
<iMaxTeamInstances>-1</iMaxTeamInstances>
<iMaxPlayerInstances>4</iMaxPlayerInstances>
<iInstanceCostModifier>0</iInstanceCostModifier>
<DefaultUnit>UNIT_SHARPSHOOTER</DefaultUnit>
</UnitClassInfo>


<UnitClassInfo>
<Type>UNITCLASS_SHARPSHOOTER</Type>
<Description>TXT_KEY_UNIT_SHARPSHOOTER</Description>
<iMaxGlobalInstances>-1</iMaxGlobalInstances>
<iMaxTeamInstances>-1</iMaxTeamInstances>
<iMaxPlayerInstances>5</iMaxPlayerInstances>
<iInstanceCostModifier>0</iInstanceCostModifier>
<DefaultUnit>UNIT_SHARPSHOOTER</DefaultUnit>
</UnitClassInfo>

The only difference is iMaxPlayerInstances. 1 has a value of 4 the other 5. All other lines are the same.

I have been using Sharpshooters and believe I have 5 total.

JosEPh

 

Thanks. Fixed in the SVN. The second definition replaces the first so you get 5 units.

 

I assume you are using v19 because we fixed that when subdued animals was moved to the dll for v20. The main problem was that subdued units where not being placed in the same plot as the unit doing the subdue due to a bug in the information being passed to python from the dll.

This is a timing issue between when the unit is killed and python and the even system know that it has been killed. I don't think there is anything we can do here. The game sometimes awards exp or promotions to dead units also for the same reason.

 

Thanks. Looks like I missed 5 animals including the macaw. I will test then put it in the SVN for v20.

 

My rev 1504 just stopped responding when clicking on a new location in the minimap, unfortunately no minidump because it didn't crash and after reload it worked again. Anyway, attaching logs and autolog, maybe anything unusual in there.

View attachment 311821
View attachment 311822


A few turns later it crashed, minidump attached

View attachment 311823

 

Is there any way to get rid of sooooo many "storms", see attached, and thats only a SMALL section of the map?? The No Storms (check) in the BUG doesn't help

They are a HUGE memory allocation problem.

 

What's the connection between storms and memory allocation?

 

A few more possible inconsistencies regarding "base terrain" and "terrain features." Not sure if this is intended behavior or not. Maybe +1 commerce next to river is only true if there is no feature, or if the feature itself indicates +1 commerce next to river? But just to make sure below are the scenarios:

1) Marsh terrain with no feature on it next to river gives +1 commerce, +1 food, +1 hammer as the civopedia says it should. This is good.

2) Marsh terrain with tall grass feature on it next to river gives +2 food, +1 hammer but does not give the +1 commerce that the base marsh terrain would get. It does add the +1 food correctly though but nothing in the civopedia says that it should subtract the +1 commerce that the marsh terrain gets.

3) Marsh terrain with swamp feature on it next to river gives +1 commerce, +1 hammer. It correctly subtracts a food, but it should also add another +1 commerce due to swamp next to river according to civopedia. Both the base marsh terrain and the swamp feature are suppose to add a +1 commerce next to river according to civopedia

I did not test for all features on terrain, but I have a feeling other "base terrain" and "terrain feature" combinations are being calculated similarly...

Also, I noticed that "hills" are not described in the civopedia at all?

EDIT: I guess this is all intended behavior after all, following the original Civ4 behavior when forest feature is adjacent to river. My only comment on this then would be that as more and more possible features are added that the "next to river" consideration is made for it if it makes sense, and it looks like this was done for many of them hence some features also including the +1 commerce next to river attribute. However I'm wondering if it makes sense that a tall grass feature would remove this +1 commerce? I forget the rationale why forest removed it to be honest...