Jump to content

cjorgens79

Members
  • Content Count

    168
  • Joined

  • Last visited

Community Reputation

3 New Car Smell

Personal Information

  • Gamertags
    cjorgens79

Gaming Setup

  • Platforms
    Steam
  • Peripherals
    Steering Wheel
  • Steering Wheel
    Logitech G27

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. cjorgens79

    F1 2020 UDP Specification

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

    F1 2020 UDP Specification

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

    F1 2020 UDP Specification

    @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 time should all tick over together in the same frame rather than being spread across multiple frames which is problematic. F12020_Packet_LapData: P1 - Player 100 -> lap: 14, sect: 1, lastLapTime: 75.387, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 14, sect: 2, lastLapTime: 75.387, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 14, sect: 3, lastLapTime: 75.387, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 14, sect: 1, lastLapTime: 75.387, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 15, sect: 1, lastLapTime: 74.574, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 15, sect: 2, lastLapTime: 74.574, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 15, sect: 3, lastLapTime: 74.574, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 15, sect: 1, lastLapTime: 74.574, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 16, sect: 1, lastLapTime: 74.664, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 16, sect: 2, lastLapTime: 74.664, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 16, sect: 3, lastLapTime: 74.664, invalid: False, inPits: False F12020_Packet_LapData: P1 - Player 100 -> lap: 16, sect: 1, lastLapTime: 74.664, invalid: False, inPits: False It does this every lap and for every player in an online MP session (unsure about AI, but definately for human players). Cheers
  4. cjorgens79

    F1 2020 UDP Specification

    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 collect and store personal information for other reasons outside the expected service provisions, and you shouldn't be storing it for longer than is necessary. Any player that races online knows exactly what name is being used in that session, and i don't really see how the telemetry side is any different as their name is visible to every player/spectator in that session. Your not exposing additional information about them that is not already available on the screen, via an online live stream, or in the communications packets the games uses for synchronising the players in the session over the network. I would think that all that should be necessary on your side is to state in the terms of service that the user agrees to when they start the game for the first time, is that their user name will be visible to all other users in a multiplayer session, that there is the possibility that it may be included in a video recording or live stream broadcast by another user in that session and that it will be transmitted to other users in the session who have the UDP telemetry output enabled. I would also just state that if they do not agree to that part then they should not participate in any online sessions. At the end of the day then they have been informed, and it is their choice whether they want to use multiplayer or not. Everyone that plays in online sessions is aware what their name shows up as, and that other players can see it. If there are concerns about the telemetry data being broadcast across the internet, then just restrict the IP that the player can enter to any of the valid private IP address ranges, there are only a couple so its easy to restrict. That way you also ensure telemetry output is restricted to each users internal home network. I really hope this issue can be resolved, so many people complain about it and understand why its only an issue for the F1 games, when other games like PC1/2 have been doing it for many years. I would be interested to know what the legal justification for blocking it currently is, or whether its just a case of taking an overly cautious approach to a complex regulation that may be hard to understand, especially for non-technical people in how it relates to software. Cheers
  5. cjorgens79

    F1 2020 UDP Specification

    @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 being made to this one. There is plenty of room in the packet to fit that information. Edit: FYI I just checked and the result status value in the LapData packet also reports 7 for the player. Cheers
  6. cjorgens79

    F1 2020 UDP Specification

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

    F1 2020 UDP Specification

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

    F1 2020 UDP Specification

    Ok thanks for the clarification, I'll just add them post release.
  9. cjorgens79

    F1 2020 UDP Specification

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

    F1 2020 UDP Specification

    Ok, thanks for the update.
  11. cjorgens79

    F1 2020 UDP Specification

    @Hoo - fyi the Event Packet info on the first page has the full packet structure and unioned sub structs posted twice.
  12. cjorgens79

    F1 2020 UDP Specification

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

    F1 2020 UDP Specification

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

    F1 2020 UDP Specification

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

    F1 2020 UDP Specification

    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 zeroed out.
×