Open ahicks92 opened 1 week ago
Funny followup here.
if you go down the above list by the time you get to registering destruction events, actually the items at that point might as well be considered equivalent for all practical purposes. While we technically might care that two rocks are on one tile this doesn't happen in the first place and so what if you mine one before the other?
Point being I think we can just drop the last step and no one will notice for the life of them.
Sounds like you figured out a really nice way to do it on the fly. You can tile cycle with it too, right? I think it would be a nice upgrade.
yes. You can tile cycle with any stable sort. There is a cost of acquisition but the order is the same every time you call it modulo changes to the tile itself.
We need this for space age support. The chances of us using the current mechanism successfully for multi-surface and contexts where the player and the viewpoint are on different surfaces is...nil basically. SO yeah good luck to us if we don't.
I'll triage 2.0 stuff when I get a chance, got busy.
Space age because not only will the player be on multiple surfaces, they may be working on multiple surfaces at oncec
Because it's unclear how to get a stable order of entities, the mod currently uses a per-tile cache which it consults and creates as the cursor moves. This has all sorts of issues, not least of which include being horribly awkward with multiple surfaces and requiring an explicit refresh always just in case some code path you might expect didn't. The scanner however has revealed the fix we need for that: if you register the same entity for destruction twice, then it will always return the same u64 id. This is expensive, so we complicate things a bit. The following algorithm produces a total order over all entities, while avoiding registration when not necessary and doing what we "prefer". We write these from the perspective of the lua comparer, so the first in the list which can establish that a is less than b, stop:
a.unit_number < b.unit_number
.In other words we only have to use the register-for-destruction trick in the case that both entities aren't something with a force (because all entities with a force have a unit number) and both are also the exact same prototype. This almost never happens. The only cases of it are overlapping acid streams, corpses, and other decoratives. Even then it's rare.
We thus can write this function:
And clamp the players' index into that array as needed.