About that maybe-server-api

Along with the longitudinal spline pos, it'd be nice to have lateral, normalized to the track boundaries (0 at one boundary, 1 at the other - outside that range when off track)

Obvious applications in 'region-aware' type apps like helicorsa but also a reasonably detailed way to describe offtrack incidents without needing to understand the circuit.

 

some small update.

I've managed to add the normalized spline pos to the protocol.. so the code to read the ACSP_CAR_UPDATE packet now looks like this:
Console.WriteLine("ACSP_CAR_UPDATE");

var car_id = br.ReadByte();
var pos = readVector3f(br);
var velocity = readVector3f(br);
var gear = br.ReadByte();
var engine_rpm = br.ReadUInt16();
var normalized_spline_pos = br.ReadSingle();

Console.Write("CAR:" + car_id + " POS:" + pos.ToString() + " VEL:" + velocity.ToString() + " GEAR:" + gear + " RPM:" + engine_rpm+" NSP:"+normalized_spline_pos);


I also attach an example for the json file we get at the end of every session. All the json files are saved in the server folder under "results/", the UDP gets called as soon a new json report is available and is passed in the filename of the json.

The json report is much more verbose (it's repeating car and driver all the time) because of the way the server works, there is no guarantee that only 1 drive will drive a car per session.. so for every lap/client event, the driver is fully expressed.

let me know if you see something else that can be useful.. next little thing to add is going to be tyres off the track and loss of control.

 

Great !

Going to bed now, will look at it tomorrow, but thank you very much to include all that new info.

It's looking pretty good.

Sent from my SGH-I337M using Tapatalk

 

Thank you very much! I was just about to ask about the numberOfTyresOut, but it's already being planned!

One small question: In the current protocol there is this field in the "Lap completed" packet

- byte cuts

I assume that this is the number of detected cuts in the lap. Does this need penalties enabled to work?

 

@Lord Kunos , I'm wondering, if I may discuss a possible change in the API design regarding the realtime report here. If I understand the design right, you get one UDP packet per car each x milliseconds. This will probably result in a high udp packet rate. Is there a use case to track a single car of the server and ignore others? The most common use case will probably be to track every car on track. So I'm wondering if it'd be possible to put all the cars in a single UDP packet resulting in only 1/15 to 1/30 of the UDP packet rate on the server (of course with larger packets, but I assume the OS overhead will be mostly triggered by the number of packets)?

I understand if this is too late to discuss; I just thought I'd ask...

Greetings
Neys

 

I have a big wish at the guys who are going to make popular server plugins:

I think iRacing's no fault safety rating works pretty good, I think it's not worth wasting time trying to automatically give blame to a driver based on impact position, relative speed or whatever. Just assign the incident to both parties, the bad apples will collect more incidents anyway and the system works by itself. A system like this should be fairly easy to implement, a simple ratio of km/incident (maybe scaled to a meaningful range, and maybe make the system only consider the last 1000 km) and you are done. A system like this is a must have if we want to divide "clean racers" from the rest by simply requiring a certain minimum rating for server entry (at least in peak hours).

And I think iRacing's iRating also works pretty good, in my more active times over there I pretty much knew where I was going to finish at the end of the race based on the iRating, no matter where I started.
But there is one big flaw in a "serious competition" system like this, and here is where my wish comes in: Please implement a rating that rewards driving many races. Or in other words, my biggest gripe with iRacing's system is that racing less but perfectly prepared is the best way to have a high rating, which means that many people would only race one race at the end of the week and be done with it. Hours and hours of practice, then one single race, and that's it.
Please please please create a system for AC that rewards doing a lot of races. Even if it's not going to be the most accurate rating for skill, I think a system that encourages you to race often instead of making you afraid to lose points is the way to go!
For example, implement a rating that just adds race result points (25, 18, 15, ...) on top of each other. Obviously doing a race on your own shouldn't score points, but I'd give full points (25 and 18) for both drivers in a two car race (if they finish). This will also encourage people to join less populated servers instead of wanting to join THE most populated server and wasting time waiting for a free slot (maybe even for a free slot of their favorite car, damn, we need to get rid of the fixed entry list one day).
In the end the fast guys know who they are, they don't need a rating that proofs their skill, why not have a rating that rewards driving often, this will benefit everyone the most, imho.

I'm very curious to see if there will be many concurrent implementations of an AC rating plugin or if there will be one common project where people work together to create something global.

Cheers,
Tom

 

Absolutely. At least on my experience it is way much better to have a less frequent bigger package of data than smaller high frequency packages flying around.
That makes me wonder if would not be a better approach to include collissions, lost controls and tyres off on the same driver data package instead of having independent events.

 

@Thomas Gocke

I am pretty sure there will be very good implementations of driving ratings based on certain rules, stats and endless parameters. In order to reach that point we need to ensure we are gathering all required data in order to provide all the information that will be used to generate the ratings.

I see on my crystal ball not to many server plugins but probably much more different implementations of rating systems that uses some of those plugins.

 

very good observation.. some thoughts:

- One big packet is surely better than N small packets. For a start, every packet has an UDP header that can become a big part of your total send rate if the packets are small. The very first version of AC Server used what I call "megapackets" for the car updates, which is exactly what you are describing, and the bandwidth usage was much better. Currently the server isn't using megapackets because they can, in the worse case scenario, double the latency between 2 clients.. but I am considering retrying the megapackets for 1.3 because of the huge bandwidth win and the fact that it becomes very easy to get a feedback on the connection quality (the famous Q factor ) because you know you expect N megapackets x second from the server. Also there is a theory around that internet routers around the world will be less likely to drop a big UDP packet than a small one.. but again, we're in the realm of assumptions here.

- Remember the server is already generating a massive traffic, the UPDATE packets between server and clients are slightly bigger than the one I'm sending to the UDP Plugin (for example, they also contain rotation information, wheel speeds and a couple of bit flags) and they are going at around 20Hz. So a plugin running at 1Hz (TBH I can't see why running it any faster) is, in the grand scheme of things, nothing to be worried about, especially if it's running locally (and, being UDP, I strongly suggest you to do so.. running of the net is possible, but then you're in the hand of the flying spaghetti monster regarding what you get and what you don't)

