just kidding, expansion-ai is still overriding it which broke it again LOL

would be nice if this was fixed lol

I can say with confidence it's the same problem, the examples I posted were more extreme because they're the ones that get sent to me/posted in discord to complain. In my experience it tends to be more similar to what you showcased which isn't as clip worthy.

Big thank you for further proving exactly the cause @murphey Can I ask what tool that is to test also?

several minutes of this new lag
https://youtu.be/AhfGeK3BdzU?si=mpHj0oLIOnXWmeqE&t=59

REARMED BEING REARMED BY THE WAY (TITLE OF THE VIDEO)
https://streamable.com/chpxgc

another example of the new lag
https://streamable.com/jy9q04

Falling through a window despite not moving due to the new rubber band lag.

Also no, @Funatic it's crashing servers as well. In my cases it was server crash.

Ok well use context clues then, it is related to physics and simulation. Do you have something that moves on it's own, a train, a boat, a building? If so remove it, from what I understand this is not affecting vanilla servers so it is technically fixable on your end.

Just since nobody has said it HERE, remove airdrop/helicrash mods, it seems directly related to the physics simulation.

Put ClearInventoryReservationEx(action_data); before the Lambda and still crashes. Will try removing the ExtendActionJuncture next to see if that fixes it. If you have another potential solution I'd appreciate it.

Maybe related? @Geez This is a client crash with similar access violation.

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.

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.

@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;

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.

In T185470#2687999, @sanguine00 wrote:

I believe the way it is now is the way it was always intended to be - the restock timer triggers when an item his its <min> value, and one of each item is spawned at an interval of <timer> seconds until it gets back to <nominal>.

You need to reduce or remove the timer in order to replenish the spawns more quickly. If you set the timer to '0' then it will bulk spawn all the items back to <nominal> at the same time, which is essentialy what it had been doing before the fix.

In T183412#2648658, @Geez wrote:

It was also mentioned in the changelog:

Changed: Attempting to start a server with ShardIds 000 - 099 will prevent the server from starting up, as those are reserved for official servers

They are not blocked, but they are heavily redirected and almost never flying straight through the leaves. It's not very feasible to hit someone with good accuracy when there is leaves between them and you.

After testing it made me aware of how awful the deflections are with bullets and leaves, could you please reevaluate the foliage bisurf after shooting through some leaves? I find it hard to believe that that is desirable as it is incredibly frustrating for players, especially considering forests consist of majority of the maps lol.

@Geez
Position: <3507.746826, 204.052811, 13009.911133>

There appears to be a new source of lag now, and I'm currently unaware of how it's being caused. This is us testing the new variables (using default settings in this clip) and there is extreme amounts of lag despite the server having 2 players on it, with over 20k server fps.

There is clearly an issue with tree fire geometry.

@Armor good report, it finally makes sense why I would always get handbugged against wolf AI mutants on STALKER servers after seeing your video

should include mdmp for futher diagnostics by the team @vadymbabii

Here's another example of it happening. Just keeps jumping up and down 100 entities.

I highly suggest adding this to your servers so it gives the developers an idea if what the problem is. https://steamcommunity.com/sharedfiles/filedetails/?id=3183607578

@andro_dawton that doesn't actually change anything, the storage still exists there on server and the client when the client walks into network range of it. That would be a really good solution though for the problem is to add a bool/condition to say when the cargo of an item can be networked.

that is already possible with occluders @JerseyD911

Please, it's not fair that STALKER and Escape From Tarkov modders can make cool stuff like this 😢

Performance is looking a lot better after this update. Thanks for the hard work team!

In T172347#2443714, @designful wrote:

Best answer is to just override Inventory Slots in their ColorBase classes so you don't have ANY issue, deleting them was unneccessary. That way we get this great change, and no mods break.

definitely need to sort your hardware situation lol{F3792919}

I think we agree that the problem you're having is not from the fps limit anymore. 50 pop should be a piece of cake to run a stable server on, if it isn't your economy, then it must be your hardware.

Those dips are the likely result of higher memory usage from prolonged server uptime, it happens regardless of an fps limiter.

Wow, there is SO much misinformation in the title post. I run 10 modded 127 pop servers with fps limited at 60 for months now, there is no difference other than exactly what Geez said (less CPU usage).

10 years of Arma 2 buildings, let modders add more rooms, improve Winter Chernarus (TREE LODS), and who knows what else. At the very least give us a reason as to why this isn't possible.

The fact this went on as long as it did is mind boggling. The gun bugging out on proned bodies has been going on for so long, months before I even reported it a month ago (https://feedback.bistudio.com/T176038).

I cannot mod and release new features without being harassed by my players to "fix the lag" instead. Thousands of players are experiencing this constant lag on servers with high amounts of pvp interactions.
This needs to be the highest priority by the programming team and needs to be fixed ASAP, I agree heavily with OP that 1.23 should not be released without this fix.

The dev team does not consist of all programmers, so there's no need to bash them for releasing new features. However, I do agree that the net code is terrible and needs priority when it comes to fixes. It's been years now that the game has been plagued with lag and dsync and it seems the devs are only now beginning to realize it.

@Geez I would confirm with the team that they are aware of this, as maybe now that we have some idea as to what the cause is, we could expedite the fix.

@rupert I was told by another server owner that BodyBags stops this specific issue. Just a disclaimer it is my mod, I don't care if you use it or not, but I don't want to come off as advertising it lol.

So an update 6 months later after going down the rabbit hole of networkobject variable tweaking,

This is still an ongoing issue. More information from the team would be helpful as we modded servers could potentially mitigate the issue until it's fixed.

Can confirm this is occurring and I would assume it's also the culprit for the widespread "ghost bullets" issue that's ongoing currently. I've been given several video's of players emptying magazines on players point blank, having no effect. Please fix :)

because theyre modded.

Best answer is to just override Inventory Slots in their ColorBase classes so you don't have ANY issue, deleting them was unneccessary. That way we get this great change, and no mods break.

I should mention this does not just include bases, this includes almost everything, load in a town too quickly and you will dsync. None of the 1.20 debug shows this happening. It is still making this game a nonstop lag fest.