First levelset I'm trying this in -- emc_freak_mine_2_easy -- I see no key or bombs indicators.
Self-build 4.2.2.0 binary, EMC 3.1.0 installed, new 'show dynamite and keys' setting turned on (default).
Switched to emc_forgotten_mine_2 -- it works there.
Modifying emc_freak_mine_2_easy/graphics/graphicsinfo.conf to match (adding 'include: gic_chipset.conf', copying in that file + RocksChipset.png) does not help.
emc_ace_mine_1 has the same issue; it is the referenced graphics set in emc_freak_mine_2_easy.
The package provides 253 identical copies each of gic_chipset.conf & RocksChipset.png. Can't those live in some parent directory and be found by the automatic chain of fallback locations? (I think such a thing exists :)
> First levelset I'm trying this in -- emc_freak_mine_2_easy -- I see no key or bombs indicators.
Well, I'm going to guess you were not able to reproduce this, as it was a config / setup error on my part. There might be something RnD could have done to mitigate it, though.
Actual names were different, but I have since confirmed that any names will be found, even e.g. '.hide.EMC-3.0.0'. I don't even know why I imagined '.hide' would omit it from RnD's scan!
I'm not sure what actual order they were scanned in. It might depend on the exact details of the names, and I don't actually remember what they were at the time -- I renamed them multiple times in discovering the actual issue.
The possible mitigation has to do with this. Somehow I was getting hybrids, where e.g. the new emc_freak_mine_2_easy config was being read, but when it referred to emc_ace_mine_1, it was getting an older config of that.
Three possibilities, in what feels to me like most- to least-sensible:
(1) define a pathname syntax which means 'ignore' (e.g. '.hide' on end, or 'starts with dot', or whatever)
(2) emit a torrent of warnings about duplicate levelset names (then I would have noticed and fixed the hierarchy long ago)
(3) when resolving content implicitly or explicitly referenced by a levelset, prefer the so-named content from its own directory path hierarchy over any others of the same names in other 'less related' paths (i.e.: diverging more parent directories away)
Actually 1+2 is probably best. Unless this exposes a huge pile of existing duplicate names (but in that case there's probably a data issue to resolve...)
My new directory structure looks like this, and seems to work correctly: