Apologies for the late post-race round up for last week's event - I was "out of the office" for most of the weekend, and have not had a chance to post anything up until now.
It was certainly an interesting race - I for one had great fun, in spite of the difficulties caused predominantly by the circuit, but I know that there are a few who did not enjoy themselves quite as much, especially after the incident(s) that occurred at the start, in the first few corners.
I will start by addressing the trouble that unfolded on the opening lap, and begin by apologising to those of you who were affected. I can say, with a degree of confidence, that the server was not at fault for the incident(s), otherwise more (probably all participants) would have been affected; but that is not to say that the server was completely innocent. Having watched the numerous videos posted after the event it appears as though there may have been some 'warping' (client-side issue, caused by spikes in CPU usage), and also 'synchronisation' problems (client/server issue, caused either by the rate at which data was being transferred between clients and the server, or clients' network connections) which resulted in 'lagging'. It looks incredibly strange, and as
@Tero Dahlberg has suggested these videos should be forwarded to Marcel and Studio 397 for analysis. If anybody does get in touch then please let me know, and I will also be more than happy to provide the log file from the server as it might be helpful. I would contact Studio 397 myself, but I am incredibly busy at the moment - my apologies.
Going back to the point about 'synchronisation' problems, it's possible that this issue was caused by both the server and client, as has been suggested; it appears as if the client was successfully sending updates to the server (and other clients could see this), but not successfully receiving all updates sent by the server (which would explain the lagging, and why cars were disappearing for the client). If the server upload rate was hitting the maximum limit then more people would have been affected, so I do not think that this was the fault. It is more likely the rate at which clients were downloading updates from the server was the cause of the issue. Other participants did not see these client lag so the upload from the client to the server must not have been an issue.
In such situations, the affected client does not necessarily need to leave the server, or even stop their car (at least not immediately), but they ought to slow down just in case a car suddenly appears in front or alongside when the server and client have successfully synchronised.
Given the number of participants in this event, it is not surprising that such an issue occurred, not only from a network point of view (and the amount of data being passed from the server to clients), but also from a resource point of view. As I mentioned in TeamSpeak, during the practice session, and also above, CPU spikes also appear to have been causing micro-stutters and warping, due to the amount of processing being performed by clients, not only for their car but also those around them. Most (if not all) significant processing operations performed by rFactor 2 are client-side, hence the high CPU usage even when racing online. Sebring seems to be very resource hungry, almost certainly due to the amount of detail that it encompasses; the characteristics of the track surface are like nothing we have ever seen before in rFactor 2 (at least not legitimately), and I firmly believe that this resulted in high CPU usage and spikes. I am of the opinion that several of the bumps and scrapes, which ultimately lead to the pile-up at the beginning of the race, can be attributed to the track and the number of drivers.
Going back to the race, I would like to thank everyone who took part, and in spite of the problems I hope that you also had fun!
I was thankfully able to dodge most of the spinning cars in the first lap melee, and found myself 8 places to the good after the first lap. It was a tough race, not least because I am not the quickest of drivers and I was constantly being chased down, but also the sheer amount of concentration and focus required to keep the car between the white lines at this circuit was just astounding. I was definitely more mentally fatigued than physically fatigued after the race (not that I am ever really physically fatigued, but you do start to feel a bit achy after a while). In the opening stages I was having a great battle with
@Theo van den Brink, and a few other drivers (I was so tired by the end that I cannot remember who exactly I fought with), before he binned it at the exit of Sunset Bend. At that point I thought that it was going to be a fairly quiet race for me, but I too had an incident (thankfully it was only small) and along came
@xiqui to keep me company until the closing stages of the race when his tyres seemed to go off. We were having a great tussle before he started to fall behind, and I then realised that I might not have enough fuel to make it to the end of the race.
@Steve Le Gallez was hot on my heels, but thankfully I was able to hold out with a little bit of lifting and coasting on my penultimate lap. Another half a lap and it would have been game over for me!
The chequered flag came just in time, and I was able to bring the car home in 18th place, which, for me at least, was a decent result. Definitely one of my best drives in a very long time (excluding the Bathurst 1000GT event), and hopefully the first of many more.
I look forward to driving with many of you again in the endurance club event, at Circuit Paul Ricard, at the end of the week.
Hopefully there are fewer issues this time...
See you again on Friday folks!
![Luca [OT]](/data/avatars/s/3235/3235113.jpg?1697196734){kind=avatar}
