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

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.

 

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.

 

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

 

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.

 

I think I'm just going to have to get this and use it myself to see what I can find and fix.

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.

 

This upper case issue is now fixed.

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

 

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

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?

 

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

 

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.

That is what I fixed in rev. 9593.

 

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.

 

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?

 

If vanilla mapscripts messed up manufacture bonuses before, my latest SVN change will have fixed that now.

 

I was not sure because of DH's statement:

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.