v19 bugs and crashes

Status
Not open for further replies.
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
 
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.
 
Still can't get thru Industrial Era with version 1480 build 1495. Random CTD just hit again.

JosEPh <sigh>
 
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
 
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. ;)
 
My subdued Macau just revealed a whole bunch of unexplored territory, which IIRC it's not supposed to do. Screenshot attached

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.

Another small error, but why are friendly natives giving help to a unit that's already dead?:p

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.
 
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.

Nope, I'm using SVN rev. 1510, which means the Macau might have been missed. It was moved there by me, not subdued on that tile.
 
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:sad:

They are a HUGE memory allocation problem.
 
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:sad:

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...
 
Status
Not open for further replies.
Back
Top Bottom