Ping - Updated OP for Update 7.
Hi,
Just went on the test server to try the rate limiting.
First of all I have noticed that even having set a low chunk download rate, my line is saturated. => ~340kB/s = ~3Mbit/s
Is there a way to configure the chunk download rate rate in kByte/s or kbit/s somewhere ?
I think the low, medium, high, maximum does not tell a great deal when dealing with different line speeds.
I think that it does not make sense to put too much effort into a workaround to get people to be able to play at low chunk download rates. It would be better to invest some time into rethinking the chunk handlers, f.ex. A-sync methods, CRC comparison and the like (there are many possible techniques)ā¦, as the chunks are anyhow pseudo-random generated and to only download blocks that need to. This would not only benefit those with low speed lines but the whole chunk handling would improve.
I donāt know how the chunk handlers are implemented, but my advise would be to solve it from ground up and not try to cover/repair cracks.
Hope I donāt extend too far here 
, please donāt take it as an aggression, just me thinking out loud.
I do love this game and I really think it will be something great. Great things take a great foundation and a lot of time and you are on the right track.
2 Likes
Hi @Kueder
Weāre always happy to get ideas to improve Boundless!!
I agree that the current information isnāt too helpful.
Itās currently limiting the number of chunks requested in parallel per second and as the chunks can vary in size this means that itās not strictly a pure bandwidth limit (in the Mbit/s sense.)
However, I agree that it would be better to say Low 15/s, Medium 30/s, High 60/s, and Max unlimited. We can also add lower rates. You can currently customise this directly in the boundless config file.
On Windows edit:
c:\Program Files (x86)\Steam\steamapps\common\Boundless\user_settings\NAME\gameoptions.json
to include:
"chunkSendRate": 8
or lower.
Be careful editing this file, if you corrupt the JSON syntax the game will likely fail to load.
(Whilst Iām not an expert in this particular part of the engine) we do already load the chunk asynchronously. Whilst the chunks are originally generated the process requires lots of information about the surrounding chunks and biomes as is quite expensive. Additionally we need to serialise changes other players make to the world and the state of world and resource regen - so sadly we canāt generate them on demand. (Which the engine originally did.) The chunks are also stored and dispatched in a compressed form.
We do still plan to add local chunk caching so that if the chunk hasnāt changed it doesnāt need to be re-downloaded from the server. This will help reduce bandwidth when reentering the game, but will not help when going somewhere new.
Also happy to share ideas.
3 Likes
Now tell me James where would one find this chunk cache once thats added, hmm? Iām sure it would have all sorts of useful info about hidden resourcesā¦ 
Thanks James for the reply
I will test it out.
Iām aware that chunk generation needs a lot of the surrounding chunks data but it all depends on what data is stored within a chunk or even voxel, on how the data is stored and so on.
Caching will be a good solution and many games do it that way.
There is no jack-of-all-trades solution for this kind of requirements anyhow and am happy to hear that you think about doing it that way. I still see a hindrance(might be big deal or might be not) with how you handle non-claimed chunks. As these are ,I guess regenerated periodically or partly regenerated if there is a difference, they might/will differ from the cached chunks.
I know itās a bit off-topic but is this resources distribution system staying in place like it is now or are you thinking of other possibilities? I personally like ore to be much tougher to find and mine (higher yield amount) and have yield per hit and not be repopulated. This would make mining a lot more pleasant for people who love to mine and find resources. The now in place system is really suitable for vegetation in my opinion but not so sure for ores/underground resources.
Wilderness Chunks (chunks outside of a beacon) are regenerated and would invalidate any simple absolute client cache. But we estimate that these would still be a small percentage of the total chunks loaded for any position. Hence the caching would still be a significant bandwidth win.
(Although interestingly many players are meshing bound, where the cost of converting the chunk into a mesh is slower than the download.)
Iām not quite sure what youāre requesting here.
Mineable resources are regenerated into different locations once gathered.
Whereas the landscape is regenerated exactly as before.
Not requesting, only interested in roadmap.
To me it seems like the resources are regenerated periodically on all non-claimed (so no beacon) chunks. F.ex. a harvested tree on a chunk is always regenerated the same as it was before, a mined fossile on a chunk is maybe regenerated but you are correct, the chunkās primary composition is the same, but the mineable resources(fossiles, tech, iron, copper, diamonds,ā¦) may not be present in the same chunk after regeneration. Or do I miss something here ?
Yes - resources are redistributed but blocks are not.
Ok, just what I suspected. Thanks!
I donāt play too much because of the issues and therefore canāt give a lot of feedback.
Iām looking forward to chunk caching to see if I can finally enjoy the game as I want.
I will of course test the new implementations done to counter the latency issues
Thanks James and keep up the good work!
Hi James,
I somewhat tested the Chunk download rate settings.
The only thing that is a bit unfortunate is that I have approx 100ms latency to the test server.
I set the rate to 6 now and am pleased with the result. The chunk download rate is approx. 2Mbit/s.
This makes some room for the web handler. I can no longer see the rubber banding effect and can move about without ābeaming/flashingā around. So this now resolves the uncontrollable behavior of the player. I have some synchron issues with the hit animation with the actual hit sound/crack animation but I guess that has something to do with the bad latency.
Btw. I never had the meshing issues, I have here my reinstalled audio workstation 
with 6 cores no issues there as far as meshing is on the cpu.
I have not tried but on the production server this would not yet work right ?
I have tried with higher than 6 values for the chunk rate that did not saturate my line, but I guess they did not leave enough headroom for the whole bw requirements.
So 6 is what has done the day for me.
Did you try reducing the chunk loading lower? I was just testing with 4 and itās playable. (Obviously takes longer to load the world.)
Yes, read the one before yours.
The latest Live release includes the chunk download limiting.
Nice!
I will test a bit later then
Itās getting worse with the new update. Now I have rubber banding of my mouse on Therka. Before it was just on other planets from other servers and rarely on EU Server.
Where exactly do I find this Bandwidth Limit? I canāt find it in the ingame menu.
@DarthNott you can find it by pressing ESC key then the crank Game Options and down the list you will find it -> Chunk Download Rate.
2 Likes
boing - updated OP for Update 8.
Tested on Live and I confirm that it is working.
But I still have animation synchronization issues.
The hit count seems to work, meaning I have a persistent hit times for the same block time with the same tool. There is some rubber behavior when exiting a machine f.ex workbench. It is a tiny glitch but one can feel it as the player does not respond immediately to control input, but for an early version seems within OK to me for now, but will need some investigation later.
Would it be possible to capture a short video of this whilst displaying the debugging details?
I can try it, but have never done such thing, so no promises.