Right now, placing a trile in an overlap trile requires a trile in a base layer (layer 0). Additionally, removing a trile in new layers shifts triles from higher indexed layers in given emplacement one layer lower. This is because of how the game is handling overlap layers - it's a sequenced list of triles assigned to an emplacement.
This can be a bit annoying to deal with in an editor - triles in further layers implicitly shifting one back when a trile is removed is not a good pattern. A suggestion I have is to change how we handle such cases to allow non-occupied slots in overlap layers. This would require us to either create a trile instance data which is ignored by the game or append extra information to a serialized trile instance data (sort of how Hammer Editor appends extra data to stuff in VMF files, later ignored during compilation process).
Right now, placing a trile in an overlap trile requires a trile in a base layer (layer 0). Additionally, removing a trile in new layers shifts triles from higher indexed layers in given emplacement one layer lower. This is because of how the game is handling overlap layers - it's a sequenced list of triles assigned to an emplacement.
This can be a bit annoying to deal with in an editor - triles in further layers implicitly shifting one back when a trile is removed is not a good pattern. A suggestion I have is to change how we handle such cases to allow non-occupied slots in overlap layers. This would require us to either create a trile instance data which is ignored by the game or append extra information to a serialized trile instance data (sort of how Hammer Editor appends extra data to stuff in VMF files, later ignored during compilation process).