Server plugins: neys's wishlist thread

So here is my wishlist thread for stracker:

New information I wish was included to the API:

• [new] message when a car enters or leaves pitlane
• [new] Message when a car enters or leaves pits.
• [CarInfo] Add the assists used by the player to the CarInfo object (i.e. AutoClutch, AutoBrake, AutoGear, AutoThrottleBlib, RacingLine)
• [NewSession] Add track name / track layout
• [LapCompleted] Add TotalTime (same as in the ENTRY html page) of the driver (not necessarily to the leaderboard)
• [LapCompleted] Information about which tyre a car uses in the lap completed messages (maybe with just an enum for the new (S), (SS), etc. codings)
• [CarUpdate] Add the number of tyres out to the realtime messages
• [CarUpdate] Add CurrentTime to the realtime objects, if possible (equivalent to what we get in the clien's shared memory interface acpmf_graphics.currentTime)
• [CarUpdate] Add ABS and TC levels to the realtime object

Changes of the current messages:

• Change number of bits from 8 to 16 for the Laps member of the leaderboard (because the limit of 255 might easily be reached in endurance races)

New interaction possibilities:

• Possibility to kick a player
  
• Possibility to ban a player
• Possibility to send a player to pits
• Add a requestable SessionInfo object equivalent to NewSession object (but requestable by the plugin)
• Add the possibility to set the number of laps or session time for next session
• Add the possibility to set the type of the next session (practice, qualify, race)
• Grid manipulation for the next session

Version information:
I'm fine with your proposal for a requestable version message.
Many thanks for your cooperation, Stefano! This is really highly appreciated.

Forum:
It would be nice to get a forum section to discuss this stuff

 

Good thread for posting plugin requirements, thanks @never_eat_yellow_snow1 for the thread. Hope you do not feel we are hijacking it.

ACSProtocol.ACSP_NEW_SESSION
- Include track name and track configuration, just like the session result JSON file generated by acServer. I am currently complementing what my plugin generates with this JSON file, but will be hand to include it on this event.

ACSProtocol.ACSP_END_SESSION
- Sometimes, I cannot read (always using readonly mode) the acServer generated session result JSON file. It seems the file is still being written by the time this event it called. I set a 2 seconds delay before attempting to read the file. Not big deal but something you may need to know. May be a timing issue.

ACSProtocol.ACSP_CLIENT_EVENT
- For every contact between two cars I am always getting two events, with the same cars and with the different speed for each car, which is fine. What I would like to have is include some kind of server timer "tick" or someway to identify at what time on the race the contact happen. In this way we can identify if both events represents the same contact in order not to register two contacts for both drivers. Even if the tick is different, we could apply some threshold to know if both events represents the same contact.
- Include the lap number and splinepos when the event happen

ACSProtocol.ACSP_LAP_COMPLETED
- Include the number of laps on the header information (after the laptime or cuts). I know the info comes also on the leaderboard, but it will be easier to access.
- If possible include the sector times (as an array, seems to be very popular on some sites that shows stats)
- As already mentioned, change the number of laps of the leaderboard collection from Byte to UInt32 to support long number of lap races.
- Include the tyre type used, both on the header (after the laptime or cuts) and on the leaderboard for each driver
- Not sure if welcome, as already being included the grip level, include the ambient temp and road temp, if they change going through the race, which I am not sure it happens.
- Include fuel level in liters

[NEW] ACSProtocol.ACSP_PIT_ENTRY (for proper count of pitstops)
- Include, carId, guidDriver, lapNumber, server time or tick (to calculate pitstop time, optional)

[NEW] ACSProtocol.ACSP_PIT_EXIT (for proper count of pitstops)
- Include, carId, guidDriver, lapNumber, server time or tick (to calculate pitstop time, optional)

[NEW] ACSProtocol.ACSP_CLIENT_OFF_TRACK (handly for generate driver rating)
- This is similar to CLIENT_EVENT, but used to identify the off tracks
- carId, guidDriver, lapNumber, number of tyres of track, splinepos (helpful somehow to measure the distance between off tracks for rating)

[NEW] ACSProtocol.ACSP_CLIENT_LOST_CONTROL (handly for generate driver rating)
- This is similar to CLIENT_EVENT, but used to identify lost of control (probably just a 180 spin)
- carId, guidDriver, lapNumber, angle delta from track direction?, splinepos (helpful somehow to measure the distance between off tracks for rating)

I know some of this information could be set on the ACSP_CAR_INFO event, but I would prefer to have them already included on the mentioned events, as using ACSP_CAR_INFO can be hard when trying to sync the data from the source event with the requested ACSP_CAR_INFO at many times.

Interactions to the server

Apply a blackflag, a stop & go pit penalty or a drive through to any driver.

@Lord Kunos thank you so much for listening to us. Hope this feedback would be useful for you. Any questions or comments please let us know. Can reach me also on twitter if for any hurry.

 

THX guys.. I will update this POST with the changes I am doing in real time. The plan is to release 1.2.3 later today which will include all the changes to the UDP protocol up to that point. Then we'll have a server only release tomorrow with the changes I'll manage to put in tomorrow as well. So get ready for some refactoring

UDP Plugin changelog:

- Added ACSP_VERSION both as command and as incoming message.
The server fires one up at startup (assuming the plugin is already there), you can also later re request the protocol version with an ACSP_VERSION command. However, I've also added the protocol version number to the ACSP_NEW_SESSION message because that used to be the entry point for the plugin.

- ACSP_NEW_SESSION has now a brother ACSP_SESSION_INFO
ACSP_SESSION_IFNO is more generic because it can be requested by a couple of commands and also return information about the next session.
This is how it is deserialized now:

var version = br.ReadByte(); // UDP Plugin protocol version, in case you miss the first ACSP_VERSION message sent by the server at startup
var sess_index = br.ReadByte(); // The index of the session in the message
var current_session_index = br.ReadByte(); // The index of the current session in the server
var session_count = br.ReadByte(); // The number of sessions in the server
var server_name = readStringW(br);
var track = readString(br);
var track_config = readString(br);
var name = readString(br);
var type = br.ReadByte();
var time = br.ReadUInt16();
var laps = br.ReadUInt16();
var waitTime = br.ReadUInt16();
var ambient_temp = br.ReadByte();
var road_temp = br.ReadByte();
var weather_graphics = readString(br);
var elapsedMS = br.ReadInt32(); // Milliseconds from the start (this might be negative for races with WaitTime)

- New ACSP_CHAT message
Called every time a chat message is received by the server. Useful to interact with the plugins.

- New ACSP_CLIENT_LOADED message
Fired by the server when the first position update arrives from a client, which means, it's done loading

- New ACSP_GET_SESSION_INFO command
Use this to request a session info packet to be sent by the server

- New ACSP_SET_SESSION_INFO command
To change name, laps, time, wait time of a session. In theory this can change also the current session, but the client is not aware of that at the moment. This will open the door to have time limited races, although the support would be much more clearly implemented natively in AC and I have plans to do that.
I might decide to have the server refusing to change the current session info

- New ACSP_ERROR message
The server will use this sending a stringW with the description of the problem. Used for stuff like out of bound indices and so on.

- New ACSP_KICK_USER command
It does what it says on the tin

 

Today I am working on all the feature that don't involve the client and the client/server protocol because I don't want to touch it before releasing 1.2.3 . I'll get into the fun stuff tomorrow.

 

Yes you guessed right, ACSP_GET_SESSION_INFO gets a byte with the session index you want to get or a -1 for the current session

I think you can treat a SESSION_INFO as a NEW_SESSION every time the index==current_index, in other words, if that is the current session, also the elapsedMS will be <=0 or very very small.

Nevermind, it was better.. I restored ACSP_NEW_SESSION, same format as SESSION_INFO but only sent when a new session starts.

 

Well spotted that -1 byte.. changed to a 16 bit integer.

 

The grid manipulation is tricky because it needs a blocking system from the plugin.. when a session is finished the server calls the plugin and the plugin needs to answer... or a couple of seconds to be added to the qual time.
Do I understand correctly what you need.. end session.. the plugin sends me a list with the grid. the server obeys.

It could also happen at any time, the plugin might send a new grid after every lap completed... but as I've said, need a couple of seconds at the end of a qualify session to wait for the plugin to process the last lap completed.

Perhaps somebody can write down a possible scenario of what they want to do with grids?

 

My plugin is not planned to manage grids, but from what you explain, from my point of view, the best scenario would be to have an event where you expect the grid that will be applied in return, or null for no changes on the grid.

Again, probably a best description of the scenario will be from those interested in manipulate the grid.

 

Giving the plugin a few seconds after the qualify to change the grid sounds like a good idea. However, I also see the use case where the plugin sets a grid and then just restarts the session - wait I just went through my list and this was missing:

[new] possibility for the plugin to move to the next session (and also define the next session as Minolin already suggested) equivalent to the /next_session admin command.

This is evolving nicely I'm excited!

 

All this mp attention...did I die and go to heaven?


Good vibes!

 

In ACSP_SESSION_INFO, could there also be a value maxclients?

It seems that most of the new information is the same as what is available in the /INFO on the server. So could maxclients also be included in the session_info? Then I don't have to request the /INFO in my application anymore

 

that is a constant during the execution easy to get from server_cfg.ini . But you would say that also other infos are constants (ie. track/config) and were included.. and you would be right.

 

Ya I agree that admin should be accessed via chat, that way any new addition is automatically exposed to the plugins.