ACC Blog 1.2 Multiplayer & Rating changes

Next to the big CP server update (covered in this dedicated thread), 1.2 will bring a few big and small improvements to multiplayer and ratings:

1) Multiplayer CPU improvements
With the last update, we removed the artifical car limits for private servers - and we were very happy to immediately see 60+ car events running races at Spa. Which of course is the ultimate test for the hardware, and quite a few users had to abort racing and leave server with 50 to 60 cars.

https://clips.twitch.tv/AmusedShakingWoodpeckerPeoplesChamp

We now could say "50 cars is a great achievement", but.. With the 1.2 version, users especially with medium/good CPUs should be able to run significantly more cars before the "99% CPU occupancy" warning kicks in.

Please note, this does not (necessarily) increase the fps you see, but fundamentally changes the amount of cars the client can handle within the defined behaviour (going past the 99 warning can and will decrease the physics frequency, introduce lag and errors in the FFB).
To run such big grids, it is still recommended to adjust the video options and specifically reduce the "Visible opponents" count to a fairly low number (15-20 or less). Also running those grid sizes you should be very sceptical of any "EPIC" video option, especially shadow and mirror related (read it as "SCREENSHOT" level of detail).

Spoiler: more details

While the exact improvement depends on the system, hardware and configuration we are sure there is quite a big jump. During our tests on MrGits big grid, the gain was in the range of 200% to 300%, allowing certain CPUs (like Ryzen 1700 or i7700) to run below 40% CPU occupancy at 60 cars. Those CPUs were at/above the limit before. Even older CPUs like the i5 3470 (!) was dropping from "hopeless" to 70% occupancy, which wasn't comfortable but allowed to participate in the race.

We are extremely happy about this change, as this effectively allows many ACC users to join the big grid races. For the next one I demand that we see the 82 spa slots being filled so I can screenshot a "the server is full" error message.

2) Increased grid sizes (for nonpublic servers)
So now we can run big grids on Spa, that's nice. For leagues, we also imlpemented multiple pit slot assignments, which will enable leagues (and any pw protected server) to run bigger grids on other tracks!
So far Monza and Paul Ricard are suited to run 60 cars as well, and we will increase the grid numbers for other tracks in the future.

https://streamable.com/u59gh

Spoiler

Please note that this means two (or more) cars share the same pit box, causing visual overlap during pitstops and spawning in the pits. The grid positions on the track are of course unique for both formation laps.

Special thanks go to @MrGit@Twitch who is running a semi-public Big Grid event every week, helping out with testing big times (and also providing nice video material)


3) Netcode improvements
We went to great lengths investigating the ACC netcode during the past weeks, and could locate two improvements.

a) Fixed a bug ruining the timing of the server, dependent on the server's operating system. This could lead to constant prediction errors that the netcode was trying to overcome, resulting in cars moving back and forth
b) Slightly changed the balance between agility and smoothness towards smoothness

Important note: Even on latest servers and clients, cars still may be moving unnaturally - this is unstable latency and happens especially when this client's internet connection is either bad or overburdened, for example by live streaming.
If all the cars around you have this behaviour - it's your end.

Spoiler

The timing bug was proven to be present on Windows Server 2008 R2, which is possibly the most popular ACC server hosting Windows OS (by far). Newer servers may have had less issues.
A quick comparison from testing on a 2008R2 server, while I was spectating two cars with the exact same ping/setup only a few minutes apart.
Old server:
https://streamable.com/hi8pq
New server:
https://streamable.com/s7cew

Another hint is the km/h displayed for remote cars you spectate. If this is oscillating, this car has issues with the netcode prediction (caused by the server bug or unstable latency). This is a notable difference in the both clips above; the second one with improved server is as smooth as a locally calculated car.

4) Additional BoP
Many will remember the ballast and restrictor option in Assetto Corsa (1) - now leagues and community server admins can use similar tools to tune and balance car and driver performances.

There are multiple ways to manipulate the MP specific BoP, but in any case you will see the corresponding ballast (in kg) or restrictor (in %) in the timetables:

Spoiler: more details

While the ballast still just adds the mass to the car, the restrictor will behave different compared to AC1. Now you can read the value as % power penalty at max rpm. Still it limits the air intake and reduces power for high revs. It's a good tool to balance top speed - but drivers beware: changed power curves may result in different (optimal) upshift rpm. In average you want to consider shifting earlier the higher the restrictor is, but it depends a lot on the car, engine, turbos and whatnot.

Additional ballast and restrictor will not change the Blancpain BoP, which means it's always an addition to the selected season (2018, 2019, Intercontinental) and track combination BoP.


It can be applied in 3 different ways:

a) Via bop.json: a new configuration file that allows to add track-carmodel specific ballast and restrictor values. If you for example think the McLaren is too quick at Silverstone 2019, but good for the other tracks: Just add 3 or 5% restrictor for this combination, and all McLarens will spawn accordingly
b) Via entry list: this is meant for leagues who follow concepts like success ballast. Simply add the values to the entry list's car entry. This is additive to the bop.json values, so the current championship leader may receive another 10kg on the McLaren in Silverstone of the example above.
c) Instant action via admin commands (/ballast <carNo> <value> and /restrictor <carNo> <value>). Will overwrite both entry list and bop.json configured values, and just set to whatever you want.
The change will vanish once the car left the server, nothing carries over to the next poor soul joining. If the same driver rejoins in the same car, defaults according to a) and b) are applied again.