- Bigger packets might run into the MTU size affair.. I admit I'm not a low level network expert, but every time I've looked into it I've found the assurance that you can never rely on anything at all.

So to recap... I think it's a very good observation, but that, considering the amount of traffic we can expect and the assumption that the traffic will be local, going megapackets for the UDP Plugin might now be a huge win after all.

 

Do not know if this would be the right place to suggest some modifications to the JSON structure.

Also, I formatted the JSON for readability using a new line after a block. It is cleaner for me to look at it, but if you are not comfortable we can change it to the standard formatting.

Code:

{
   "Type" : "RACE",
   "DurationSecs" : 0,
   "RaceLaps" : 1,
   "TrackName" : "Silverstone",     /* new */
   "TrackLayout" : "International",  /* new */
   "Cars" :
   [
     {
       "CarId" : 0,
       "Driver" :
       {
         "Name" : "asd",
         "Team" : "asd",
         "Guid" : "ks145"
       },
       "Model" : "bmw_m3_e92",
       "Skin" : "black_red",
       "BallastKG" : 10
     }
   ],
   "Result" :
   [
     {
       "DriverName" : "Lord Kunos",
       "DriverGuid" : "ks1",
       "CarId" : 5,
       "CarModel" : "tatuusfa1",
       "BestLap" : 58598,
       "TotalTime" : 58593,
       "BallastKG" : 0,
       "PositionClass" : 1,    /* maybe for future use, when capable to identify different car classes */
       "PositionGeneral" : 1,   /* new */
       "LapsCompleted" : 1  /* new */
     },
     {
       "DriverName" : "Driver1",
       "DriverGuid" : "ks2",
       "CarId" : 1,
       "CarModel" : "bmw_m3_e92",
       "BestLap" : 999999999,
       "TotalTime" : 0,
       "BallastKG" : 0,
       "PositionClass" : 2,
       "PositionGeneral" : 2,
       "LapsCompleted" : 0
     }
   ],
   "Laps" :
   [
     {
       "DriverName" : "Lord Kunos",
       "DriverGuid" : "ks1",
       "CarId" : 5,
       "CarModel" : "tatuusfa1",
       "Timestamp" : 88602,
       "LapTime" : 58598,
       "Sectors" : [30668,   27930],
       "Cuts" : 0,
       "BallastKG" : 0,
       "LapNumber" : 1,  /* new */
       "InvalidLap" : false  /* if different from Cuts field, like 4 wheels out, but no cut */
     }
   ],
   "Events" :
   [
     {
       "Type" : "COLLISION_WITH_ENV",
       "CarId" : 5,
       "Driver" :
       {
         "Name" : "Lord Kunos",
         "Team" : "boh",
         "Guid" : "ks1"
       },
       "OtherCarId" : -1,
       "OtherDriver" :
       {
         "Name" : "",
         "Team" : "",
         "Guid" : ""
       },
       "ImpactSpeed" : 28.204433,
       "WorldPosition" :
       {
         "X" : 104.59276,
         "Y" : 191.02394,
         "Z" : 67.71219
       },
       "RelPosition" :
       {
         "X" : 0.87020576,
         "Y" : 0.08854308,
         "Z" : 1.7496352
       },
       "LapNumber" : 1  /* reference to when the event happen */
     },
     {
       "Type" : "COLLISION_WITH_ENV",
       "CarId" : 5,
       "Driver" :
       {
         "Name" : "Lord Kunos",
         "Team" : "boh",
         "Guid" : "ks1"
       },
       "OtherCarId" : -1,
       "OtherDriver" :
       {
         "Name" : "",
         "Team" : "",
         "Guid" : ""
       },
       "ImpactSpeed" : 37.87011,
       "WorldPosition" :
       {
         "X" : 158.783,
         "Y" : 188.2993,
         "Z" : 180.3633
       },
       "RelPosition" :
       {
         "X" : 0.8701962,
         "Y" : 0.08856083,
         "Z" : 1.7496443
       },
       "LapNumber" : 1
     }
   ]
}

 

