cjorgens79

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

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

@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

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

@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

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

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.

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

@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

Ok, thanks for the update.

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

@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

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

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.

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.

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

@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.5244140625 sTotalDist = -4152.5244140625 sRacePos = 6 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D2 -> FOREST sLapDist = -4238.380859375 sTotalDist = -4238.380859375 sRacePos = 2 lapNum = 1 mPitStatus: 1 sDriverStatus: 0 sResultStatus: 2 D3 -> MICHALSKI sLapDist = -4138.3212890625 sTotalDist = -4138.3212890625 sRacePos = 18 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D4 -> CALABRESI sLapDist = -4209.7451171875 sTotalDist = -4209.7451171875 sRacePos = 13 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D5 -> ATIYEH sLapDist = -4202.4130859375 sTotalDist = -4202.4130859375 sRacePos = 7 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D6 -> CLARKE sLapDist = -4195.6396484375 sTotalDist = -4195.6396484375 sRacePos = 10 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D7 -> LEVASSEUR sLapDist = -4252.5053710938 sTotalDist = -4252.5053710938 sRacePos = 12 lapNum = 1 mPitStatus: 1 sDriverStatus: 0 sResultStatus: 2 D8 -> BELOUSOV sLapDist = -4159.8955078125 sTotalDist = -4159.8955078125 sRacePos = 11 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D9 -> CORREIA sLapDist = -4245.1743164063 sTotalDist = -4245.1743164063 sRacePos = 15 lapNum = 1 mPitStatus: 1 sDriverStatus: 0 sResultStatus: 2 D10 -> IZUMI sLapDist = -4188.3076171875 sTotalDist = -4188.3076171875 sRacePos = 8 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D11 -> MURRAY sLapDist = -4259.23046875 sTotalDist = -4259.23046875 sRacePos = 3 lapNum = 1 mPitStatus: 1 sDriverStatus: 0 sResultStatus: 2 D12 -> SCHIFFER sLapDist = -4231.0493164063 sTotalDist = -4231.0493164063 sRacePos = 17 lapNum = 1 mPitStatus: 1 sDriverStatus: 0 sResultStatus: 2 D13 -> KAUFMANN sLapDist = -4167.0986328125 sTotalDist = -4167.0986328125 sRacePos = 5 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D14 -> MORENO sLapDist = -4145.6923828125 sTotalDist = -4145.6923828125 sRacePos = 4 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D15 -> ROTH sLapDist = -4266.5610351563 sTotalDist = -4266.5610351563 sRacePos = 9 lapNum = 1 mPitStatus: 1 sDriverStatus: 0 sResultStatus: 2 D16 -> SAARI sLapDist = -4223.8271484375 sTotalDist = -4223.8271484375 sRacePos = 14 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D17 -> GILES sLapDist = -4302.1782226563 sTotalDist = -4302.1782226563 sRacePos = 19 lapNum = 1 mPitStatus: 1 sDriverStatus: 0 sResultStatus: 2 D18 -> LAURSEN sLapDist = -4174.4619140625 sTotalDist = -4174.4619140625 sRacePos = 20 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D19 -> LETOURNEAU sLapDist = -4216.4951171875 sTotalDist = -4216.4951171875 sRacePos = 1 lapNum = 1 mPitStatus: 0 sDriverStatus: 0 sResultStatus: 2 D20 -> BARNES sLapDist = -4294.8837890625 sTotalDist = -4294.8837890625 sRacePos = 16 lapNum = 1 mPitStatus: 1 sDriverStatus: 0 sResultStatus: 2

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 integrators when dealing with the telemetry data. Cheers