The OneSync EAP and you


What?? You don’t change either of those files, nor should you ever touch hardcap unless you know what you’re doing.
@RAMEX_DELTA_GTA undo those changes, there is no reasons to change those files unless you’re only changing the setReason().


what are you talking about ? @JHodgson1
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. :man_shrugging: 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??


Neither of those are loops.


Okkkkk I understood so I do not touch the hardcap this line local cv = GetConvarInt(‘sv_maxclients’, 64)


It retrieves the variable sv_maxclients from the server.cfg. If it doesn’t exist, it makes it 64


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:
INFO: User [413] XXX authenticated - [19] [413]
[ACCESS | 56/64] XXX has finished loading as server ID 413 (steam:11000010XXXXXXX).
40a87000-40b47000 rwxp 00000000 00:00 0
40c35000-40c45000 rwxp 00000000 00:00 0
41154000-414df000 rwxp 00000000 00:00 0
4190e000-419ae000 rwxp 00000000 00:00 0
41a15000-41a25000 rwxp 00000000 00:00 0
41a79000-41d41000 rwxp 00000000 00:00 0
41d48000-41e98000 rwxp 00000000 00:00 0
3d7b2600000-3d7b2680000 rw-p 00000000 00:00 0
10b643ee8000-10b643ef0000 rw-p 00000000 00:00 0
11d26ee50000-11d26ee80000 ---p 00000000 00:00 0
11d26ee80000-11d26ee83000 rw-p 00000000 00:00 0
11d26ee83000-11d26ee84000 ---p 00000000 00:00 0
11d26ee84000-11d26eeff000 r-xp 00000000 00:00 0
11d26eeff000-11d276e50000 ---p 00000000 00:00 0
1dc5cd000000-1dc5cd02f000 rw-p 00000000 00:00 0
20da2a080000-20da2a100000 rw-p 00000000 00:00 0
2f6d93180000-2f6d93200000 rw-p 00000000 00:00 0
37a78e380000-37a78e383000 rw-p 00000000 00:00 0
3e6525700000-3e6525703000 rw-p 00000000 00:00 0
3e6525703000-3e6525780000 r--p 00000000 00:00 0
7f4816200000-7f4816300000 rw-p 00000000 00:00 0
7f4816800000-7f4816900000 rw-p 00000000 00:00 0
7f4816bfc000-7f4816bfe000 ---p 00000000 00:00 0
7f4816bfe000-7f4817000000 rw-p 00000000 00:00 0
7f4817114000-7f4817152000 rw-p 00000000 00:00 0
Memory around native instruction pointer (0x7f482d789d2b):
0x7f482d789d1b  83 e1 fe 48 8d 1c 0f 48 89 0c 24 48 3b 03 74 01  ...H...H..$H;.t.
0x7f482d789d2b  f4 48 8b 2c 24 4c 8d 2d e9 bc 06 00 c7 44 24 18  .H.,$L.-.....D$.
0x7f482d789d3b  00 00 00 00 49 8b 04 24 48 23 43 08 a8 01 0f 84  ....I..$H#C.....
0x7f482d789d4b  27 01 00 00 48 89 e8 48 89 ef 48 83 c8 01 49 89  '...H..H..H...I.
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

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.

Would this be the ‘hold F/Y/Triangle’ behavior?


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. :frowning:


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?



Update to the latest build (934 or 935).


Oh Okey, I guess I missed that, thanks, appriciate it


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.


Hello, with the new artifact the server crash on linux from a number of player (20 to 25)


The vehicles are invisible on the One Sync since the last shift and the players do not get along


Quick question, do I change things like for i = 0, 31 to for i = 0, 255
or just <31 to <255?


You change

for i=0, 31 do


for i=0, 255 do




Would for i = 16, 31 do be changed? If so, what would it be? It’s for teleporting to online players.


Probably same principal, change 31 to 255.