Important remarks:
At the moment, this is active on public servers. Please use theese tools responsibly and with small adjustments, otherwise we are forced to restrict the feature set to private servers only.

Additionally, the original BoP is a lot better than you may think, which will effectively make it incredibly hard to improve it. Testing real race pace is a collosal effort, needing alien level drivers with dedicated setups doing full stint test. Please don't fall into the trap to try to balance hotlap performance - critizing BoP is easier than actually doing it better. A good idea may be some success based ballast for car models in consecutive league championships though.

5) Safety Rating (SA) improvements

In general, many small things have improved the SA rating, but in total this will have quite some positive impact. A TL;DR list:

a) finishing races will regard bonus trust, increasing the SA rating
b) improved relative impact speed determination, allowing us to use better algorithms for paint trade action without consequences (especially in singleplayer)
c) introduction of a concept that will assign less OBWPs for certain situations (or none at all), if the other car matches one of several mistake patterns
d) due to several fixes in the AI depeartment, we could begin to rebalance SA in singleplayer as it was originally designed. Overall the AI is now both very competitive and clean, allowing SA to consider accidents in SP as "most likely the human's fault"
e) OBWPs collected should be lower in total, increasing the SA rating (especially for drivers with less mistakes on their side)

Spoiler: more details

The Bonus Trust is applied based on race distance. The longer the race, the more Bonus you get. But you have to have this mileage, there is no point in waiting in the pits until the end of the race and then do one last lap (the bonus would be worth one lap, not the race distance the others did). Apart from that the bonus is meant to be an incentive to drive, so there is no dependency to anything else. As this may even lead to lonely races on abandoned servers, we will assign this Bonus even to Hotstint sessions. They are the perfect training and preparation for actual races.
However, the SA math works in a way that this is a nice addition especially for drivers finishing what they've started - but it's not a tool to max out the SA rating (simply isn't possible without racing at least in a safe distance).

Anything that should prevent (or reduce) OBWPs was revisited, finetuned and obviously corrected if something was wrong. This alone will be a game changer for good drivers, especially as the system now is reasonably tolerant concering paint trades.

A MP-only bug for the contact bag (protecting all but the root contact partners from getting OBWPs assigned in mass collisions) has been fixed, now it works reliably in a very important section of the "advanced" SA rating.

Additionally we fixed a bug sometimes calculating the wrong impact speeds (could be too low), which will both make the received damage more consistent, but also allows much sharper handling of impact speeds in the SA rating.

While we are always very careful about deep analysis of accidents (which is something between "difficult", "dangerous" and "impossible" on a logical layer), you may notice that there may be a few accidents where you aren't penalized for. This is not a mistake, but the result of a lot of work. Sadly this can't be extended in unlimited ways, but if our analysis of "most frequently happening types of accidents" is correct we should see quite some impact.
The loophole we use here is that the analysis only happens on elements that are out of the control of the car in question; this way not getting OBWPs cannot be influenced, enforced and therefore exploited. But that also means many accidents will be outside the parameters for the necessary statement "the other car was guilty WITHOUT DOUBT no matter what you did".
In the core, our SA system is still using the statistical approach, now maybe with a few extras for an even sharper distinction. We also stick to opinion that there is nothing wrong with the statistical system using a 1:1 distribution, even though it may not feel like that in the heat of the moment.

The AI team found improvements in the AI's awareness and could fix both AI vs AI accidents as well as AI cars misjudging brake distances towards the player car; for SA this is critically important. The SP SA had to consider that the AI did mistakes, and therefore reduce the OBWP impacts. The current AI works outstandingly well, and allows SA to go back to the default view of "contact is human's fault with very, very high probablility". Still the "innocence" math is in place also for AI, that means hitting an AI car that was rejoining or for some reason overshooting the corner will most likely not assign OBWPs to you. Same for mass accidents, though we don't see them anymore in SP.

Overall we expect the SA ratings to raise in average, and raise more for better and cleaner drivers. This inflation is not a big problem (except everybody ends up with a 90+ SA rating), in the worst case "80" is "the new 70" .
There is a substential increase in the qualitative statement, so it is entirely possible that good drivers do see a bigger jump of something like 70-90, and read that somebody else made it from 40-60 => please don't fall into the false theory that the ratings in general increased by 20, and 90 is the equivalent of the old 70. I bet there are drivers who will not see any improvement (or even decrease further), and some may only raise 2 points in the same scenario.

But we will monitor the overall numbers and apply adjustments if necessary.

6) Wall contacts are now relevant for track limits

In consideration of you-know-which-track, ACC will now regard (significant) contacts with walls as track limit. This will

a) invalidate laptimes
b) may cause penalties like cuts (dependent on a potential laptime gain)
c) be part of the mass accident logic, so a car bouncing off a wall into a third car won't give the third car OBWPs
d) reset track medal progress

Spoiler: more details

"Significant" means we try to allow as much wall contact as possible - as this event is already a frustration. But at some point we need to draw a line to prevent "using" walls for an advantage. Rule of thumb is if you aren't bouncing off or use the wall to slow down the car, you should be fine (but better stay on the black stuff in the first place).

 

bump