We have quite a few objects on our map that are technically in view, but will never be visible, like pipes under the floor.
There's enough that they make up about 20% of our sendmap budget.
It'd be really nice to have some way to mark them as "invisible" to sendmaps if that makes sense.
We've tried some really cursed things in an attempt to get a similar effect to this, moving the objects to nullspace and then attempting to fake them with custom "get contents" procs and such, but that's horrific, and way too fragile.
I realize that entirely removing them from the objects that get iterated over is impossible, because it'd require essentially duplicating how objects are stored, but if possible it would be great to have a way to lessen the cost of that iteration.
ID:2778883
 Mar 30 2022, 1:26 am
|
|||||||
| |||||||
|
Apr 11 2022, 1:16 pm
|
|
Armhulenn
 |
+1, there is a MIGHTY need for this!
|
This would be an EXTRAVAGANT feature to have, +1
| |
This would be of great help for a project of mine, if nothing else as a high level tool.
| |
I'd murder for this. We can sorta pull off visual-only objects by jamming them into vis_contents at a location, but we can't define physical-only objects.
This would open up a lot more avenues for dealing with the invisible performance suck caused by using object-oriented map data hinting techniques. | |
+1, would help in improving performance.
| |
I'd be very open to this if I could figure out an implementation path to it.
SendMaps() operates by looping through all the objs and mobs in a visible turf's contents. Having something be physically present but not map-relevant wouldn't be doable without having some alternate form of storing contents, like a second set of linked lists for objs and mobs. This would complicate anything looping through contents, plus it's an extra 8 bytes for anything that can hold contents. | |
Is there anything particularly unusual about the way contents is implemented? I know objs and mobs are stored separately, but is each of those just a typical linked list? I don't think the extra 8 bytes is avoidable, but depending on how it works right now, I can think of a potential method to (mostly) avoid extra complications in looping through the lists.
| |
For what it's worth I really just want this so I don't need to spend 40% of the tick on sending people wires and pipes.
Something like threaded maptick would solve the same thing. | |