Trying to track down a strange bug that changes slate to glowstool.

[alleZSoyez]

I'm not sure what could possibly be causing it. Adding my mod to an existing save turns all the mineable slate on the map into glowstool. It doesn't do this when adding the game to a fresh save, and in all cases other slate items are unaffected (slate blocks, chunks, floors, smoothed slate, etc). I've been looking at it for days and I can't seem to find any reason why it should be doing this, since I haven't touched any of the vanilla items except the plant pots and roses.

An example of what I mean: https://imgur.com/eUiGYo1

While I'm not surprised that my first ever mod has bugs, this one doesn't make any sense whatsoever. Could someone please point me in the right direction? I made the mistake of releasing this on workshop as-is, even with a warning telling people not to add to it to existing saves for this reason, but it seems like some are adding it because of the bug!

https://github.com/alleZSoyez/rimworld_mod_anyplant

[Pelador]

There's a "desktop.ini" file of links to standard resources refs within the texture path folder for glowstool, wouldn't be at all surprised that this might be causing the corruption.

[alleZSoyez]

Ack, I thought I got all of those. I have removed it and checked the rest of the folders for any more of those, but it didn't make any difference in the slate-glowstool mixup.

[Pelador]

This might be a longshot but just following the logic through:

Looking at the mod details a little bit more there might be some strange behaviour as to how immature plants are spawned or generated.

You have changed the definitions so it is no longer defined as a cave plant (whilst also removing the wild references in the base definition), and the error only seems to be effecting glowstool which is the only cave plant with an immature definition and also the graphic for the plant shown on the map looks like the immature definitions.

if the map expects a number of these kinds of plants to exist (has a population) it might be trying to generate them to exist where possible, and this might coincide then with the locations that slate is generated (for some/whatever reason). Might be the best conditions for the plant or something? Unsure how the actual mechanics in detail work.

Though i'm surprised that this then doesn't also occur with the generation on new maps since with the order of things I'd expect it to do something similar, though being generated together as a process at new map generation there is, of course, the chance to resolve and prioritise map desirability conflicts for the placement of items and rearranging things. Something that cannot happen if only introducing a new item to pre-existing map already defined.

Throwing it back to you as a potential thing to investigate, and could be debugged with changing glowstool's definitions, even if temporarily for testing purposes.

[alleZSoyez]

Thank you for your guidance. Tried changing the defs, tried PlantBase instead of CavePlantBase, tried rewriting the entire glowstool def one piece at a time, tried renaming the images/removing the immature one. The only thing that worked was changing the defName to something silly. So I guess "AnyPlant_Glowstool" is now known as "AnyPlant_Glowstool_is_not_a_rock".

I'm not sure how this worked, but loading it into three different saves, it's all behaving as intended... somehow...

Thank you again!

[Mehni]

RimWorld generates a unique hash from the defName.

Sometimes they aren't unique enough and you get a hash collision, which is what happened here.

[LWM]

The hash function (used in IsSaveCompressible, etc) is only used for "generic" items that don't have any variation.  So, mine-able slate, standard boulders, etc.  Apparently, you made glowstools look the same as slate.  Well done, most amusing mod bug so far for 2019!

--LWM