F1 2018 UDP Specification

[LetMeThrashU]

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

[Lopensky]

LetMeThrashU said:

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

[EnsiFerrum]

LetMeThrashU said:

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.

[carlucio24]

Please Hoo, change frequency of CarStausData, 2 second is too too high

[LetMeThrashU]

EnsiFerrum said:

LetMeThrashU said:

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. 

[EnsiFerrum]

LetMeThrashU said:

EnsiFerrum said:

LetMeThrashU said:

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  

[LetMeThrashU]

EnsiFerrum said:

LetMeThrashU said:

EnsiFerrum said:

LetMeThrashU said:

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!

[Hoo]

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

[Hoo]

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.

[LetMeThrashU]

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?

[Hoo]

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

[LetMeThrashU]

Hoo said:

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

[btastical]

LetMeThrashU said:

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.

[cjorgens79]

Hoo said:

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

[mrbelowski]

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

[Hoo]

cjorgens79 said:

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

[Lopensky]

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? :)

[Alex35zombi]

@Hoo 1.06 has broken the driver carrer mode id it previously streamed 1 and now it streams 2 the same as Ricciardo

[CanTQuiT]

Another bug:

in multiplayer games w/ mix of  AI controlled and human controlled drivers  DriverID 0  (PARTICIPANTS PACKET) is given twice. (to human and AI controlled driver)

[btastical]

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

[Lopensky]

Thank you @btastical for your help.. since i use it in online races there should be no problem with flashbacks.. so i imagine i can assert it is unique for each session of the event (unique ID for Q, new unique ID for Race). :)

[EnsiFerrum]

LetMeThrashU said:

Hoo said:

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

[LetMeThrashU]

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

[IJS84]

@Hoo any thoughts on my idea of a hashed driver name?

[trenamax]

LetMeThrashU said:

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

[Lopensky]

IJS84 said:

@Hoo any thoughts on my idea of a hashed driver name?

Let's hope they will implement this, it's the best idea to solve the problem. :)

[Hoo]

Lopensky said:

IJS84 said:

@Hoo any thoughts on my idea of a hashed driver name?

Let's hope they will implement this, it's the best idea to solve the problem. :)

We've looked at the idea and there might still be some concerns regarding the latest privacy laws - we're still looking at various options, but don't think a straightforward hash would be sufficient. However, we have now fixed the driver IDs in online sessions so these should be stable for all of the known AI drivers. In addition, human players will have a unique ID for the duration of the multiplayer session, so you may be able to use the sessionUID and driverID to correlate results for a session more easily.

[IJS84]

Shame. Hope you can come up with something that can work as it's a real pain having to map driver names every session

[cjorgens79]

Hoo said:

Lopensky said:

IJS84 said:

@Hoo any thoughts on my idea of a hashed driver name?

Let's hope they will implement this, it's the best idea to solve the problem. :)

We've looked at the idea and there might still be some concerns regarding the latest privacy laws - we're still looking at various options, but don't think a straightforward hash would be sufficient. However, we have now fixed the driver IDs in online sessions so these should be stable for all of the known AI drivers. In addition, human players will have a unique ID for the duration of the multiplayer session, so you may be able to use the sessionUID and driverID to correlate results for a session more easily.

Re the privacy, I assume this is re GDPR? I'm not sure how including the gamer handles in the telemetry (which is generally constrained to the players LAN anyway, or could be for sure if you wanted to enforce it) would be a breach. Firstly the gamer handles are already being transmitted over the internet by the game for the multiplayer sessions, as each player in a MP session can see every other players gamer name. Not to mention anyone that is streaming their gaming sessions is also broadcasting that same information. Secondly anyone that joins an online session is well aware that their gamer handle is being passed onto other players / spectators. A handle in itself is fairly anonymous to the outside world without having some underlying linked account data to connect it to, which is not in anyway involved in the telemetry. I would imagine your TOS already cover the fact that gamer handles are shared with other during gaming sessions, so would that not also cover telemetry?

