About that maybe-server-api

A step backwards: How does the track data look like, is it binary/compressed? Could we easily read/parse such stuff? (the server currently doesn't have track data, just the checksums)

 

I've played around a bit to understand how the messaging really looks like and how it could work, which ended in a good part of creating the fake server. Then I realized that this one might in fact be useful for testing purposes (redirector, but also plugin developers and maybe even the Lord himself*) and I improved the GUI a bit more.
Currently I stopped after two outgoing messages (after all this could look really different after 1.2 release) and need to implement the way back so we can read 1 or 2 messages from the plugin. But the overall concept and gui shouldn't change that much, I'm quite satisfied so far.

Maybe you're already interested to see and use it for tests or debugging. The attached solution contains Stefano's acRemoteServerUDP_Example (which is a usual plugin) next to my acServerFake (Which is a simple GUI program). The project are setup in a way they both start on debug (F5 or newcomers), but they are completly independant executables.

The plugin is currently just listening, but you'll see the output when a message is sent (and what values are understood). The fake-server looks like this:


Simply click a Event-Type and press "send" to get the data over the wire. In the example you can see (logviewer below) that I first tried to send without opening the UDP channel, then sent a new-session-event and a collision-event.
Every sent event logs a human readable string representation and the binary stream that is to be sent (for comparison).

The plugin did receive both messages like this:


So you can see the acServerFake can at least send UDP-data in a way the plugin can understand (which is not necessarily equal to what the server would sent, though).

--------------

My observations so far:

1. we have to take care of the string handling; ASCII+UTF-32 are mixed up. I think it's absolutely correct this way, as this is just a shadow copy of the data broadcasted between client & server. Chat + driver names need to be unicode; all the other stuff doesn't and will be 4 times smaller this way. We just have to take care of this; in the best case it's hidden inside the one language dependant framework (you really don't want to do and update the deserialization in every single plugin)
2. I have no idea who will start communication and how the server generally handles this. UDP is tricky, maybe it's possible that we can talk about a super-simple, 1 byte PING-PINGBACK event that both ends can send whenever they want?
3. Overall this looks really good. Exciting and enjoyable so far.

 

We know what is processed in the sample, so probably yes. At least more or less.
I'll write a little summary once I've finished the other way round. But I can say it really looks nice so far.

 

Yep & yep

 

When the next session starts, your plugin's NewSession() event is raised. You can guid as much as you want.
Not sure for the first one, but I could imagine that you'll get the newsession at once

 

uh, 30 clients with 100Hz is quite a thing - and you have to keep in mind that we're cpu-taxing the same machine that runs N "real" acservers.
But tbh. I didn't even think about UDP fail safety. First it's really unlikely on the same machine. Then we maybe could detect a missing msg, but what then? Create a "please resend X" logic on both sides? Na, don't think so.

-------

Promised a little overview. Please keep in mind that I don't have more than the sample-project, and that nobody said this actually works. So there may be some fantasy or notyetimplemented stuff we don't receive with 1.2

Server->plugin messages

New Session (example: Qualifying ended, race is a new session now)

Parameters:
- string name (no idea, maybe the server's name?)
- byte type (probably the same numeric type like in the config.ini)
- unsigned short time of day (probably in minutes)
- unsigned short laps (lapcount, if race)
- unsigned short waittime (time before the green light, maybe also Qualifying "stay-in-pits" time)
- byte ambient temperature
- byte road temperature
- string weather


Collisions (2 subtypes: collision with environment / other car)
- byte car_id (probably the same we know from the python API)
- optional: byte other_car_id (when subtype == collision-with-car)
- float speed (relative speed between both cars / environment)
- vector3xfloat world position (same as in python)
- vector3xfloat relative position (local position vector, maybe car_id-center vs. point of impact)


Car info (may be requested by ACSP_GET_CAR_INFO)
- byte car_id (again python api)
- bool isConnectd (= is a player sitting in there?)
- Unicode model (car model)
- Unicode skin (car skin)
- Unicode driver name
- Unicode driver team
- Unicode guid (hopefully SteamId64)

Car update (can be requested per car_id + interval)
- byte car_id (again python api)
- vector3xfloat world position
- vector3xfloat velocity
- byte gear
- unsigned short engine_rpm

New connection (new driver is connecting)
- Unicode driver name
- Unicode guid (hopefully SteamId64)
- byte car_id (again python api)
- Unicode model (car model)
- Unicode skin (car skin)

Connection closed (driver disconnected)
- Unicode driver name
- Unicode guid (hopefully SteamId64)
- byte car_id (again python api)
- Unicode model (car model)
- Unicode skin (car skin)

Lap completed
- byte car_id
- unsigned int laptime (miliseconds?)
- byte cuts (probably how many tyres off track dependant on the config.ini setting)
- included: complete, current leaderboard (byte car_id / uint best time / byte laps driven)
- float grip level


Plugin->server messages
Get car info (probably returns the car info once)
- byte car_id

Enable realtime report (server will send "car update" every x ms)
- byte car_id
- unsigned short interval (in miliseconds)

---------

Those are C# datatypes, I hope you can translate them into whatever you program in.
byte = 8bit Integer
short = 16bit Integer
float = 32bit decimal
vector3xfloat = simple struct, you can also read three floats (x,y,z where y = height) in a row
string = ASCII
Unicode=UTF-32

--------

The messages come in binary; the first byte always identifies the message type. Strings and unicode fields just have a byte that defines the length; then the text.

--------

You can see this is getting somewhere. Pretty sensible events, only the newsession lacks a "end-of-race"-event. But this is made up by a wonderful "lap completed" one, including leaderboard and cuts (!).
I hope this can help you efficiently.

 

Yes please, incredible useful and efficient. But I'm afraid this won't happen with 1.2 release, because the SplinePos isn't part of the netcode (but is calculated on the client based on the world position and known track).
Stefano indicated that this could happen, but of course it's not just adding something the server already knows into the UDP stuff.

I still think it's worth it, almost every python app where I've browsed the code had used the SplinePos.

Offtrack would be very nice, yes. There will be two kinds of alternative cutting systems: new ways in detection (like cutters), but I think the ones who will shine just generate alternative consequences (like PLP). The latter can and should use the Kunos detection system. But I'm almost sure the server doesn't know about tyres out, again. I think the Lord already gave us everything the server broadcasts into that car update event. So everything we want additionally has to be uploaded by the client and sent over network.