Re: F1 23 UDP Specification

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? 

---

@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. 

@Hoobiechoobie 

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?

@Hoobiechoobie I have another question. Is is possible to set the CARID of all Online F1World Cars to 42 (or some other number), and that only the Players F1 World Car get CARID 41 ? It's easier to seperate it from the data then.

And can you please add a interval for DRIVERAHEAD and DRIVERBEHIND ? 

So, when can we expect UDP data update with new IDs and stuff?

<Id143 CarName="ART Grand Prix 2023"/>
<Id144 CarName="Campos Racing 2023"/>
<Id145 CarName="Rodin Carlin 2023"/>
<Id146 CarName="PHM Racing 2023"/>
<Id147 CarName="DAMS 2023"/>
<Id148 CarName="Hitech Grand Prix 2023"/>
<Id149 CarName="MP Motorsport 2023"/>
<Id150 CarName="PREMA Racing 2023"/>
<Id151 CarName="Trident 2023"/>
<Id152 CarName="Van Amersfoort Racing 2023"/>
<Id153 CarName="Virtuosi 2023"/>

These are the new CarIDs

Sorry, no.
I do not need them.

You get the DriverIDs in your programm / app?
Then simply chose a 2023 F2 race and look at them in your telemetry output.

F2 2023 Driver IDs

145 Zane Maloney

146 Victor Martins

147 Oliver Bearman

148 Jak Crawford

149 Isack Hadjar

150 Arthur Leclerc

151 Brad Benavides

152 Roman Stanek

153 Kush Maini

---

@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?

@Hoobiechoobie How can I get the live delta time? I mean not the delta between cars, i want the delta between my best time?

Also do you share the percentages and colors for wear, temps change? (blue, green, yellow.. etc) 

thanks

Regarding delta times, I record times depending on the cars position on the circuit. I use percentage. e.g. 5% lap completed m_lapDistance vs m_totalDistance in lap data, was done in x seconds last / best lap vs the same the current lap. I round the percentages so it's not perfect, but it's close enough.

I do the same for x car ahead / behind as it was built pre the m_deltaToCarInFrontInMS but it's easier to look at any opponent on the track.

---

@RJ80F1  ha escrito:

Regarding delta times, I record times depending on the cars position on the circuit. I use percentage. e.g. 5% lap completed m_lapDistance vs m_totalDistance in lap data, was done in x seconds last / best lap vs the same the current lap. I round the percentages so it's not perfect, but it's close enough.

I do the same for x car ahead / behind as it was built pre the m_deltaToCarInFrontInMS but it's easier to look at any opponent on the track.

---

oh man... how did it not occur to me... it's very easy like that hahaha

And I was going to divide the tracklength into x parts and store it.
hahaha.

Thank you very much, I'll try it this way and see if it doesn't bother me too much. Sometimes the solution is right under your nose...

edit: totalDistance from lapdata gives that info? or you mean tracklength? as far as i know, totaldistance if you finish 3 laps, will be 3*tracklength or im wrong?

Yep you're completely right. I meant using m_trackLength from PacketSessionData. :-)
Doing it this way also means you can expand it and break the track into your own sectors and see where you are slower.
e.g. from 0% to 20% took you x time, compared to someone else.

Sometimes the possibilities are too much with so much data. Haha.


No worries. I'm sure a lot of the stuff I do is going round the houses quite a bit when there is a much simpler way that I haven't twigged.

yes, but maybe @Hoobiechoobie could add or tell to add something like LapDataEx packet that contains an array of 22 cars, with some minisectors (IRL there are 20-30) with time and distance so we could made that comparison easy.

Then we only need to store those (it could be better it we had a field in PacketSessionHistoryData with an array of 100 laps with player 1 and 2 minisector history (time and distance) 

And if we could get the percentage in which damage, or temperature data changes (from green to yellow, and so on) it would be fantastic.

Well, I created a plugin for SImhub, that gives these color outputs. I also made dashboards, and Leaderboards that use my Plugin and these values. Just look for RaycerRay on RaceDepartment.