[DISCUSSION] F1® 25 UDP SPECIFICATION

Hi TMillo​, from what I understand from the UDP spec doc, the game packs everything including the tyre temp fields into C style arrays, and their array indices have been documented clearly in page 19

All wheel arrays are in the following order:
0 – Rear Left (RL)
1 – Rear Right (RR)
2 – Front Left (FL)
3 – Front Right (FR)

If you have written the parsers by hand, then please share the parser code for CarTelemetryData struct.

I'm unable to figure out which framework/language this code snippet uses and how exactly the object is parsed from raw bytes

GameRawData.PlayerCarTelemetryData.m_tyresInnerTemperature02

If you are using some library or building for some existing platform, you might get better mileage by posting in their forums

For front and rear ride height - what is the scale for these two? Thanks

The m_frontAeroHeight and m_rearAeroHeight is in mm, and represents the height of the plank from the ground. I verified this in MoTeC I2 Pro with data I collected from F1 24 when these values were added last year. Hope that helps!

Hello,

The m_penalties data in the Lap Data packet still only accounts for 2 and 3 seconds penalties. 5 and 10 seconds penalties are not added to the total in the data, so if a driver has a 3sec and a 10sec penalty in a race, the m_penalties will be 3 instead of 13.

It looks to me like there are no other packets that contains the 10sec penalty data, other than having to parse a penalty event and adding it manually (/by code) to the focused driver. Could you confirms it's a known issue or if I'm missing something here EA_Groguet​ ?

Thanks in advance !

I wouldn't say it's an issue. There's a difference with these penalties, the first group of 2 and 3 second penalties can't be served in a pitstop, while the 5 and 10 second penalties can. It makes more sense to keep these 'serveable' penalties as events.

Hi folks, in the participants packet, m_numActiveCars description is 

Number of active cars in the data – should match number of cars on HUD

When I was testing out in my team mode, I observed that this is matching the number of cars that have not DNF'd. 2 cars DNF'd in my race and m_numActiveCars was reported as 20 (when 22 was expected, since even DNF'd cars are present on the HUD).

Am I misunderstanding this, or is this a bug and is 22 the correct and expected value in the above situation?

Would like to know this too. EA_Groguet​ can you update us on this?

It seems like the UDP for time trial rivals has stopped working properly. Looking in the participants packet, the only names different are Default Ghost, Personal Best and mine. The corresponding participant from the time trial rival index is my username, and not my current rivals.

I too am experiencing the same. Also setups for rivals are not showing up. Not sure if thats a bug or a feature, given that the rival's setup is not a secret. One can directly load this setup from the menus and read every parameter.

Is it me or is the final classification packet not working right half the time? Sometimes I'm able to receive this packet in the final screen, sometimes it doesn't send at all, or extremely late (1+ minute, that I've noticed). This is causing me a lot of problems in handling the end of a session. I wonder if it might be because I used the fast forwarding option in a quali session to get to the final screen faster.

Another weird bug I've found is when a qualification session is restarted in the final screen, is that once the new session restarts, m_carPosition of the LapData packet will be the same for all drivers except the player. It gave me a little bit of trouble in my telemetry app, since I was using that as a backup to m_gridPosition in the LapData packet. It's a bit odd that m_carPosition has a meaningful value when the session is first started, but upon restarts it's entirely useless.


EDIT: Remembered another thing - m_frameIdentifier in the header is also always 0 for the Final Classification packet, it seems. I'm fairly sure that's a design choice, but I think using UINT32_MAX would've made more sense, as this is the "end-all-be-all" packet for the end of a game session. It's not the end of the world, though.