Single Player bugs and crashes v37 plus (SVN) - After the 24th of December 2016

XML tags are generally Case Sensitive did you check if the tags with wrong letters showed up in game?
No I didn't. They were manufactured and Cultural bonuses only.

That might actually explain some of the CTDs people reported. It would only CTD when a plot where one of those bonuses had been placed was displayed.
 
I did not intend to set off a wave of "OMG all these things are WRONG" in my post earlier...

Do not worry - I think it was my earlier post on SVN 9548 that caused it. You just posted in the middle of the discussion.

But if it was your post - you should be proud. You helped improve the mod. So keep them coming. :)
 
Last edited:
Edit: @Dancing Hoskuld You can remove the errors I fixed from your previous posts so TB doesn't have to scratch his head when he tries to fix those that are already fixed.
This is exactly where I'm stuck. I don't have any concise list anywhere that doesn't seem to be resolved as soon as I start looking into it. Is there anything still left to do here and if so, is there a maintained list somewhere?

PS: I'm not sure I'm familiar with the validator. It was my understanding that the debug dll would cover this need. Since I'm hearing now that it doesn't, it would be good to get to know how to use this validator myself. Where is it to be obtained in the first place?
 
Found another repeatable CTD; during the turn, in between moves, like last time. This time I can't figure out what's triggering it, but it always happens at the same time in the unit cycle.

Attached a save from the turn of the crash, a save from the turn before, and a minidump.

Most recent SVN
 

Attachments

Found another repeatable CTD; during the turn, in between moves, like last time. This time I can't figure out what's triggering it, but it always happens at the same time in the unit cycle.

Attached a save from the turn of the crash, a save from the turn before, and a minidump.

Most recent SVN
OK... I'll look into this soon. Probably on the weekend.
 
There are the four on the the previous page and the three in the files I posted on the SVN thread when this all came up.

The Validator is linked to in the Modders documentation thread.
 
The Validator is linked to in the Modders documentation thread.
I think I'm just going to have to get this and use it myself to see what I can find and fix.
There are the four on the the previous page and the three in the files I posted on the SVN thread when this all came up.
How am I supposed to know which ones are not addressed and which are though?
 
The ones in the spoilers marked fixed have been fixed none of the others have been. No one has even looked at the ones I put on the SVN thread. Note none of them are the ones with the commerce/yield problem as that is a known issue that requires/ed the schema and dll to be fixed before we can fix the XML. All of the ones that use those tags are mine so I will get to them.
 
In most cases it causes no errors to appear in game. It may cause memory problems when the data is read in.

It looks like they were the cause of my experimental Antiquities not working. Which is what the validator is for - finding problems when you can't see then yourself. The validator is case sensitive so iPLacementOrder in the Bonus Infos is not the same as iPlacementOrder but the code Civ uses to read the tags may not case sensitive. That example was the main source of errors on the Cultural Bonuses file.
This upper case issue is now fixed.
I did not intend to set off a wave of "OMG all these things are WRONG" in my post earlier...
Don't worry, this stuff would have come on it's own without your previous post.
DH has been working on xml syntax and structural related errors for quite some time already (1-2 months or more).
 
Last edited:
Toffer mentioned in the SVN Changelog, that the iPLacement (the capital L) will not work nut i found that in the manufactured area that from this point on i believe ALL PL's are that way . . . (see pic)
 

Attachments

  • PLacement.JPG
    PLacement.JPG
    91.1 KB · Views: 33
Last edited:
No one has even looked at the ones I put on the SVN thread.
I looked at the first one and didn't see a problem and since I cannot confirm that it hasn't been done, which some conversation alluded to the possibility that it had been addressed, it's frustratingly demotivating to think I'm working on something someone's already fixed. Particularly when all of this could not be coming at a worse time for me to work on... well, it COULD be worse but suffice it to say I'm in the middle of something here.
Note none of them are the ones with the commerce/yield problem as that is a known issue that requires/ed the schema and dll to be fixed before we can fix the XML.
As stated, it's correct in the dll and incorrect in the schema so it's a simple schema fix. Did I not already correct this with my last commit? There was only one tag with this problem right?
 
Toffer mentioned in the SVN Changelog, that the iPLacement (the capital L) will not work nut i found that in the manufactured area that from this point on i believe ALL PL's are that way . . . (see pic)
I went through an corrected all of them in the Manufactured and Culture folders. Having iPLacement instead of iPlacement is a possible cause of CTD errors as the defaults given by the dll when it reads the file will have an iPlacement of 0 which means that it can be put on the map. However these don't have a map graphic so the plot they are placed on will CTD when displayed on screen.

