You wouldn't know the reason why when you generate from icon states it messes up map instancing would you?
| |
Depends on your map instancing method. If it only saves/loads types of atoms, then variations of the same type will be ignored. It's not a limitation of map instancing in general.
| |
Ah I honestly can't do it on my own. I usually use FA lib.. But can't anymore since the way I generate icons on map. Sucks and I really don't want to have to remap
| |
I personally find that subtypes > instances always, even if it's only for 1 specific dmm file, my reasoning is that it is very hard to manage instances (not to mention the horror that is managing maps on open source projects with something like git).
Although Zeta's implementation was still poor. | |
I personally find that subtypes > instances always For something like SS13, instances are almost never the right option, because your content model is almost always based on modified behavior per-instance. SS13's scenery is very much objective, whereas most RPGs choose a design ideology wherein the scenery is pretty much just wallpaper over an otherwise featureless void. A good way to manage instances is to actually keep a DMM file that contains palettes compiled into the project when in debug mode, but when building a release variant of the project, uninclude the palettes so that any instances that are unused will not be included in the project. | |
+1