[Hoo]

We have to tread very carefully where there is a suggestion that user data can be passed to and stored by third parties without explicit consent. For our purposes, anything that can allow someone to correlate data with an individual user falls exactly into this category. There is a difference between passing around player information in a supposedly closed network environment and providing a data structure to facilitate to storing of this information. We are still considering a few of options which might still give you what you're after, so I'll let you know if there are any developments in this area.

[cjorgens79]

Hoo said:

We have to tread very carefully where there is a suggestion that user data can be passed to and stored by third parties without explicit consent. For our purposes, anything that can allow someone to correlate data with an individual user falls exactly into this category. There is a difference between passing around player information in a supposedly closed network environment and providing a data structure to facilitate to storing of this information. We are still considering a few of options which might still give you what you're after, so I'll let you know if there are any developments in this area.

Thanks for the info, yeah GDPR is great in principal but hard to deal with for a lot of companies due to some of the broad definitions they use.
Just a thought but why not just ask for explicit consent, if you want to play online you have to consent to your gamer tag being shared? Thanks for keeping us informed :)

[Lopensky]

Hoo said:

..

However, we have now fixed the driver IDs in online sessions so these should be stable for all of the known AI drivers. In addition, human players will have a unique ID for the duration of the multiplayer session, so you may be able to use the sessionUID and driverID to correlate results for a session more easily.

That sounds great! Some questions:

1 - when this is going to be released for PS4?

2 - Driver_id now is th eone that corresponds to the selected driver?

3 - Isn't the human players driver ID the one given by the selected F1 driver? In case, it's obvous that it keep the same value for whole multiplayer session.. If not.. please explain this better :P

[Hoo]

Lopensky said:

3 - Isn't the human players driver ID the one given by the selected F1 driver? In case, it's obvous that it keep the same value for whole multiplayer session.. If not.. please explain this better :P

Yes, but it is also possible for players to change teams at any point in a series of multiplayer races, so the ID would change. I think that the new way ensures that the ID stays the same until the player exits the multiplayer lobby. I'll check this with the dev team when I get a moment. This next set of fixes should go into the next patch. I'll give some more details once the patch has been through our test team.

[Lopensky]

Hoo said:

Lopensky said:

3 - Isn't the human players driver ID the one given by the selected F1 driver? In case, it's obvous that it keep the same value for whole multiplayer session.. If not.. please explain this better :P

Yes, but it is also possible for players to change teams at any point in a series of multiplayer races, so the ID would change. I think that the new way ensures that the ID stays the same until the player exits the multiplayer lobby. I'll check this with the dev team when I get a moment. This next set of fixes should go into the next patch. I'll give some more details once the patch has been through our test team.

Sincerely, this new solution seems really bug-prone, since you are forcing an ID to a driver that should have (and i expect him to have) a different one.. Not sure if there's someone out there that really need to keep IDs from different consecutive online races even if drivers change team. :|

If you can make it sure that if i choose Ricciardo my driver_id will be 2, if i choose Hamilton my driver_id will be 7 and so on (accordingly to the driver id table mappings in second post of this topic) that will be enought. If i change driver (ie seect ricciardo then pass to hamilton) i expect the driver_id to CHANGE (from 2 to 7), and that is the way it should work.

