Something you can also add is a boolean that allows/disallows a containers contents to be networked. A good example of something you can apply this to would be a barrel. Opening the barrel would begin the networking the contents to networkRangeNear like it already does, and closing it would clear it up. This would make it so inactive storage doesn't waste server/client resources.

Hello designful.
Can you please send us the server config with which you experience this problem?

@Geez

networkRangeClose = 15; //I lower this to stop the contents of storage from lagging players + its unnecessary to see contents beyond lootable range
networkRangeNear = 35; //I lower this because its pointless to have stashes, loose loot, visible to cheaters 150m away
networkRangeDistantEffect = 4000; //default
networkObjectBatchSendCreate = 10; //default
networkObjectBatchSendDelete = 500; //increased because deletions seemingly don't cause any dsync
networkObjectBatchCompute = 1000; //default
networkObjectBatchBandwidthLimit = 0.3; //lowered because there's SO many different networking problems that will randomly cause lag - Example: https://feedback.bistudio.com/T177400
//rest is default
networkObjectBatchEnforceBandwidthLimits = 1;
networkObjectBatchUseEstimatedBandwidth = 0;
networkObjectBatchUseDynamicMaximumBandwidth = 1;
networkObjectBatchLogSlow = 5;

I am aware that lowering networkObjectBatchBandwidthLimit will introduce delayed networking, however it is currently the ONLY solution available to us to mitigate against constant network dsync (players rubber banding), along with manipulating the network bubble ranges.

Right now I'm seeing extremely good performance, unlike anything I've seen in years because of that limiter. However it has it's flaws as I mentioned in the OP. There can still be lag, which PlayerIdentityBase::GetInputThrottle() will return a non zero number when it occurs, things take a lot longer to load. But in return we get much smoother movement when just exploring the world despite there being thousands of bases.

If things were properly networked based on the distance away from you, rather than just complete random is what it seems to be, then the slower networking wont actually be as visible to the average player. Instead though, you can be loading a base 900m away, while there is loot on the ground in front of you not rendered.

Also, can I ask why there isn't, or if there is, any configuration for the client Input Throttle that gets mentioned in PlayerIdentityBase::GetInputThrottle()? Because as I mentioned, anytime it returns a non-zero number, that client is going to rubber band/lag.