About that maybe-server-api

Hi guys,
together with a friend(@Gareth ← ) I created a Node.js implementation of the server protocol. It does everything the example application does, plus it also throws a custom event when a player is done loading and is connected. The documentation is not great at the moment (no one likes writing documentation), however if you have worked with Node before it should be pretty self explanatory.
You can find it at: https://github.com/flamescape/acsp

If you find any issues please post them on the GitHub page.

 

As soon as we get a New_Connection message, We start pinging the server with GET_CAR_INFO requests. In the response there is a "is_connected" value that will be set to true when the player is done loading. So when we get a response where that value is true, the event is emitted.

 

wish:
set starting grid via plugin

in more detail:
At the time of a new race session, assign every driver connected to the server a specific grid position, or starting from their pit, or not allowed to start.
Grid position - idk which is more like the current grid, put driver GUID into an array of grid positions, or put grid position into an array of drivers. Either way, it should allow for gaps in the grid, for most flexibility to add latecomers.
Starting from the pit - for people who didn't qualify, or whatever.
Not allowed to start - for spectators, or people who DQed. Lets them see the race, and be present if participation is counted, but not race.

On the note of latecomers, if someone connects, it should be able to react to that by adding them to the grid, if the time window is still open.
The automatic grid should be provided to the plugin in the same format ideally, both as an example and as useful info for the plugin.
My feeling is it should also be able to override the automatic 20 second window in which you get sent back to the pits if you're not 'ready' but idk if that's part of the same request or not.

 

Yeah I thought of that after some contemplation. We currently have the automatic "if you don't ready-up in time, you go to the pits", plugins should probably modify that aspect if they want to control things that happen between session-start and green light, and leave 'custom grid' as "have an array of positions at the start of the session", so absentees are in that array by default, but get moved to pits with the other option if they're too late.

To stop it blocking I guess it should be sent to the server in the last 30 seconds of the previous session or in the preamble between 'server started' and 'session available to join', not sure how many leagues launch race-only servers right now but they'll probably complain if they can't use the feature.

 

nice idea, implemented this in my ReportPlugin

 

Hi,

just saw interesting thread

Maybe one more message that the ADMIN SERVER will be able to set before to run the server:

"Please follow our basic rules on the track"
"welcome on our server-visit our site www....."

etc...

 

I wish Stefano would use the forums to communicate...

 

On another wishy note,
Let plugin start & see the results of votes. Would be useful for eg. doing something extra to users that are votekicked, or being able to add new sorts of session-skipping votes (do a second race with reverse grid instead of Q, skip to next track, give Niki a 200kg ballast next race, whatever)

 

First thing which comes in my mind when I hear votes:
If Kunos adds the ability to kick, you guys really have to give us (server admins) an automatic vote-spammer kick

 

Guys,

My plan is to do some work on Monday/Tuesday (that would be tomorrow) on the server UDP plugin but I need some sort of list to go through in order to do so.

It would be nice if people working on plugins (please do not feel like you need to participate to the discussion if you are not ) to post what they would like to be added/changed and why and how. Feel free to open a new thread if necessary and link it from here so I can follow. Let's start with a simple list without getting into debates about what is good and what is bad and why, let's keep it clean if possible... each user, 1 post.. several requests, don't turn it into a fight.

The other big point that requires a decision is how we handle the protocol version. My initial proposal would be to have a message ACSP_PROTOCOL_VERSION send as request and answered by the server with the version number. If a plugin discovers it is talking to a server with a different protocol it just stops there.
I am open to different ideas that do not involve too much work, let's remain pragmatic.

 

Thank you very much! I have made a thread with my wishlist here: https://www.assettocorsa.net/forum/index.php?threads/server-plugins-neyss-wishlist-thread.25797/.

 

Thank your very much for working on this, and especially for coming to the forum on a sunday

@never_eat_yellow_snow1 do you know if the total time (that you are talking of, from the ENTRY html page) is correct for drivers that connected after the race has begun? Is it counted from the race start or from their connection time?

If "total time" it's not reliable, I'd like to have a "server timestamp" in the "lap completed" event.
and I'd rather have the "tyre info" in "lap completed" than in every "car update", but if it's in "car update" (like neys suggested) then that's fine too.

 

I'm 99% sure that the entry list's total time information is reliable. I use it in stracker and calculate the stracker classification with this and there hasn't been any issues with this recently.

Regarding tyre info: Thanks for suggestion, I'm going to change the thread

 

@Lord Kunos is the receiver on the server side of the UDP messages thread safe? I have the feeling that if I request several broadcasts in short order, the server mixes up the messages, in some cases repeats the second message instead of broadcasting first and second message. Has someone else seen this?
If that's the case the plugin writers should probably have a short delay between request messages so they don't mix on the receiver side. I'll try if that fixes the problem and report back.

 

Yep, reproducible and yep, solvable with a delay between the requests.
@Minolin I added a send message queue to the DuplexUDPClient that waits at least 20ms before sending the next message. 20ms seemed enough in some tests, if we still have issues we might increase the value as needed.

 

how many request messages do you plan to send per second?

It is easily reproducible, just loop a broadcast request message with 30+ characters with an index in front, you will see some messages are skipped and some repeated. A 10ms delay did already solve this in my tests, but I wanted to be on the safe side...