Jump to content Jump to content

F1 2018 UDP Specification


Hoo

Recommended Posts

@Lopensky why did you mark the message as off topic? It is useful to know so I can highlight the tyre temperatures, blue, green or red in my app.
Nope. I think this is a question that should have its own topic, just this. It is not strictly related to UDP data ;)

Anyway, i just want to be sure @Hoo reads THE solution proposed by @IJS84 . B

Link to post
Share on other sites
What are the optimal inner and surface temperatures of each compound?
Asked a similar question last year. Wanted to know at which rpm_percentage the Leds light up in each car. Never got an answer. 
So I think you have to go the hard route, as I did last year. Drive, look at the colours, notice the numbers and implement.
Link to post
Share on other sites
What are the optimal inner and surface temperatures of each compound?
Asked a similar question last year. Wanted to know at which rpm_percentage the Leds light up in each car. Never got an answer. 
So I think you have to go the hard route, as I did last year. Drive, look at the colours, notice the numbers and implement.
Suppose in this case, if the car had x number of lights, say 15. You would then do 100/15 = 6.6666%. This means that in light one turns on when rpm_percentage is >=6.6666. Light two would then turn on when rpm_percentage is >= 13.333% etc. This way, if you know how many led lights are on the car, you know what percentage it is. 
Link to post
Share on other sites
What are the optimal inner and surface temperatures of each compound?
Asked a similar question last year. Wanted to know at which rpm_percentage the Leds light up in each car. Never got an answer. 
So I think you have to go the hard route, as I did last year. Drive, look at the colours, notice the numbers and implement.
Suppose in this case, if the car had x number of lights, say 15. You would then do 100/15 = 6.6666%. This means that in light one turns on when rpm_percentage is >=6.6666. Light two would then turn on when rpm_percentage is >= 13.333% etc. This way, if you know how many led lights are on the car, you know what percentage it is. 
If it has been that easy ….
Now try that.
Then take a RedBull for a few laps and compare your dash LEDs with the ingame LEDs.
After that take a Ferrari for a few laps and do the comparison again.
Your Das LEDs will never match!

You can get the right rpm_percentage for each LED from last year here:
https://1drv.ms/x/s!AngnWwGMubK9oJ5gXrqLUzvjk1rEMg  
Link to post
Share on other sites
What are the optimal inner and surface temperatures of each compound?
Asked a similar question last year. Wanted to know at which rpm_percentage the Leds light up in each car. Never got an answer. 
So I think you have to go the hard route, as I did last year. Drive, look at the colours, notice the numbers and implement.
Suppose in this case, if the car had x number of lights, say 15. You would then do 100/15 = 6.6666%. This means that in light one turns on when rpm_percentage is >=6.6666. Light two would then turn on when rpm_percentage is >= 13.333% etc. This way, if you know how many led lights are on the car, you know what percentage it is. 
If it has been that easy ….
Now try that.
Then take a RedBull for a few laps and compare your dash LEDs with the ingame LEDs.
After that take a Ferrari for a few laps and do the comparison again.
Your Das LEDs will never match!

You can get the right rpm_percentage for each LED from last year here:
https://1drv.ms/x/s!AngnWwGMubK9oJ5gXrqLUzvjk1rEMg  
Didn't realise. Thanks for letting me know!
Link to post
Share on other sites
  • Codemasters Staff
There appears to be some issues with the timing data for Time Trial, it seems to contain data for a number of additional non-existant players. The m_numCars is 1, however there are multiple entries in the lap data record that appear to be active. They show as lap 1, position 1 and for all intensive purposes appear to be an active player (albeit with overlapping race positions). They even have valid x/y/z world co-ordinates.

At the moment I have had to work around it by doing a check for m_numCars = 1, in which case i know there is only the "player", so i can use the m_playerCarIndex to make sure i grab the right entry, as they all overlap each other in terms of their result (race position). 

This sounds like the ghost cars that you are racing against. The will include your personal best plus your next rival in the leaderboards in racing online. If so, then using the m_playerCarIndex value should give you the right values. You can turn off ghost cars in the Time Trial options menu if this is annoying you.
Link to post
Share on other sites
  • Codemasters Staff
Ho3n3r said:
@Hoo Ride height values (in mm) is an integral part of racing telemetry, yet it's not part of what is exposed via UDP. Why is that? Do these values not exist?
Hi. This information is contained in the CarSetupData packet: m_frontSuspensionHeight and m_rearSuspensionHeight.
Link to post
Share on other sites
Hoo said:
Ho3n3r said:
@Hoo Ride height values (in mm) is an integral part of racing telemetry, yet it's not part of what is exposed via UDP. Why is that? Do these values not exist?
Hi. This information is contained in the CarSetupData packet: m_frontSuspensionHeight and m_rearSuspensionHeight.

I think what he is meaning is the height difference between the floor of the car and the track. If not, it would be nice to have it. Also @Hoo, what are the optimal temperatures for each compound?
Link to post
Share on other sites
  • Codemasters Staff
Hoo said:
Ho3n3r said:
@Hoo Ride height values (in mm) is an integral part of racing telemetry, yet it's not part of what is exposed via UDP. Why is that? Do these values not exist?
Hi. This information is contained in the CarSetupData packet: m_frontSuspensionHeight and m_rearSuspensionHeight.

