Description
Disclaimer:
Moved from:
Creators-of-Aeronautics/Simulated-Project#1015 (comment)
This also means that the ticket refers to "contraptions" which for these purposes are but physics objects
Description
I dont think this is intentional, so I am opening a bug report on it. If its not been adressed when I am done with exams, Ill get to it myself. For now I'd just like this ticket to exist cause I doubt I am the only one having build a contraption more than 4 chunks wide (which is about where the issues begin).
Bug:
The current implimentation of contraptions (I think its "dev.ryanhcode.sable.sublevel.SubLevels") do not account for the actual bounds of the contraption in terms of chunk loading. This gets incredibly unpredictable and frustrating the further the contraptions shape is from a sphere and depending on the origin of the Sublevel.
This causes a series of issues:
Players dying from suffocation as the contraption loads in on top of them as the player finally enters simulation distance.
Contraptions despawning while the Player is on it or building or... etc etc.
Contraptions blinking in and out of existence if moving too fast, make the player glitch out of their seat/cockpit and fall down and die (as position updates of the player gets out of sync with those of the contraption and the contraption despawns for a tick or two). This is not only for large contraptions, but all, it just gets worse when the cockpit is further from contraption origin.
The Best Solution: (I could think of)
Create a seperate "tick" (something like "contraptionTick") running pre pre-physics tick. Upon "contraption tick" have a manager ensure that an update from the server is send to all players within a radius of any contraption.
This radius should be the difference between server/entity simulation distance/render distance and contraption bounds (approx).
Should have insignificant performance impact but solve a lot of the aforementioned stability issues. Could also allow contraptions to effectively appear as normal structures within standard render distance, rather than relying on simulation distance.
Also seperating contraption update handling from standard entity simulation might provide a lot of benefits in the long run.
The Easiest Solution:
Simply force load the chunks within the radius by using tickets. Same effect, will cause performance issues some times, especially if there is no check for whether a player is actually around the contraption (as that would just permanently load at least 1 chunk per contraption... which would be costly at scale).
Game Log
n/a
Description
Disclaimer:
Moved from:
Creators-of-Aeronautics/Simulated-Project#1015 (comment)
This also means that the ticket refers to "contraptions" which for these purposes are but physics objects
Description
I dont think this is intentional, so I am opening a bug report on it. If its not been adressed when I am done with exams, Ill get to it myself. For now I'd just like this ticket to exist cause I doubt I am the only one having build a contraption more than 4 chunks wide (which is about where the issues begin).
Bug:
The current implimentation of contraptions (I think its "dev.ryanhcode.sable.sublevel.SubLevels") do not account for the actual bounds of the contraption in terms of chunk loading. This gets incredibly unpredictable and frustrating the further the contraptions shape is from a sphere and depending on the origin of the Sublevel.
This causes a series of issues:
Players dying from suffocation as the contraption loads in on top of them as the player finally enters simulation distance.
Contraptions despawning while the Player is on it or building or... etc etc.
Contraptions blinking in and out of existence if moving too fast, make the player glitch out of their seat/cockpit and fall down and die (as position updates of the player gets out of sync with those of the contraption and the contraption despawns for a tick or two). This is not only for large contraptions, but all, it just gets worse when the cockpit is further from contraption origin.
The Best Solution: (I could think of)
Create a seperate "tick" (something like "contraptionTick") running pre pre-physics tick. Upon "contraption tick" have a manager ensure that an update from the server is send to all players within a radius of any contraption.
This radius should be the difference between server/entity simulation distance/render distance and contraption bounds (approx).
Should have insignificant performance impact but solve a lot of the aforementioned stability issues. Could also allow contraptions to effectively appear as normal structures within standard render distance, rather than relying on simulation distance.
Also seperating contraption update handling from standard entity simulation might provide a lot of benefits in the long run.
The Easiest Solution:
Simply force load the chunks within the radius by using tickets. Same effect, will cause performance issues some times, especially if there is no check for whether a player is actually around the contraption (as that would just permanently load at least 1 chunk per contraption... which would be costly at scale).
Game Log
n/a