Jump to content Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by cjorgens79

  1. Thanks @Hoo. I have applied for the beta however I noticed there was nowhere to indicate that I was signing up with the primary purpose of testing the updated telemetry api, hopefully this gets taken into consideration when deciding who gets access to the beta. Cheers
  2. Hi @Hoo, just wondering if there has been any movement on the whole player names GDPR thing? Thanks
  3. @Hoo I was doing some testing/telemetry recording in a multiplayer Race. At the end of the race session i got an End Session event, but I never got the Final Classification information. The qualifying session worked fine. Now in the race i retired my car at about 2/3rd's race distance and spectated the remainder of the race and let it finish properly and give me the results on screen, so its quite possible that this issue is only occuring because I (the player) didn't actually finish the race by crossing the start/finish line due to my early retirement.
  4. @Hoo, What does the value of 7 represent in m_resultStatus? This was asked during beta but I dont think we got an answer for it. I am seeing it in my data after retiring, but there is already another value for retired so it would be nice to know its true meaning.
  5. @Hoo, Multiplayer sessions still seem to be buggy when it comes to the player crossing the start finish line. Single player works fine, just online MP is the issue. From memory i think i reported this same issue with F1 2019. If you look at the log of lap/sector changes for a specific player you can see that at the end of the lap the sector number resets back to 1, but the lap number doesn't change immediately. So it briefly looks like the player is restarting the same lap. I would expect that when a player crosses the start/finish line both the lap number and sector number and last lap t
  6. Hi Hoo, PC1 and PC2 have always had player names for both the PC and consoles right from the moment they added their UDP telemetry protocol. iRacing does as well (although the interface itself is different), but they enforce the use of peoples real names, ie you can only play the sim using your real name, you cant use an alias or fake name at all, its tied to your payment information. As far as I understand it, the customers data (ie name) can be used as is required for the provision of the services you provide to them (eg multiplayer sim racing), what you're not allowed to do is col
  7. @Hoo, I've finally had a chance to put the Final Classification packet to use (I should have done it sooner but just haven't had the time). In general it works pretty well, just a couple of points to note 1. I am seeing an m_resultStatus value of 7 for the player, the description for that field says it should only go up to 6. So what does 7 represent? 2. The packet really needs to have the sector times and lap number that relate to the best lap time. I know its too late now to change it, but just letting you know so it can be added for next years game if no more changes are bein
  8. My apologies, I had forgotten that I had been applying a +1 offset to the value that I store internally in the online portal so that 0 is "not available" by default (for other games that dont implement it).
  9. I think its just a doco error that is in the previous game version protocols doco (that this was based off) as well. I'm seeing the same data range 1-4 for F1 2019 as well for example, yet the doco for that also says 0-3.
  10. Ok thanks for the clarification, I'll just add them post release.
  11. @Hoo Is there going to be another beta before release that contains the other tracks? In particular I am interested in the two new tracks as I need to build track maps for the app from the data. Also, is the protocol set in stone now? Cheers
  12. @Hoo - fyi the Event Packet info on the first page has the full packet structure and unioned sub structs posted twice.
  13. @Hoo - do you have a rough idea when the next beta (which has telemetry output that matches the current published final protocol structure) will be available? Just want to try and plan ahead to ensure there is enough time for us to do final testing on our apps and then get them approved for publishing by the app stores so they can be available to our users at the same time the game is. Cheers
  14. @Hoo, dont forget to also update the total packet lengths for all the other packet type descriptions. They all need +1 added to each existing size in the doco.
  15. Check the m_resultStatus field, its intention is to indicate whether or not the driver slot has valid data or not, if it is not a valid driver then any data in that driver's packet should be ignored. So basically ignore any drivers who's m_resultStatus value is less than 2.
  16. Thanks for the reply, after I posted it occurred to me that was probably the reason why the distances were negative. The pit status is a bug though as you have mentioned, it is easy enough to work around though. Re the "zero" stuff, yeah i know what you mean about the conflicting ids, however the result status field's intention is to indicate whether or not the driver slot has valid data or not, if it is not a valid driver then any data in that driver's packet should be ignored. I found this flag after that original post, however i still think it is cleaner for the unused slots to be zer
  17. I think this could be useful as well for those single player sessions where time jumps occur by going back to garage or jumping to a flying lap. There is plenty of room in the packet to allow the addition of 2 more floats for float m_bestLapSector1Time float m_bestLapSector2Time
  18. @Hoo The LapData packet has some anomalous data in it. This is the current state of drivers 6 seconds into a 30 minute practice session. Note that the Lap Distance and Total Distance values are large negatives. I would have expected these to be 0, as the session has just started and each driver is in the garage. The Pit Status also seems a bit random too, again everyone is in the garage however the pit status seems random between them. The very first LapData packet of the session looks exactly the same as well. D1 -> NIEVES sLapDist = -4152.524414062
  19. Just a minor point, I have been doing some api testing and have noticed that the two extra slots (21, 22) have randomish values in them for some fields that could make it a little confusing for some people working with the api. For example, the api is reporting 20 cars in the race (as expected), however slot 21 has semi valid x,z positional data, race position is 1 and lap number is 1. Slot 22 has no positional data, its race position is 0, but it is on lap 1. It would be nice if these slots could be cleared (zeroed out) properly so there is no randomish data in them to make it clearer for int
  • Create New...