Conversation
- Moved occlusion logic out of the permission check so that it applies to all players - refactor occlusion logic into a helper function to reduce repeating code - remove onPlayerMove listener in favor of double-scheduled tasks on join
|
I have 1 reported person who doesnt get occluded on my testing server so there might still be some edge-cases causing the join occlusion to not work and I will look into that! |
|
I'm not sure why "pendingPlayer" is a concurrent hash map, also the name could probably use some work. |
|
Conceptually, I like the idea of just firing one check at the start for all players, however using the move event seems like a weird way to do so. What's wrong with firing the check in the join event? |
whoops. okay I forgot to remove the old "pendingPlayers" map.
Previously i had a secondary checkup which would add each player into a "pendingPlayers" map onJoin -> if they wouldnt be removed from the one call after joining, once they move they would trigger a most likely "definite" occlusion call. I removed that because it seemed a little overkill and not fitting for such a small thing. I am still looking at what could cause that 1 Player to not be removed from the list while most others so far did not have any occlusion problems on-join.
Since it was removed in my latest commit the only firing happens in the join event. |
|
Adding a wait in the join event is probably not ideal. Consider using PlayerClientLoadedWorldEvent? |
2 participants
Summary: This PR implements basic player occlusion on join for v1.6.x. This feature helps ensure that out-of-distance players are never able to see eachother.
Primary Logic: Players are hidden immediately upon joining.
Fallback Mechanism: Testing showed it is reliable in one task, but I've added a secondary task that triggers 100 ticks after join. This acts as a "failsafe" to ensure players are culled even if the initial packet is missed.
Configuration:
Added "cull-players-on-join" (Boolean).
Default: false