I’m planning to slow down how frequently the worlds update. I think that will make the updates more consistent and regular. The worlds are all trying to update 2,000 times every second and that seems excessive. The cpus seem to be context switching pretty heavily to try and keep up with that rate. I wonder if any lag has always been from heavy context switching causing erratic updates.
From the git history, it looks like it might have been accidental. Very early on, Boundless’s server loop had no sleep at all, it updated as frequently as possible, using as much cpu as possible. Also very early on, someone added a 500 microsecond sleep to slow it down a little bit. 500 microseconds per update = 2,000 updates per second.
correct me if im wrong but i was sure game as Boundless requires update every time the block count on worlds are changed, place a block during building, demolish, farm, drop regen bomb, killing creature, hunting, doing meteorsupdate, why it updating empty planets? while noone even is at world? there are no farmers, no builders, no hunters
i really was sure it getting s updated only after changing in planetary mesh/block structure? also after appearing new exo/sov and changing in their block structures
is it possible to set updates only after certain actions will be detected?
I don’t expect it to affect much in-game. I bet it might not be possible to notice a difference unless you closely inspect how fluidly other players seem to be moving on the same world.
so maybe make a test
set a time, ask players to log in, do normal activity as gathering, building hunting etc and try to update world every minute? we will tell if we noticed any difference in placing blocks or farming?
or just put test on weekend and we will see what difference we will be able to notice?
A couple of test cases I’d be curious about…
Meteor hunts - A lot of players already experience lag during hunts when 10+ players are present
Players navigating an area with a lot of builds or portals
Everyone going to the same Exo to farm
I’m thinking 20 updates per second instead of 2,000 per second. I think that’s enough to fix it. And everything should keep running the same I’d think.
I posed many of the same questions. In theory, it should not affect anything. My concern was more around what happens when and if the game reaches 500+ players.
As it’s been explained to my other games similar update between 20-30 updates per second such as Minecraft. First person shooters like Counterstrike 2 do 60 updates per second for casual and around 128 updates per second for competitive.
In theory, we should not notice much difference, but if we do it is something that is easily reverted.
I think it might really improve the lag when multiple players are all on the same world. I’m not sure about portals.
Right now, whenever you’re on a world, there are multiple other worlds running on that same server and they’re heavily competing for your world’s cpu. And no world is getting to use it very much because it keeps getting snatched away by another world, which also won’t be able to use it much. I think that’s the root problem. If every world would just back off and chill out for a couple milliseconds this would all be fine.
It’s very cool to see this level of dialogue and engagement with the game. It makes me more optimistic than these forums usually do for the future of boundless. Thanks for that @jon-eric
Hey if 20 TPS works for Minecraft, it should work for Boundless too
I doubt we would even notice any difference in how players are moving around the worlds because I don’t think the server is sending position updates at tick rate? I could be wrong but I guess there is some sort of interpolation going on?
Just a thought, but this could have an impact on gleampops, they have to check the blocks the player is walking on, change the water block to ice of the preset color as fast as the player can walk across it. They have to keep up with a speeding player too. If the check and update isn’t fast enough the player falls into the water and then… the script starts working on the next layer of water instead, or traps the player under the ice layer? Something to check/observe on the test, perhaps?