what are you talking about ? @zee
He tells us to change :
Make sure sv_maxclients is over 32 if you want to use that many clients. Use 63, not 64, 64 might be a very bad idea, or maybe that was hardcap. 64 should work now. Finally, real 64 slots!
Fix your scripts in case there’s any <31 loops to use <255 loops to iterate over players. Players go down from 63+1 now, so your script will be broken if left unchanged.
I changed this line : setReason(‘The server is full: ’ … tostring(cv) …’/64 players…’) and this line local cv = GetConvarInt(‘sv_maxclients’, 64) What is the problem??
Today, we ran a 64-player test with OneSync. We tested 2 builds for one hour each: 934 (linux), and 935 (windows). We had everyone fill out forms describing their experience and note down any bugs they ran into. Here are our results:
Issues reported on both builds:
Whenever we would hit 64 players, or close to it, ~16 players would time out after 10 seconds simultaneously.
Numerous reports of receiving an earth-chicken-kentucky crash. Here is an example: screenshot
When loading into the server, the VOIP proximity would be global for a split second. This could potentially be fixed by deafening the player until all resources have been fully loaded.
No one could blow up gas tanks or any explosive objects by shooting at them.
Damage would not always sync properly when attacking AI or other entities. We had reports of people shooting each other with shot guns and not going down after 5-6 shots.
We’ve received numerous reports of players not being able to hear each other while driving in the same vehicle. It seemed that player positions were falling out of the voice proximity range while travelling at high enough speeds (100+ MPH).
AI would occasionally stop responding to any player interaction. They would not be able to take any damage, and you couldn’t attack them.
You cannot currently punch people (both players and AI) out of vehicles.
Custom ped overlays were not properly showing for other players.
Sometimes MP ped models would have their model reset to default variations for a second, and then reload back to the correct model variations.
Numerous reports of people crashing while attempting to stream various custom assets. Some were for streamed textures, overlays, models, etc. and not specific to any one file: screenshot
Issues reported during the Windows build test:
Numerous reports that whenever one person was having issues with the world loading in for them, everyone in that same area would have an issue with the region loading/unloading. During our test, this was specific to the Davis/Legion Square area, where there were large groups of people loaded in the same area.
Issues reported during the Linux build test:
We received numerous reports that the framerate was noticeably worse than it was on the windows build. We’re unsure what differences would have made this happen.
According to some logs we’ve received from players during the linux build test, people noticed this line spamming the logs more often than during the windows build test: Migrating object 1818 (of type class CNetObjAutomobile) from us to XXX (remote player). If no 'remote-migrating' shows up, that's bad.
The server ended up hard crashing once during the hour-long test on this build. Here’s the logs:
Issues reported exclusive to each build may not necessarily mean it’s exclusive to that build, but rather only experienced in the duration of that build test.
We had 52 participants rate their experiences on a scale of 0-5. Here are their average responses: How would you rate the overall syncing of the server: 3.1 How would you rate the behavior of the AI compared to the stable server: 3.1 How would you rate the VOIP Clarity: 4.0 How would you rate the VOIP Consistency (0 - choppy, 5 - crystal clear): 3.1
This seems like the longer-standing CPU load issues. It is currently unsure where CPU load issues can be made to not directly break the network layer, would it perhaps be possible to run an ETW trace for a future Windows test (and save buffers around the time this starts occurring)?
Also, what are the CPU specifications of the server the test was performed on?
Happen to have captured client .dmp files?
Interesting - thanks for noting this, it might indeed be a good idea to not connect until scripts have had a chance to run.
Did this mainly happen at the higher player counts? This might be related to load issues.
Correct. Positions will be obtained directly from the player entity in the future.
Classical migration issues - @Disquse has usually found a decent method to capture those with low amounts of players and more information would be useful.
Interesting - either the current assumption about player appearance data never exceeding 256 bytes is incorrect, or there’s a second issue touching player appearance.
This doesn’t seem 1s-exclusive - did this happen more often than with 1s disabled? It could be the TCP thread ended up overloaded more often than usual. Client log files would help.
This is mainly associated with large amounts of unoptimized streamed assets, and it’s hard to tell whether or not there’s a correlation with 1s or not - if more players use more different models, streaming memory is more likely to fill up; but similarly it might be the case that assets aren’t getting cleaned on object deletion in a sufficient fashion.
That’s odd. Perhaps comparing client-side ETW traces could help.
Ouch. Linux crash information is practically useless, the only way to generate valid crash information on there would be a custom build and using GDB on a running server.
The timeouts were happening more frequently on the Linux build. We can run whatever tests you’d like, just let us know the syntax you’d guys want.
Both servers were running on a Quad-Core Intel® Core™ i7-7700K CPU @ 4.20GHz
Afraid not. I personally didn’t experience this crash, that’s just what was reported to us.
Yes, we had a consistently full server, with ~8 people in queue. It’s hard to say if this was the cause of it since we never really had low player counts.
I personally experienced this as well. It happened when I was 2 other players in the Del Perro area; there was an AI on a scooter which was frozen in traffic. We tried shooting the AI, and it wouldn’t take any damage. We tried blowing up the vehicle, and neither the AI or vehicle took any damage, however the explosion did cause it to move. I attempted taking the AI off the scooter, but I ended up “colliding” with the AI in the driver seat, and eventually got teleported off the bike.
Yes, when you would hold F on the passenger seat to punch the driver out of the vehicle. It would result in the player doing so to sit in the driver seat simultaneously with the original driver, until the player attempting to hijack the vehicle is then teleported out of the vehicle.
We’ve had this happen before on our normal server, however it’s a very rare occurrence. It seemed to happen more often with OneSync.
I’ll ask for the person to give me their logs when available. It’s possible they may already be deleted by now though.
It is possible. Most of our assets, excluding vehicles, are custom, and we aim for optimization when it comes to these assets. We’ll try conducting a test again with the custom assets disabled and see if it becomes an issue.
We ran a OneSync test one week ago or so, but couldn’t get the voip to work, did you guys have to do something special to get it to work on your server?
I’m not sure this is the place to report bugs but I found a very big bug. If you are in cover somewhere and you shoot, no one else will see that you are shooting but you can kill other players.
