Codemasters Team@Hoobiechoobiedo you reckon we could have more event-based telemetry data in the future? Things like sector times, lap times etc... feel like they should be events emitted when they happen, rather than a constant flow of live telemetry data, like speed, throttle etc... Trying to capture last sector times, or last lap times means we have to write adapters that turn these packets into events, which is sub-optimal.
Codemasters Team
@p403n1x87 wrote:
@Hoobiechoobiedo you reckon we could have more event-based telemetry data in the future? Things like sector times, lap times etc... feel like they should be events emitted when they happen, rather than a constant flow of live telemetry data, like speed, throttle etc... Trying to capture last sector times, or last lap times means we have to write adapters that turn these packets into events, which is sub-optimal.
The current implementation has arisen via different requests over the years, so it would be good to know if there is a preference from the community about which route to go down for this type of data in future. Both appraches have pros and cons, so would be good to hear what you all want from this.
Well, alot of applications, like I Simhub work with packadges, and don;t have support for Event like. Bug problem with the event types are that when you start the data later in the session, and you missed some data, you don;t get it anymore. So how it now works with the UDP packadges is great.
And would be great to get more data out of it at this way. I understand the question of @p403n1x87 . The Sector 3 data (you only have a currentsector1 and currentsector2) is realy hard to capture. In gamesessions like de OneShotQuali, at the end of the session, alot of the data is gone. Sector3 data is hard to capture then.
@Hoobiechoobie I notecied a bug in the UDP data in the One Shot Quali. The Damage packadges of the Sidepod, Diffuser, Rearwing and floor is 100% for all players except the PLAYER itsself, and Player Position 10. Front wing left and right is correct for everyone. Can you look into this?
Codemasters Team
@Raymond-Smits wrote:
@Hoobiechoobie I notecied a bug in the UDP data in the One Shot Quali. The Damage packadges of the Sidepod, Diffuser, Rearwing and floor is 100% for all players except the PLAYER itsself, and Player Position 10. Front wing left and right is correct for everyone. Can you look into this?
We can't see this issue here. Do you have any more info about which game mode you are using and what damage setting the session is using? Thanks.
Sorry, offcourse. It happens in a Multiplayer session in the One Shot Quali (Doesn't matter if we use a 3 laps, 5 laps, 25%, 35%, 50% or 100% race). Damage setting is set on realistic.
And I happens only in a created multiplayer session. All other sessions (single player) work.
I think the current system is good. At least all the games I support with my Tool use similar system, so it seems to be the standard way of doing things.
I think key issue is the UDP connectivity, which can be unreliable, so if the data would be 'Events based', then if you miss one of those packets, your data would be out of sync. And also you would need to keep track of the events, if you are doing something more advanced with e.g. the race data.
As was already said, now we get to have up-to-date data of the game state, which nicely reduced the need to keep track of this data in the Tool. And that is what I like.
There could be more events sent by the game, but I think the current system is quite good.
Cheers.
I might be missing something but I'm misunderstanding what SessionID in the headers are for. Here's why:
I have a go package, written using this implementation (yeah, it's still using the 2022 spec, I plan on creating a PR to add 2023 to it soon).
When I get all my packets during a session, the SessionID matches. But as soon as I get a Session Classification packet, the SessionID is different. I would expect the SessionID to be the same, from the moment a session (practice, qualifying, race) starts all the way through until it ends. Is this the correct assumption? Or am I misunderstanding SessionID's completely?
If that's not what sessionID's are for, how would you suggest I tie up Participants to Results? Is there any way to do this?
@Bird87ZA wrote:I might be missing something but I'm misunderstanding what SessionID in the headers are for. Here's why:
I have a go package, written using this implementation (yeah, it's still using the 2022 spec, I plan on creating a PR to add 2023 to it soon).
When I get all my packets during a session, the SessionID matches. But as soon as I get a Session Classification packet, the SessionID is different. I would expect the SessionID to be the same, from the moment a session (practice, qualifying, race) starts all the way through until it ends. Is this the correct assumption? Or am I misunderstanding SessionID's completely?
If that's not what sessionID's are for, how would you suggest I tie up Participants to Results? Is there any way to do this?
@Hoobiechoobie could you perhaps help here?