As stated, it's correct in the dll and incorrect in the schema so it's a simple schema fix. Did I not already correct this with my last commit? There was only one tag with this problem right?
In the C2C_Buildings schema file in the XML/Buildings folder it is still

Code:
    <ElementType name="SpecialistCommerceChange" content="eltOnly">
        <element type="SpecialistType"/>
        <element type="YieldChanges"/>
    </ElementType>
which is wrong.
 
I went through an corrected all of them in the Manufactured and Culture folders. Having iPLacement instead of iPlacement is a possible cause of CTD errors as the defaults given by the dll when it reads the file will have an iPlacement of 0 which means that it can be put on the map. However these don't have a map graphic so the plot they are placed on will CTD when displayed on screen.


In the C2C_Buildings schema file in the XML/Buildings folder it is still

Code:
    <ElementType name="SpecialistCommerceChange" content="eltOnly">
        <element type="SpecialistType"/>
        <element type="YieldChanges"/>
    </ElementType>
which is wrong.

This is lines 806, 807, 808, right? Just need to change the <element type="YieldChanges"/> to <element type="CommerceChanges"/> , correct?

EDIT: Just changed it and will commit now.
EDIT2: Done
 
Last edited:
I went through an corrected all of them in the Manufactured and Culture folders. Having iPLacement instead of iPlacement is a possible cause of CTD errors as the defaults given by the dll when it reads the file will have an iPlacement of 0 which means that it can be put on the map. However these don't have a map graphic so the plot they are placed on will CTD when displayed on screen.
I think all map scripts considers what terrain the bonus is eligible for, so they will never be placed as they cannot be placed on any types of terrain.

The only issue here is that mapscripts will add those resources to the list that it is going to run trough a lot of code when adding bonuses to the map.
Each extra entry in that list will add a noticeable time delay to the bonus placement code.
It will check if it can place the manufactured bonus for every tile on the map.
Toffer mentioned in the SVN Changelog, that the iPLacement (the capital L) will not work nut i found that in the manufactured area that from this point on i believe ALL PL's are that way . . . (see pic)
That is what I fixed in rev. 9593.
 
Last edited:
I think all map scripts considers what terrain the bonus is eligible for, so they will never be placed as they cannot be placed on any types of terrain.
And the default is all terrains but the probability will be extremely low for placement.

One time I was testing stuff I ended up with a lot of something I thought would be rare because the map script decided to place as many as possible in the empty deserts as I had the BONUSCLASS_GENERAL defined for it. All these have BONUSCLASS_MANUFACTURING or CULTURE so should not be considered as fillers.
 
And the default is all terrains but the probability will be extremely low for placement.

One time I was testing stuff I ended up with a lot of something I thought would be rare because the map script decided to place as many as possible in the empty deserts as I had the BONUSCLASS_GENERAL defined for it. All these have BONUSCLASS_MANUFACTURING or CULTURE so should not be considered as fillers.
You might be right that some mapscripts may try to place them, I don't know the code they all use.
PW, PM, and World, the ones I know how work, would never place those bonuses on a map no matter what the iPlacementOrder is due to them having:
<iConstAppearance>0</iConstAppearance>
<Rands/>
<iMinLandPercent>0</iMinLandPercent>
etc.
 
You might be right that some mapscripts may try to place them, I don't know the code they all use.
PW, PM, and World, the ones I know how work, would never place those bonuses on a map no matter what the iPlacementOrder is due to them having:
<iConstAppearance>0</iConstAppearance>
<Rands/>
<iMinLandPercent>0</iMinLandPercent>
etc.

So with what DH posted and you quoted and with the changes you've made are we going to have vanilla BtS maps messing up now?
 
I was not sure because of DH's statement:
All these have BONUSCLASS_MANUFACTURING or CULTURE so should not be considered as fillers.

Just trying to keep up.
 
I found something odd inside the Animals_CIV4UnitInfos.xml. There are hundreds of units with xml like this.
Code:
            <FeatureImpassableTypes>
                <FeatureType>FEATURE_MANGROVE</FeatureType>
                <FeatureType>FEATURE_SWAMP</FeatureType>
            </FeatureImpassableTypes>
            <FeaturePassableTechs>
                <FeaturePassableTech>
                    <FeatureType>FEATURE_SAVANNA</FeatureType>
                    <PassableTech>NONE</PassableTech>
                </FeaturePassableTech>
            </FeaturePassableTechs>

That makes no sense at all because:
  1. FEATURE_SAVANNA isn't listed under FeatureImpassableTypes so putting it into FeaturePassableTechs does exactly nothing.
  2. Even if it would be listed under FeatureImpassableTypes it would make no sense at all without a PassableTech.
 
Back
Top Bottom