I think what he is meaning is the height difference between the floor of the car and the track. If not, it would be nice to have it. Also @Hoo, what are the optimal temperatures for each compound?
I guess with the wheel dimensions this should be possible? Unfortunately I don't have the tyre compound information to hand.
Link to post
Share on other sites
Hoo said:
Hoo said:
Ho3n3r said:
@Hoo Ride height values (in mm) is an integral part of racing telemetry, yet it's not part of what is exposed via UDP. Why is that? Do these values not exist?
Hi. This information is contained in the CarSetupData packet: m_frontSuspensionHeight and m_rearSuspensionHeight.

I think what he is meaning is the height difference between the floor of the car and the track. If not, it would be nice to have it. Also @Hoo, what are the optimal temperatures for each compound?
I guess with the wheel dimensions this should be possible? Unfortunately I don't have the tyre compound information to hand.
Probably. Where would be the best place to get the optimal temperature for the information?
Link to post
Share on other sites
What are the optimal inner and surface temperatures of each compound?
F1 2017 had a default tyre temperature for time trials. I guess that these values seem to be optimal? Maybe F1 2018 has something like that in TT, too?

Just checked myself. Tíme trials has 100 for both inner and surface temperature.
Link to post
Share on other sites
Hoo said:
There appears to be some issues with the timing data for Time Trial, it seems to contain data for a number of additional non-existant players. The m_numCars is 1, however there are multiple entries in the lap data record that appear to be active. They show as lap 1, position 1 and for all intensive purposes appear to be an active player (albeit with overlapping race positions). They even have valid x/y/z world co-ordinates.

At the moment I have had to work around it by doing a check for m_numCars = 1, in which case i know there is only the "player", so i can use the m_playerCarIndex to make sure i grab the right entry, as they all overlap each other in terms of their result (race position). 

This sounds like the ghost cars that you are racing against. The will include your personal best plus your next rival in the leaderboards in racing online. If so, then using the m_playerCarIndex value should give you the right values. You can turn off ghost cars in the Time Trial options menu if this is annoying you.
I can see the ghost cars in there but there are also additional cars after the ghost cars too (at least they seem to be different to the ghost cars in that they have an actual F1 2018 driver name, eg Sebastian Vettel). Should there be more 10+ ghost entries? I see about 3-4 that look like valid ghosts cars directly after the player then another additional 6 or so of random drivers.
Link to post
Share on other sites
have you checked for a null char at the start of these ghosts' names? Not sure if it's the same with F1 2018, but in pCars they seem to null out only the first char of the driver name when this driver is no longer part of the session, leaving the rest of his name as stale data
Link to post
Share on other sites
  • Codemasters Staff
@Hoo - what is the difference between m_tyresWear and m_tyresDamage in the Car Status packet? From what i can tell they always seem to have the exact same value. I thought that perhaps m_tyresDamage was related to the suspension or rim damage, however it just seems to be the same as the tyre wear percentage.
If the tyre is not detached/punctured/ burst then the damage is the same as the wear. However, if a wheel becomes punctured or burst then the damage goes to 100%. This is to keep it in line with what is displayed in the OSD panel.
Link to post
Share on other sites
Anybody who knows can explain me how the sessionUID works so i don't need to do hours of testing?!? :)
Is it unique for the whole race event or it changes session by session (ie Q has one, Race has another)? :|

Similar question related to the field m_resultStatus of LapData packet. If someone crash out this field become 6? And the game continues sending this value till the end of the race? :)

Link to post
Share on other sites
Lopensky said:
Anybody who knows can explain me how the sessionUID works so i don't need to do hours of testing?!? :)
Is it unique for the whole race event or it changes session by session (ie Q has one, Race has another)? :| 
This one seems to be weird. I am currently working on a telemetry recorder and I am using the sessionUid to identify the sessions.
Since I didn't really drove, I totaled the car. Did a flashback and thats when the sessionUid changed. So I don't think it is bound to any kind of "session" as in "F1 session".

Gonna do some more testing (it is just driving, the recorder will handle the rest)



Here you go.. I only did some driving and then totaled the car every "session".
Link to post
Share on other sites
Hoo said:
Hoo said:
Ho3n3r said:
@Hoo Ride height values (in mm) is an integral part of racing telemetry, yet it's not part of what is exposed via UDP. Why is that? Do these values not exist?
Hi. This information is contained in the CarSetupData packet: m_frontSuspensionHeight and m_rearSuspensionHeight.

I think what he is meaning is the height difference between the floor of the car and the track. If not, it would be nice to have it. Also @Hoo, what are the optimal temperatures for each compound?
I guess with the wheel dimensions this should be possible? Unfortunately I don't have the tyre compound information to hand.
Probably. Where would be the best place to get the optimal temperature for the information?
Done a little google search: "tyre temperatures Formula 1 2018", second finding was the perfect one:
https://www.reddit.com/r/formula1/comments/86ajnd/the_exact_working_ranges_of_the_2018_pirelli_tyres/ 


Edit: Wet tires missing in the pic.
If I remember right the inters will work well from 60°C -70°C and the full wets between 30°C - 40°C.
Link to post
Share on other sites
@Hoo
Is it me or if a player deactivates DRS when in a DRS zone, the UDP data temporarily shows drsAllowed as false? If so, please can you fix it?
I've already highlighted this bug previously in this thread, although no response yet. It would not be an evident issue if they increased the frequency of the car status packet to the game setting frequency (60hz in my case), or moved it to the car telemetry packet which is output at game frequency.

Because even without this bug, it's still not great entering a DRS zone and having to wait up to 500ms before the DRS legal status changes. It's really noticeable in game for me because I have an LED triggered by DRS legal.
Link to post
Share on other sites
  • Hoo pinned this topic
  • Hoo unpinned this topic

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...