If id keeps the same then i will have someone with casual ids, maybe someone with Ricciardo and criver_id 7, while another that uses Hamilton and have a completely random id since 7 is already in use (or even worse, he could have 7 too or the ricciardo's one).

Do not make things work in an unpredictable way, keep it simple, please. :#

[cjorgens79]

@Hoo there appears to still be a bug related to the telemetry and flashbacks. It doesn't always happen, but it is happening. I have a telemetry recording from one of users who was doing a single player race (61 laps) against AI at singapore. What happens is that on lap 14 he hits the wall, between turns 12 and 12 (on the official map), then uses flashback to rewind back to half way between turns 9 and 10. At this point the telemetry triggers a complete session end (SEND) event packet, the m_sessionUID changes to a brand new ID and the m_sessionTime resets back to 0 as well. There may be other fields also reset, but these are the ones that are causing problems as it is effectively telling us apps that a completely new session has started. He did use flashbacks at other points without issue, there was one earlier on in the race that worked correctly.

[cjorgens79]

@Hoo if there are going to be any other changes to the struct, would it be possible to get each players "RaceTime" included, even if its only set once they cross the finish line at the end of a race. Would be handy to have the correct version of this, as our calculated data can currently get messed up sometimes due to flashbacks and lost packets. 

[Lopensky]

float m_bestLapTime; // Best lap time of the session in seconds

@cjorgens79 is this a trusted value to have the qualification best lap? Does this value ignores invalidated laps or not? :/

[cjorgens79]

cjorgens79 said:

@Hoo there appears to still be a bug related to the telemetry and flashbacks. It doesn't always happen, but it is happening. I have a telemetry recording from one of users who was doing a single player race (61 laps) against AI at singapore. What happens is that on lap 14 he hits the wall, between turns 12 and 12 (on the official map), then uses flashback to rewind back to half way between turns 9 and 10. At this point the telemetry triggers a complete session end (SEND) event packet, the m_sessionUID changes to a brand new ID and the m_sessionTime resets back to 0 as well. There may be other fields also reset, but these are the ones that are causing problems as it is effectively telling us apps that a completely new session has started. He did use flashbacks at other points without issue, there was one earlier on in the race that worked correctly.

@Hoo - got a bit more info from my user on the incident, he said "you are correct in that there was a SC come out which was for an incident involving two of the AI.  I was trying to get a clean run for testing fuel and tyres without a SC interruption so I used the flashback to get back to a point before the SC came out and on the restart from that there was no SC incident. The only difference between this FB and others that I can think of was that this one did not involve me in any way whereas the others were done after incidents (spins, crashes) that involved me."

It could be the SC aspect that is triggering the full reset, or flashing back from a SC period into a pre-SC period or something to that effect.

[cjorgens79]

Lopensky said:

float m_bestLapTime; // Best lap time of the session in seconds

@cjorgens79 is this a trusted value to have the qualification best lap? Does this value ignores invalidated laps or not? :/

I presume so, but I cant remember for sure whether I actually tested it or not, I suspect I probably would have..

[Hoo]

Lopensky said:

If you can make it sure that if i choose Ricciardo my driver_id will be 2, if i choose Hamilton my driver_id will be 7 and so on (accordingly to the driver id table mappings in second post of this topic) that will be enought. If i change driver (ie seect ricciardo then pass to hamilton) i expect the driver_id to CHANGE (from 2 to 7), and that is the way it should work.

In most session types the player drives as themselves, not as one of the official drivers. I think GP mode is the only mode where you drive as a licensed driver. In your example, you should be able to use the team ID to work out what vehicle they are in. If there is a requirement to know which of the two team slots they occupy in modern era races then that is a different piece of information that we don't currently send via the UDP packet.

[Lopensky]

Hoo said:

Lopensky said:

If you can make it sure that if i choose Ricciardo my driver_id will be 2, if i choose Hamilton my driver_id will be 7 and so on (accordingly to the driver id table mappings in second post of this topic) that will be enought. If i change driver (ie seect ricciardo then pass to hamilton) i expect the driver_id to CHANGE (from 2 to 7), and that is the way it should work.

In most session types the player drives as themselves, not as one of the official drivers. I think GP mode is the only mode where you drive as a licensed driver. In your example, you should be able to use the team ID to work out what vehicle they are in. If there is a requirement to know which of the two team slots they occupy in modern era races then that is a different piece of information that we don't currently send via the UDP packet.

Why doesn't you send the driver_id of the selected driver in online?!? :(

Which is the utility (or the motivation) of sending a "casual" id for real players? :/

At this point you are telling me there is no way to map these IDs in a decent way. I have to link udp driver to real one at each race start when i start receiving them. Exactly what i want to avoid. :|

Hoo said:

..

If there is a requirement to know which of the two team slots they occupy in modern era races then that is a different piece of information that we don't currently send via the UDP packet.

This is exactly what i (and others) need. And till now i was sure that the game was sending this info using the driver_id field! :| :| :|

[Faya]

Hi all,

I thought you might like to know that we have a number of UDP fixes in the 1.07 patch, which includes the following;

• Driver information should now be correct in online sessions
• Player names should now be correctly reported when a player leaves a session
• m_sessionUID should no longer change when exiting an instant replay
• Player names should no longer corrupt in online sessions
• Telemetry – Time trial classic car team id should now be correct
• Final telemetry info should now send
• Notification for allowing DRS should now be quicker
• Cars should no longer be listed as being in second gear while in the garage

Please do let us know if any of these are still giving you issues after you’ve updated to 1.07. For the other fixes that are not UDP related and platform release timelines, please see the thread here.

[Lopensky]

• Driver information should now be correct in online sessions
• Player names should no longer corrupt in online sessions
• Final telemetry info should now send
  

Can you please be more specific and give us more info about these 3 points? Just to know what has been done and what we have to expect :)

