Welcome to the brand new Codemasters Forums! Be sure to check the FAQ and Forum Rules before you get started.

F1 2017 D-Box and UDP Output Specification

124

Comments

  • cjorgens79cjorgens79 Member New Car Smell
    One other thing I realised is that there doesn't seem to be any indication of session duration, would it be possible to get this field added? There is currently a session time field at the start of the struct, but no way to determine how long is left in a time based session. It could be addressed by either adding a new var to indicate session time remaining, or a new var to indicate total session duration from which time remaining could be calculated using the existing session time field.
  • IJS84IJS84 Member New Car Smell
    Has anyone unpacked this in python yet? I've not got the beta yet and I'm struggling to visualise how what the struct format code will be to unpack it all. I'm sure I'll figure it once the game is out, but would like a little head start on it
  • cjorgens79cjorgens79 Member New Car Smell
    @Hoo, has there been any changes to the telemetry api in todays beta, such as fixing the timing information being slightly out of sync during sector/lap changes? I couldnt see a complete change list anywhere so figured i would ask.
  • HooHoo Member, Codemasters admin
    We haven't made any changes in this latest beta. We are reviewing the various change requests at the moment.
  • cjacksonXBLcjacksonXBL Member New Car Smell
    edited August 8
    Seems like car data don't have speed. If we could have that, we can calculate gaps in secs between two cars. I could still calculate its speed with distance it moved and time diff between two packages but it is extra calculation for every packet received. 

    And also could we get tyre number or id in car data packet so we can calculate tyre history of cars. 

    I don't have beta access (if there is one) so I can't test my app. Is there any example raw data so I can use with my mock server to send it to my app. 
  • baxbax Member New Car Smell
    edited August 8
    Seems like car data don't have speed. If we could have that, we can calculate gaps in secs between two cars. I could still calculate its speed with distance it moved and time diff between two packages but it is extra calculation for every packet received. 

    And also could we get tyre number or id in car data packet so we can calculate tyre history of cars.
    Car speed is useless if you want to calculate the gap between 2 cars because cars have different speed in different parts of the track (straight or turn or chicane etc...). My way is: reset a timer_1 each time the first driver passes the finish line (m_sector value changes from 2 to 0) and compute time elapsed for each driver passing the finish line... you will have the gaps between each driver and the first one (excluding overlapped ones). Calling this ABSOLUTE gap, it will be easy to compute the RELATIVE gap between any 2 drivers.
    Doing the same for each sector change (3) you will have gaps updating 3 times during a single lap: it is enough in my opinion.

    m_tyreCompound is already available for each driver!
  • cjacksonXBLcjacksonXBL Member New Car Smell
    bax said:
    Seems like car data don't have speed. If we could have that, we can calculate gaps in secs between two cars. I could still calculate its speed with distance it moved and time diff between two packages but it is extra calculation for every packet received. 

    And also could we get tyre number or id in car data packet so we can calculate tyre history of cars.
    Car speed is useless if you want to calculate the gap between 2 cars because cars have different speed in different parts of the track (straight or turn or chicane etc...). My way is: reset a timer_1 each time the first driver passes the finish line (m_sector value changes from 2 to 0) and compute time elapsed for each driver passing the finish line... you will have the gaps between each driver and the first one (excluding overlapped ones). Calling this ABSOLUTE gap, it will be easy to compute the RELATIVE gap between any 2 drivers.
    Doing the same for each sector change (3) you will have gaps updating 3 times during a single lap: it is enough in my opinion.

    m_tyreCompound is already available for each driver!
    That will only change gap when sector change. I know gap changes at straight and braking points, but it is also like that in tv. 

    I didn't mean tyre compound, I know compound is there, but we can't know which set driver is using. There will be multiple sets of same compound and he might not change tyre every time he pit, also he could use already used tyre if no sets left and he punctured his tyres etc.
  • baxbax Member New Car Smell
    edited August 9
    That will only change gap when sector change. I know gap changes at straight and braking points, but it is also like that in tv. 

    I didn't mean tyre compound, I know compound is there, but we can't know which set driver is using. There will be multiple sets of same compound and he might not change tyre every time he pit, also he could use already used tyre if no sets left and he punctured his tyres etc.
    Even if you know exactly distance and speed for each part of the track you can not compute exactly the gap between 2 drivers using these 2 values because the 2nd driver can change his speed anyway anytime: you can only forecast the gap. There is no mathematic formula for this.
    The only way (I found) is to compute the elapsed time when 2 drivers pass on the same point of the track: you can use 3 sectors (as real F1 TV did till 2 year ago) or divide the track in more sub-sectors using distance value, creating your own grid (more points, more timers) as real F1 TV does in the last 2 years.

    About tyres: now I understand what you mean ;)
  • cjorgens79cjorgens79 Member New Car Smell
    @Hoo - just a bit of feedback from the testers of my app. They are loving the new features that are on offer with the new telemetry which is great. The biggest issue currently though is with the timing stopping the moment the player finishes or when they are paused (in multiplayer this is an issue). In the test i did tonight, i finished a race at the front which meant that all the timing for pos 2+ stops. So the final results of the actual race did not match what the app showed as it was only accurate up until the point i crossed the start finish line, the true results for everyone behind are impossible to get currently. For me this is an even bigger issue as i can store the session results to my online portal, problem is they will be wrong.

    Hopefully this issue can be solved before the game is released as now that we have all opponent timings available it is a really noticable problem.

    If any of your guys want beta access to the app just to see what sort of things 3rd partys like myself are doing (or to see the issue for themselves), just PM me with the email address they use for the app store and what platform they want to try the app on (iOS or Android) and ill add them to the beta testers list.

    Cheers
  • HooHoo Member, Codemasters admin
    @cjorgens79 - unfortunately, keeping the telemetry going after the race finishes isn't something we can easily fix at this stage in development. We're exploring options, but it seems like we may need to do a more significant re-write / re-organisation of our data to allow us to better control what data is sent when. This amount of work wouldn't happen before release though. In terms of aggregating results, we are looking into the session ID idea that was proposed, so at least local information can been uploaded and correlated. I'll let you know if this is something we can get into the current title.
  • DaveyGravyDaveyGravy Member New Car Smell
    @Hoo +1 from me for my Race Dash app on iOS for a unique session ID - this would be super helpful. Many thanks
  • cjorgens79cjorgens79 Member New Car Smell
    Hoo said:
    @cjorgens79 - unfortunately, keeping the telemetry going after the race finishes isn't something we can easily fix at this stage in development. We're exploring options, but it seems like we may need to do a more significant re-write / re-organisation of our data to allow us to better control what data is sent when. This amount of work wouldn't happen before release though. In terms of aggregating results, we are looking into the session ID idea that was proposed, so at least local information can been uploaded and correlated. I'll let you know if this is something we can get into the current title.
    @Hoo - understood, thanks for the info. On a related note, would it be possible to continue sending the last known telemetry after the player finishes for say a second. At the moment the telemetry stops very quickly, so quickly in fact that the only one or two packets get sent after crossing the start finish line. This means it is possible that sometimes the end of the session (ie lap change when the start finish line is crossed at the end) could be missed due to udp not being guaranteed. If it could send the final telemetry packet for another second or so, that should be more than enough to ensure it gets picked up by any clients so they can process the end of the final lap reliably. I have had this issue happen to me during testing, examination of other recorded sessions indicates that only one or two packets get sent after finishing which explains the issue.

    Also do you think the synchronisation of the timing and the lap/sector data in the telemetry will be fixed, ie so that when the start finish line is crossed, the lap time, sector time, prev lap time and lap dist will reset in the same packet that the sector and lap number increment. This particular issue is highly problematic since we don't have a sector 3 time, we need to rely on detecting the change of lap/sector and then cross reference against the lap time/last lap time and previous known sector times to work out what the final sector was. When these are out of sync it obviously makes things rather difficult.

    Thanks
    Craig
  • baxbax Member New Car Smell
    ...The biggest issue currently though is with the timing stopping the moment the player finishes or when they are paused (in multiplayer this is an issue). ...
    What if you are a spectator?
  • cjorgens79cjorgens79 Member New Car Smell
    bax said:
    ...The biggest issue currently though is with the timing stopping the moment the player finishes or when they are paused (in multiplayer this is an issue). ...
    What if you are a spectator?
    good question, i have been meaning to test out what happens in spectator mode but hadn't yet got around to it
  • cjacksonXBLcjacksonXBL Member New Car Smell
    What is the id of player in career mode? 
    Hoo said:
    I've just the traction control values with the handling team and they said this value is correct for the 2002 Ferrari as it has some in-built traction control. If you are seeing this with the modern cars or the 88 McLaren then there is probably a bug in there. 

    We'll get the IDs for the some classic teams and drivers released soon. 

  • RadioactiveJimRadioactiveJim Member Unleaded
    edited August 11

    Was wondering if those of you who are creating your telemetry apps could check something for me.

    I am using V-Dash by EKSimracing and it all works pretty well except for tyre pressure.

    For FR, RL & RR the value stays at 18 all the time, FL will start at 18 until I leave the pits then it will go up to 300 or 400 (higher if I click on a Convert to PSI first option) the thing is the data displayed has nothing to do with pressure it actually looks like it is displaying the brake temperature for that wheel as it closely follows the displayed data for brakes.

    If someone could confirm they are getting proper data for this I can relay that info back to Zappadoc at EKSimracing and he could get it fixed.


    Thanks for your help.

  • cjorgens79cjorgens79 Member New Car Smell

    Was wondering if those of you who are creating your telemetry apps could check something for me.

    I am using V-Dash by EKSimracing and it all works pretty well except for tyre pressure.

    For FR, RL & RR the value stays at 18 all the time, FL will start at 18 until I leave the pits then it will go up to 300 or 400 (higher if I click on a Convert to PSI first option) the thing is the data displayed has nothing to do with pressure it actually looks like it is displaying the brake temperature for that wheel as it closely follows the displayed data for brakes.

    If someone could confirm they are getting proper data for this I can relay that info back to Zappadoc at EKSimracing and he could get it fixed.


    Thanks for your help.

    I get a constant 18 psi from all 4 tyres. Tell him to check that he has taken the structure packing into account, otherwise it could result in unexpected values. 
  • RadioactiveJimRadioactiveJim Member Unleaded
    edited August 11

    Thank you, thing is though one would think it would read what the pressure was set to in the set up, default in most cases is around 23.4 on the fronts and 21.9 or something on the rears. It should also change a bit as the tyres heat up and cool down.

    So tyre pressure data is possibly not being output in the UDP data correctly. But yes the false readings are most likely a EKSim implementation error.



  • zappadoczappadoc Member New Car Smell
    Hi guys,
    always better to report in EKSIMRacing support forum. ;)
    The bug is confirmed , the brake temp of Front Left tire was wrongly reported in front left tire pressure as well, this doesn't impact the other wheels.
    The F1 2017 plugins (PC and Console Bridge XB1/PS4) have been fixed. Check For Update as usual to get the latest software.
    Changelog:
    http://www.eksimracing.com/forum/index.php?topic=4041.msg17224#msg17224

    Cheers,
    z

  • RadioactiveJimRadioactiveJim Member Unleaded
    edited August 11

    Thanks @zappadoc

    I was just checking here first then I was going to check with you.

    Still might for other things I mentioned in the beta forum.

Sign In or Register to comment.