Post Feb 1st 2013 - bugs - Single Player

Status
Not open for further replies.
Just updated at 6:03 Pm CDST to SVN 4978. Using either Desktop short cut ot the BtS main menu C2C will CTD when Initialization screen has XML (uncached) displayed after about a minute wait.

Even holding down the Shift key does not allow Mod to load. Something is broken. :(

JosEPh

EDIT: Just Updated to 4980 Still Crashes at InitXML (uncached). Will now attempt to revert back to 4955 which was working.

EDIT2: Reverted back to SVN 4955 and Mod loads and plays. Something in the last 25 updates is broken. I suspect in the last 3 updates done today.

Edit3: 4966 works.
 
Look in the C2C.FPK under Afforess/eventimages, there is alot of them there, but make sure you use a special border, you can pick from alot of different ones there then just put the image inside of it.

I know the size of image but do I save it as a DDS the same way as button/icons? IF so I will try to provide an image in the event thread.
 
I know the size of image but do I save it as a DDS the same way as button/icons? IF so I will try to provide an image in the event thread.

I think Adrian made the images, might want to check out his thread or download area, if he has a template(s)? But only do this WHEN you have time.
 
Rev 4981:

Game crashes on load during "Init XML uncached".
Last lines in xml.log are:

[11104.603] Load XML file xml\GameInfo/CIV4CivicInfos.xml SUCCEEDED
[11104.603] SetGlobalClassInfo (Civ4CivicInfos/CivicInfos/CivicInfo)
[11106.007] Loading XML file modules\Custom_Religions\Andean\Andean_CIV4CivicInfos.xml
[11106.023] Load XML file modules\Custom_Religions\Andean\Andean_CIV4CivicInfos.xml SUCCEEDED
[11106.023] SetGlobalClassInfo (Civ4CivicInfos/CivicInfos/CivicInfo)

Minidump attached

View attachment 345072

EDIT: 4977 loads fine.
 
Playing SVN 4967 and am at turn 1901 (1631 BC). When ending turn the game has become unresponsive whilst processing other civs turns and the only way to exit is by CTL+ALT+DEL. I cannot proceed any further at present.

Just updated to SVN 4981 to see if this would clear the unresponsiveness (clean Caveman2Cosmos install ) but the game now crashes to desktop when loading at Init XML ( uncached ).


DavidR

View attachment 1 turn before UR David BC-1631.rar
 
So 4978 is the culprit?

that more than likely is, because i exported where the dll's were and 4979 CTD, while 4977 didnt, but i can use the dll from 4979(after i exported it only), because of the stalling needed in 4977. Does this make sense?:crazyeye:
 
Rev 4981:

Game crashes on load during "Init XML uncached".
Last lines in xml.log are:

[11104.603] Load XML file xml\GameInfo/CIV4CivicInfos.xml SUCCEEDED
[11104.603] SetGlobalClassInfo (Civ4CivicInfos/CivicInfos/CivicInfo)
[11106.007] Loading XML file modules\Custom_Religions\Andean\Andean_CIV4CivicInfos.xml
[11106.023] Load XML file modules\Custom_Religions\Andean\Andean_CIV4CivicInfos.xml SUCCEEDED
[11106.023] SetGlobalClassInfo (Civ4CivicInfos/CivicInfos/CivicInfo)

Minidump attached

View attachment 345072

EDIT: 4977 loads fine.


Fix incoming shortly -watch the SVN thread...
 
Interesting bug. Probably caused some really weird effects in the city limits of modular civics.

Caused by the fact that some code in CvCivicInfo calls GC.getCityLimits() which in turn queries if the game option for city limits is on. At this point there is no game and the option are not initialized. In this state it used to return an uninitialized value (which actually doesn't matter in the context of the all since the dynamic decision it makes at that point doesn't impact the eventual data it loads meaningfully), but it now crashes because the options array was changed to be dynamically allocated when the game is initialized a few revs ago in one of your changes.

This was more revealing a bug than being one (in some sense), but I added a guard to getPlayerOption() so that if the options are uninitialized in the calling context it always returns false.
 
Caused by the fact that some code in CvCivicInfo calls GC.getCityLimits() which in turn queries if the game option for city limits is on. At this point there is no game and the option are not initialized. In this state it used to return an uninitialized value (which actually doesn't matter in the context of the all since the dynamic decision it makes at that point doesn't impact the eventual data it loads meaningfully), but it now crashes because the options array was changed to be dynamically allocated when the game is initialized a few revs ago in one of your changes.

This was more revealing a bug than being one (in some sense), but I added a guard to getPlayerOption() so that if the options are uninitialized in the calling context it always returns false.
The issue is that the code that calls getCityLimits actually wants the underlying value to copy it, not the altered value depending on the game options. Now that they are all false at that point it will get the right one, but that is more chance than anything and might resurface as a bug with later changes to that function. The copyNonDefault code should be changed to use the value directly instead of calling getCityLimits.
 
The issue is that the code that calls getCityLimits actually wants the underlying value to copy it, not the altered value depending on the game options. Now that they are all false at that point it will get the right one, but that is more chance than anything and might resurface as a bug with later changes to that function. The copyNonDefault code should be changed to use the value directly instead of calling getCityLimits.

Changed, will be in next push.
 
The issue is that the code that calls getCityLimits actually wants the underlying value to copy it, not the altered value depending on the game options. Now that they are all false at that point it will get the right one, but that is more chance than anything and might resurface as a bug with later changes to that function. The copyNonDefault code should be changed to use the value directly instead of calling getCityLimits.

I never thought that that would be an issue. I thought that the enums were handled before the CvSomethingInfos classes were initialized (and that all options were false when you weren't in a game). Good catch, and thanks to Koshing for fixing that.
 
Status
Not open for further replies.
Back
Top Bottom