[Hoo]

Lopensky said:

• Driver information should now be correct in online sessions
• Player names should no longer corrupt in online sessions
• Final telemetry info should now send
  

Can you please be more specific and give us more info about these 3 points? Just to know what has been done and what we have to expect :)

1. The driver information would be incorrect for many of the drivers in an online session, e.g. you'd be racing against Bottas but the data was telling you that it was Vettel. As part of this change, the driver ID will be updated for human players to indicate that it is not one of the licensed drivers. 

2. This is the issue where you'd get "Player_" over-writing the first part someone's gamertag. The fix is to now only show "Player" without the other half of the gamertag being present.

3. This was the issue where the session would end, but the final packet which might contain the session end flag or some race results wouldn't be sent. The game should now always send this final packet.

[CNovice]

I am not able to recognise the two last buttons.

[..]

0x2000 Left Stick Click

0x4000 Right Stick Click

Is something wrong with my code?

public static UInt32 m_buttonStatus;

[..] // CAR TELEMETRY PACKET 6

m_buttonStatus = BitConverter.ToUInt32(receiveBytes, 1081);

Who can help?

Thanks.

[Lopensky]

Hoo said:

1. The driver information would be incorrect for many of the drivers in an online session, e.g. you'd be racing against Bottas but the data was telling you that it was Vettel. As part of this change, the driver ID will be updated for human players to indicate that it is not one of the licensed drivers.

Ok, this was something we have discussed here in the last days. So.. How is it working now?

What IDs i will have to expect to come out from the UDP data?

Human players will continue getting casual IDs exactly as they are doing now (except they do not get "IA-drivers fixed ones")?

Of course i'm talking about online lobbies, and my objective is to map the UDP data drivers to "real" ones.

Sorry if i'm asking more info but i really need to know how it is going to work to align my current working system to the new data the game is going to provide.. :|

[trenamax]

Thanks for increasing the DRS legal frequency. Looking forward to trying this out when I'm back from holiday next week.

Great job thanks Codemasters

[carlucio24]

Hi guys, how can I replicate the steering wheel bar that indicate the deployed energy per lap? 

I have done 2MJ - m_ersDeployedThisLap but does not match.
How can I do?

thank you

[DaveyGravy]

carlucio24 said:

Hi guys, how can I replicate the steering wheel bar that indicate the deployed energy per lap? 

I have done 2MJ - m_ersDeployedThisLap but does not match.
How can I do?

thank you

I’ve used 4MJ as the max store size in all the calculations in my Race Dash app and i think it matches OK.

[carlucio24]

So the right formula is 4MJ - m_ersDeployedThisLap ?