You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, for every AIR block that needs to be lit, a new BukkitRunnable is scheduled to revert it. This can introduce a significant overhead when player count arises.
Maybe we can insert all lit blocks into a queue and have a scheduler pop the last element? But each player must have a personal scheduler. This idea will be scrapped entirely in favor of lighting using packets.
Update: It turns out a lot of issues arise with the initial approach of swapping air blocks to light blocks. The lighting logic must be redesigned to use packets and properly lit a location, instead of replacing blocks with LIGHT material.
The text was updated successfully, but these errors were encountered:
Currently, for every AIR block that needs to be lit, a new BukkitRunnable is scheduled to revert it. This can introduce a significant overhead when player count arises.
Maybe we can insert all lit blocks into a queue and have a scheduler pop the last element? But each player must have a personal scheduler.This idea will be scrapped entirely in favor of lighting using packets.Update: It turns out a lot of issues arise with the initial approach of swapping air blocks to light blocks. The lighting logic must be redesigned to use packets and properly lit a location, instead of replacing blocks with LIGHT material.
The text was updated successfully, but these errors were encountered: