Jump to content Jump to content

cjorgens79

Members
  • Content Count

    192
  • Joined

  • Last visited

Everything posted by cjorgens79

  1. You should verify your packet structure, if you are out by even 1 byte or out of order you can end up with values like that. Also look at how your decoding the data, if your reading it straight into a struct then you need to remove any struct padding as well from memory.
  2. 255.255.255.255 is what the Project CARS games all use for their UDP telemetry. It's also possible that the game itself may do some sort of validation on the IP address entered and disable telemetry if it doesn't like the look of it.
  3. FYI try manually using the broadcast address instead and see if that works, I wonder if the series x has some networking restrictions that are causing issues. I would suggest trying a subnet broadcast first. To do this, make sure the broadcast option in the game is turned off, and in the IP address put the IP of one of your devices but change the last number to 255. So if your device was 192.168.100.40, then you would set the IP to 192.168.100.255 The alternative is a global broadcast, for this you would use 255.255.255.255 as the IP address, however this tends to be less compatible with
  4. Hi, Thanks for letting me know, I will check it out and get it sorted. For RS Dash specific support questions, you are best emailing support@pocketplayground.net directly. With regards to having actual player names (or PSN ID, etc) , this is a limitation of the game itself. Codemasters legal department does not currently allow personal account identifiers to be transmitted over the telemetry feed. If you check page 2 of this forum topic there is discussion about this topic (sending gamer tags) with Codemasters staff. Cheers
  5. Using a salted hash as is standard for secure storage of passwords is not reversible, then b64 or hex it so its displayable. There would need to be considerations though as to the length of the resulting hash string to ensure it fits in the allocated space for driver names.
  6. Have you looked at what packet types are actually being sent during this time? I know that Event packets for Button Status are now sent while in the menus, as this was requested by app developers so that we can navigate screens in our apps while also in the menu in the game using the controller buttons. Assuming it is only the "button status" events, then it sounds to me like the issue is that the motion platforms aren't properly reading the telemetry.
  7. I was looking at that field in the data yesterday and it was working fine for me on windows version. It is zero for a bit before session starts and after session ends, but during it was ticking over just fine. I was looking at data from single player sessions at the time though.
  8. I believe in previous versions of the protocol Team 41 indicated it was a "Multiplayer" team, so I assume it is still the same even though its not documented in the latest spec by looks of it.
  9. Just a couple of comments in red regaring the above points. Cheers
  10. 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
  11. Hi @Hoo, just wondering if there has been any movement on the whole player names GDPR thing? Thanks
  12. @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.
  13. @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.
  14. @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
  15. 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
  16. @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
  17. 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).
  18. 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.
  19. Ok thanks for the clarification, I'll just add them post release.
  20. @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
  21. @Hoo - fyi the Event Packet info on the first page has the full packet structure and unioned sub structs posted twice.
  22. @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
  23. @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.
  24. 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.
×
×
  • Create New...