Okee... but I don't think I can do much about the formatting because it's being formatted by the Go standard library functions.. I'll have a look if they contain some formatting option.

 

Oh, no no. I just formatted it for making it easier to read on the forum. It does not matter if the generated result file is formatted or not. Sorry if that was understood.

 

ah ok... well I found the function to do it anyway.. so it's going to be pretty now

 

Thanks for detailed explanation. I'm not sure about your latency argument for the client/server UDP packets. I mean, sending one UDP packet containing N cars should be always faster than sending N UDP packets containing one car, or do I miss something? (however, this is not really our topic here ....)

For stracker I also thought about having at least 10 Hz realtime report - with this I'd be able to generate graphs like this (http://77.108.135.2:42223/lapdetails?lapid=31136#) independently from ptracker usage. I'd also be able to add server-sided soft-split support, which would be a neat thing Last but not least: When the numberOfTyres out will be added to the realtime report, I'd also be able to generate server-sided validity information. (<excitement> All of this will result in a very cool enhancement of stracker server statistics independently from ptracker usage </excitement>)

I'm a little bit worried about the number of UDP packets when we also use the (planned) UDP redirector for enabling multiple server plugins which would easily create another factor of 3 or 4...

+1 I think Stefano has required incoming plugin connections to be at localhost only. We should do the same thing for the redirector.

 

All of this is blowing my tiny little mind. Its very good though.

I have one question.

@Lord Kunos

What is the update frequency for the netcode? Ive seen in other MP titles that upping the frequency or "tickrate" can vastly improve the quality of a player's experience, although you do get an increase in bandwidth use...?

I know some titles run at 100hz, I think Battlefield has recently moved from 20hz, to 40hz and now to 120hz with players reporting a massive improvement in the netcode responsiveness.

 

Awesome network theory porn going on here, I'm excited. When I see the results, I might even be aroused