[Quirk] Gold ore being replaced with a terrain added by mod

[Telkir]

Someone's reported a bug with my MoreFloors mod that's baffled me (doesn't take much, but this one seems especially weird). If you take a vanilla A15 colony with no mods, enable MoreFloors, then load your save, all gold ore in the map will turn into a specific flavour of planned flooring, like so:



MoreFloors only deals with terrains. Gold ore clearly isn't a terrain, and it's the only natural "building" that seems to be affected.

There are no errors in the console. The plans can be claimed and cancelled without causing any problem, leaving emptiness behind. If I remove that "Chequer slabs (marble / sandstone)" floor from the XML, reload mods and try loading the save again, gold ore appears correctly. Put the def back, bug returns. Move the def to a different position in the XML, bug still there.



I've gone over the XML of that particular floor with a fine tooth comb and there is nothing different about it compared to any of the other chequered floor defs in the same XML. Perhaps I've squinted at it for so long I've become blind to typos. You can see the full code of the relevant XML here:

http://pastebin.com/Xa40L7rH

The def in question is "FloorStoneChequerMarbleSandstone" on lines 361-370.

Can someone here give me any clues?

[Master Bucketsmith]

That XML looks fine to me. Is it the only XML stuff in that mod? Maybe there's a conflict elsewhere?

[Telkir]

It isn't, but I don't think any of the others have anything relevant to the problem.

Here they are, just in case:
MoreFloorsDesignationCategories.xml
MoreFloorsTerrainsCarpet.xml
MoreFloorsTerrainsNatural.xml
MoreFloorsTerrainsWood.xml

[Kilroy232]

I could have a better look later today at your files but I would suggest removing one .xml files at a time from the mod or commenting out sections of code at a time to isolate where the problem is coming from. Then I would hope the problem would be easy to solve.

Off the top of my head I am not even sure how you would have done this but the only thing I can think of is that you have given something the same <DefName> as the gold and so when the mod is loaded after the core the gold or def is being over ridden

[skullywag]

I had a similar issue in my natural floors mod, I had to remove the affordance to stop it being screwy, I suspect a core issue but havent had time to look into it, try messing with affordances and see if it affects anything.

[Telkir]

Thanks for the suggestions guys. I tried shuffling a few things around on a spare half-hour this weekend and didn't get much further, but I'll try what you mentioned and see if I can narrow the problem down a bit.

[RawCode]

hash collision.
there is some kind of switch for "compressed saves" set it off.

[Telkir]

@RawCode - Thanks, I see in Core that there's a "<saveCompressible>true</saveCompressible>" attached to the "RockBase" def that is inherited by all of the raw ores. Turning that to false solves the problem.

It also looks like I can just change the name of the offending terrain def to solve the problem without having to fiddle with Core, so that'll be the fix for now.

[skullywag]

Why does the name of the def matter? im not following

[Kilroy232]

Why does the name of the def matter? im not following

Ya, I am interested as to how this caused the problem

[Telkir]

I don't really know what to tell you, other than changing the def name by a single character "just works" to fix the problem.

RawCode suggested this is something to do with hashes used when RimWorld compresses a save game. I have no real idea how, but the name of the def involved must be a factor in creating them. If I simply change the culprit "FloorStoneChequerMarbleSandstone" def in MoreFloors to instead be called "FloorStoneChequerMarbleSandstone2", the bug I described in the OP goes away.

So - by some coincidence, the save hash for "FloorStoneChequerMarbleSandstone" must have some kind of similarity to the one for "MineableGold" in Core. Should I start buying lottery tickets?...

Perhaps worth mentioning that this only became an issue in A15; I tested in A14 and encountered no problem.

[skullywag]

Yeah we had a tonne of hashset issues to begin with, these were addressed in one of the minor A15 releases, still not 100% sure on this but I think Tynan should see this, somethings not right.

[RawCode]

there is no way to *explain* why and how this happening, you should open "source" of game in ILspy and check self.

hashing for savegames is faulty thing that will cause major issues later, it's a lot better to avoid any type of compression and just dump savegame data into zipstream, it will provide better results.

[Telkir]

Yeah we had a tonne of hashset issues to begin with, these were addressed in one of the minor A15 releases, still not 100% sure on this but I think Tynan should see this, somethings not right.

Alright. In the scale of things this is pretty minor but I went ahead and posted it as a bug in case it leads to something.

[Telkir]

Sorry for the necro. In the bug thread I posted ages ago, Zhentar and Tynan explained that the system causing this is "working as intended".

But that said, this quirk is still happening in A16 even after the refactoring Tynan says has been done. It's a minor thing and one I'll simply fix on my side for A17, but I wanted to mention it here just in case this anyone thought this behaviour had been purged from the code.

(And, before anyone asks, yes I thought I'd already put my fix into the A16 MoreFloors version, but apparently that one character slipped through the net  )