Descriptive Problem Summary:
Adding an object with particles to a mob's vis_contents and then entering a different object's locs will cause visual errors wherein moveable atoms ignore layering and sometimes vanish completely.
Numbered Steps to Reproduce Problem:
1. Run game. Give it a second to generate autotiles
2. Press the System button
3. All the verbs to reproduce issue are in TEST_ENVIRONMENT tab.
addVis - permanently adds the particle to the mob's vis_contents
removeVis - remove all particles in mob's vis_contents
testProcedure - adds the object to vis_contents for 8 seconds, and then removes.
4. While the object is in vis_contents, run around the buildings - inside & out. mobs & objs both experience layering issues
Code Snippet (if applicable) to Reproduce Problem:
Expected Results:
Layering is maintained, icons remain whole.
Actual Results:
Icons are splintered and break layering at seemingly random locations.
Does the problem occur:
Every time? Or how often? Every time
In other games? One development project, but unable to reproduce in a test environment.
In other user accounts?
On other computers?
When does the problem NOT occur?
Problem does not occur when the object with particles is not added to vis_contents.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
N/A - project uses features added in 515
Workarounds:
None
ID:2901649
 Nov 29 2023, 12:41 am
|
|||||||||||||
| |||||||||||||
I tried adding some code to the topological sort that I think SIDE_MAP is really missing for its sorts, but that messed up your tree layering and it actually introduced new issues where grass could pop in front of the building's floor while moving around the interior. It did however prevent neighboring buildings from being affected.
Anyway the biggest reason you're seeing massive layering issues is the big icons. Using big 9x9-tile icons like you do for your buildings, and giving them massive physical bounds to boot, causes all sorts of chaos with the SIDE_MAP layering algorithm. This is compounded by all the eggs in the one building.
To dig deep into the conflict I'd have to enable some debugging output and pore over it for hours to see where the conflict lies, but basically every time something like this happens it's because it creates a topological conflict that the algorithm can't properly resolve.
Some of this stems from a fundamental problem with current SIDE_MAP and ISOMETRIC_MAP support, which is that tiles don't have an inherent Z height, and layer is used to simulate that as far as resolving conflicts. But something like a grass turf should never ever (per the user's intention, not the algorithm) draw over anything else because it has no Z height, whereas a crate sticking up would. Ter13 usually resolves this by relegating all flat turfs to BACKGROUND_LAYER+TURF_LAYER, which uses sub-layers to resolve the problem. (Your building floors would need to do something similar, although the outer part of the building should not use BACKGROUND_LAYER.)
A future refinement of this would be to define proper Z bounds for all atoms, so it's known whether they "stick up" or not. If they never extend vertically, then they can be trivially removed from any layering conflicts.