LonelyRacer

Luckily my tool has automated detection for ids/data not seen earlier. Here are the F2 2020 new drivers + new teams detected. These are from the Enums, my tool uses. TLA is automatically created, but should be correct. Drivers (I did edit the names, as the game only gives family name for these drivers). Format is (name, TLA, IDinGame) DanTicktum("Dan Ticktum", "TIC", 91), MarcusArmstrong("Marcus Armstrong", "ARM", 92), ChristianLundgaard("Christian Lundgaard", "LUN", 93), YukiTsunoda("Yuki Tsunoda", "TSU", 94), JehanDaruvala("Jehan Daruvala", "DAR", 95), GuilhermeSamaia("Guilhrme Samaia", "SAM", 96), PedroPiquet("Pedro Piquet", "PIQ", 97), FelipeDrugovich("Felipe Drugovich", "DRU", 98), RobertShwartzman("Robert Shwartzman", "SHW", 99), RoyNissany("Roy Nissany", "NIS", 100), MarinoSato("Marino Sato", "SAT", 101), F2 2020 Teams (took team names from the Race Director). Format is (IDinGame, Year, Long name, short name, Color Used e.g. in Map) F2_2020_ART(70, 2020, "ART Grand Prix", "Art 2020", Color.GRAY), // ART F2_2020_CAMPOS(71, 2020, "Campos Racing", "Campos 2020", Color.ORANGE), // Campos F2_2020_CARLIN(72, 2020, "Carlin", "Carlin 2020", Color.BLUE), //Carlin F2_2020_CHAROUZ(73, 2020, "Charouz Racing System", "Charouz 2020", Color.DARKBLUE), // Charouz F2_2020_DAMS(74, 2020, "DAMS", "DAMS 2020", Color.CYAN), // DAMS // light blue? F2_2020_UNI(75, 2020, "UNI-Virtuosi Racing", "UNI 2020", Color.YELLOW), // Uni virtu F2_2020_MP(76, 2020, "MP Motorsport", "MP 2020", Color.DARKRED), // MP Motorsport F2_2020_PREMA(77, 2020, "Prema Racing", "Prema 2020", Color.RED), // Prema F2_2020_TRIDENT(78, 2020, "Trident", "Trident 2020", Color.BLUE), // Trident F2_2020_BWT(79, 2020, "BWT HWA RACELAB", "BWT 2020", Color.PINK), // BWT F2_2020_HITECH(80, 2020, "Hitech Grand Prix", "Hitech 2020", Color.LIGHTGRAY), // Hitech If here are any errors, let me know. Cheers

Hoo, One more note. What you have now there in the LobbyPacket, you could easily be used. I see two ways_ You add to the data an id field, which is the same Id the players have in the other packets. This way the developers can then match the name with the data using the id. Or keep the lobby packet in the same order as the other packets, i..e. if a person is at index 0 in lobby packet, then that persons data is in other packets also at index 0. Cheers.

ACC has this through the Broadcast API. In ACC there can be many drivers per car. There is EntryListCar, which has car data (racenumber etc) and that has BroadcastDriverInfo[], which has first name, last name, short name, category and nationality. In Project Cars 2/AMS2 there is PacketParticipantsData, which has 3 arrays name[], nationality[], participantMPId[], name is String, 2 others are int16. There is also another struct ParticipantStatsInfo, which has array ParticipantStatsInfo[], which contains the players OnlineRep (has 2 elements, safety & "racecraft") + timing info. The PC2 stucture is bit messy, the ACC model is quite nice. With ACC there are some other issues with their broadcast API, which has some lag/latency issues, i.e. data is not always super up-to-date. Cheers.

lonelyf12012racer - steam

Hi, I see those names too, i.e. player and "giocatore" (player in Italian), haven't seen yet 'joueur'. My wild guess is that these are PS4 or XBox players. I don't use the lobby packet for anything, as the player order in that packet is different than in any other packets. I was just checking it during the last days to see, if I could use it for something, but to no avail. Cheers.

@Hoo Found two issues during testing today 1) The tyreInnerTemperature in CarTelemetry is different, that what is being shown in the MFD. I suspect, that the value is the real inner air temperature, not "carcass" temp, which is shown in MFD. I think with F1 2019 and maybe even with the beta (cannot be sure on that), the tyresInnerTemperature was same as in MFD. Any change for a fix? 2) During Time Trial in F1 2019 the lap data info was sent, which contained e.g. the lap distance and some other info of the ghost. Now in F1 2020 only players data is available, all other data (even the personal best ghost) is just 0's. I hope this is bug and not intentional. It would be great, if at least for the active Ghost there would be the laptime + sector times and the lapdistance per each packet. I used the lapdistance with F1 2019 to show laptime trace for the ghost, so my users could see where they were gaining on the ghost and where they lost time to the ghost. So any change, we could get the ghost's LapData filled with data as it was in F1 2019? Extra: And one request for F1 2021. Any change you could change Sainz driverId to be something else than 0. Would make life easier, if/when we have to do data massage to fix/notice problems in the feed. Edit: The tyreInnerTemperature is ok. Just a note to self, if you change from using direct index number to using special method, it is a good idea to update all locations, where the direct index number was used. ;-.) Fix request: The lapdata for Ghost in Time Trial is still just 0's. Checked and in F1 2018 and f1 2019 the data was there. Would be great, if in addition to the players car, also Personal Best ghost + Active Ghost data would be filled in the PacketLapData in Time Trial. Cheers.

Just tested this as I had not noticed anything odd. This is the data I am also getting, the ERS was fixed as per earlier comments. And the DRS distance too is working for me.

Did a rerun and actually found out, it was in Sochi on T6, where I had a super crash, i.e. went straight into the wall (was changing the telemetry pages, pressing overtake and changing fuel mix all at the same time ;-)). I guess the RoadSurface id 12 is under the barriers. See the image for the spot. So nothing critical. Cheers.

It was on certain section. I can run the data recording to try see, where it was/is. Cheers.

It seems to show real driver names, but based on the lobby packet, you cannot tell who is who. Cheers.

Hi, I managed to get into some nice 10+ player lobbies. Here are my findings on the Lobby Packet With the lobby packet the "m_frameId" in the PacketHeader doesn't increase, as I was expecting to happen. My tool uses the frame change as trigger to update screen, so I had to make a workaround, i.e. lobby packet also trigger a "frame change" regardless of the header. FIX NEEDED: Would be great, if the frameId would increase with the lobby packet. The lobby packet data order is just "random". The packetHeader in other packets has different playerindex, than with the lobby packet. Still the playerIndex in the LobbyPacket's header isn't correct. So the lobby data is totally useless for anything than showing who are ready or not, but you will see that anyway when you are in the lobby. E.g. FinalClassification comes in the right order, so I am still assuming this is a bug in the lobby packet, i.e. the data order is faulty. Or if in the LobbyInfoData there were driverId, then one could use that to assign the data to the right driver. FIX NEEDED: The order of data in lobbyPacket should be the same as in other packets. Or add DriverId to the LobbyInfoData, Cheers.

Great additions. Thanks. One note: I just drove in Sochi and from my tool's log I noticed, there was road surface with id 12. Could you check, if that was a correct detection and if there are other road surfaces added to the data. Cheers

@Hoo I have been doing more driving on the weekend, when I noticed the beta was available. While driving and testing two requests came to my mind. In the MFD you see the warning sign, when temps are too low or high or there is some other issue with the car. 1) Any change, you guys could add data for the MFD warning sing, i.e. a uint8 into the Car Telemetry Packet, which would have values 0 (no warning), 1 (tires too cold), 2 (tires too hot), 3 (brakes too cold), 4 (brakes too hot) etc. It could even be a bitmask, if you have too hot brakes + engine problems at the same time. 2) Now there is EngineDamage in the CarStatus packet. Would it be possible to get the individual component's damage level there instead, i.e. MGUH, MGUK etc. Cheers.

Ok. No worries on the DRS. I actually made a solution in my tool, where the DRS status is "undefined" at the start of each session. Then if any of the drivers gets the 'canUseDRS', I turn the DRS status to Enabled. After that if there is DRSD, then it goes to Disabled status or if there is DRSE, it goes to enabled. Works quite well. The speed trap would be great. Fingers crossed. Cheers.

@Hoo, I think the ERS mode is different than what is mentioned in the first page. (Tested with 2nd week beta). The modes seems to be 0 = none, 1 = medium, 2 = overtake, 3 = hotlap Could you check if that is the case and maybe update the data on the first page. I haven't noticed issues on other enums, but will keep checking them as I test. Cheers.

Is there supposed to be data coming into the lobby packets? When I am in an online lobby, I just get empty data for all drivers, i.e. the teamId is 255, everything else is 0 and name is empty string. This with lobby with other players. The number of drivers in lobby gets updated and is correct. I would expect at least my own driver name to be visible. Cheers

It seems to work as earlier. Waiting to see, how the lobby participant stuff works. A note about events. DRSE/DRSD. Would it be possible to send one of these after SSTA to provide info, if DRS is available or not. If you don't want to add another message, the SSTA could contain a byte of 0 or 1 indicating, if DRS is available or not at the start of the session. Speed trap event? Would it be possible to add a speed trap event, i.e. when the player gets notified of new top speed on speed trap, the game would also send an event like the FTPL but for top speed with driverId and the top speed gained. Cheers.

On the topic of Delta. Just wanted to share this, as I see so many people asking about the Delta. And I know there are few ways to do this. I used to calculate the delta as an estimate based on average speed and distances between the cars. Wasn't very good. I know that some people store only leaders time and position and calculate the delta from that. This is pretty easy way to get the deltas. My solution This is what I have done in my tool: https://www.racedepartment.com/downloads/telemetry-application.27456/ The users can set the accuracy, basically the distance between detection points. Range is from 1m to 500m. At the start of the race, I create an empty matrix, where each cell will contain <driverId, totalTime>. i.e. DeltaItem[columns][cars]. The width of the matrix (i.e. columns of the matrix) is: totalLapsInRace * trackLength / accuracyDistance. For 5 lap race in 5k track with 100m accuracy the matrix width is 250 columns. With 20 cars, it means 5000 cells, each containing an int and float, so approx 50kb of memory. For a 70lap race in 5k track with 1m accuracy, memory used is about 70mb. For 10 hour endurance with 60 cars (in ACC), this would be around .3gb, but there e.g. 200m accuracy is more than sufficient, which takes about 1.5mb to store the whole 10h race. At the start, the first column contains the situation at the start of the race. (totalDistanceDriven <= 0). The index for each column after start is easily calculated with floor(totalDistanceDriven / accuracyDistance) + 1. So if accuracy is 50, you have driven 225, then the column is 5. As the race commences and cars pass to the new "column", I store the leader to the top of the column and cars behind to lower positions, i.e. each column then contains from the top down the track positions at that point during the race. All cells in that column contain the driverId + totalTime at that point. Note, all times use the totalTime, you can get that .e.g from the header's sessionTime. So then when I calculate delta to the leader for certain car, I take their totalDistanceDriven, find the column. In that column I take their cell (based on driverId), then deduct from the total time the leaders total time (at row 0). This is the delta to the leader. E.g. leader entered column 6 at 17.1 and you entered there at 17.8, so delta is .7. Delta to the car in front you get by finding the cars column (with totalDistanceDriven) + row (based on driverId), then calculating the totalTime diff for the row and row - 1. So you entered at column 6, your total time entering the range was 17.8. The car in front (your row - 1) entered the column at 17.6, so the delta to front is .2. Delta to the car behind is similar, you just find the totalDistanceDriven for car behind, their correct column and then calculate the time difference to your cell on that column. The car behind is at column 5. Your time entering that range was 17.1 and the car behind entered at 17.5, so the delta to back is .4 Getting the data is pretty fast, as calls are direct array calls with index. The only small exception is to find the row, you compare with, which needs extra loop to find the right row with corresponding driverId, but in average it is MAX_CARS/2, so with F1 series about 10 extra calls per search. But if you really need to optimize that too, you could store for the columnsr a hashmap<driverId, index_in_that_column> to reduce this search also to a single call, but at a cost of memory (columns * hashmap size) One optimization one could do, is to store the data at the "game" order, i..e car at index 0 is stored at row 0 and so on. With F1 series this should be ok, as the order stays same during the race, but there are other games, where the "game order" changes, as people join/drop. This optimization would take away the driverId search mentioned above. Other optimization for a dash solution would be to store only 4 rows, 1 for leader, 1 for car in front, 1 for the player and 1 for the car behind. Then you would always have leader at row 0, person in front (at that point) at row 1, the player in row 2 and the car behind in row 3. So the "id checking" would go away, but you would still know, who is in front/behind, if you save the driverId on the cells. And you would have access to the delta history to leader for the player. For 70lap on 6k track with 1m accuracy takes about 17mb. With this implementation, during the race and/or at the end of the race, I can produce a chart like this. Cheers.

The negative values mean, the car is that far of from the start/finish line. F1 2018 & F1 2019 this was the case with P & Q. So when you start your outlap, the values increase hitting 0 when your outlap finishes and the first real lap starts. And the Trash in "unused" cars is also, what has been there at least in time trial and online races. If it doesn't get fixed/changed, then you have to massage the data yourself. That is what I have been doing with earlier games. I.e. by using the sResultStatus <= 1 to detect, if the driver is active and then modify inactive's values accordingly so they don't mess with the proper data. The issue I see with the zeroing to"0" the values is that there is DriverID 0 for Carlos Sainz, so if they "0" all data, you still have the issue if the driver is "inactive" or if it is Sainz. I would prefer they change the Sainz driverId to something else. Would make many things easier. I still need to do more driving and looking at the data to see, if there is anything odd/new going on this year. Thus far (some 3 hours of driving + some 15 hours or running save data feed on my tool), haven't noticed anything too critical.

Well, I don't think there is such a tool around. It requires bit extra work to get the F1 2019's multi-packet data into the legacy mode's single packet format (2017 data). As you are using XSimulator, I guess you only need the motion data in the legacy feed. I know I could do something like that with my tool. I could add an option to the data directs to forward the data in different format, where one option would be 2017, the legacy feed. And it could then be used for for future games too, possibly. So when you say We, what do you mean? 2 people, 10 people or something else? Cheers.

Well, I could give you all the fish, but then you would not learn how to catch the fish. I assume most people don't answer these questions here, as they have learned the stuff by error and trial with plenty of sweat. E.g. with F1 2012 there was no data structure available. You had to first look at the feed, use Wireshark or similar to check the byte arrays sent by the game. And when you got the numbers sorted out, you had to try to understand, what each value was for. And only then could you start building your app/tool. But now it is much easier, but I still prefer that people have to learn the stuff at least on some level ... Here is my help. On the fist page of this thread there is description of the different packets. Each packet has a header struct PacketHeader { uint16 m_packetFormat; // 2019 So you might want to first learn, what is uint16 and what it means. Then you need to find a way to convert the uint16 to a a value via PHP. Luckily for you, you know that the first uint16 must return 2019. When you get this far, i.e you get the 2019, then you can dive into getting other fields from the header. And then use the header data to see, which packets you are receiving from the game and keep going on parsing the packets. When you get that far, you can start thinking what you will do with the data. Happy learning.

Hello, I wanted to see, if there would be a list of tools using the UDP Telemetry, but there seems to be none. So let's start the thread. Other developers, please add your tools, so we can share what we have done. I go first: I have been developing my Telemetry tools since the first PC version of the F1 game, so yeah, I have seen a lot of stuff. In short, with my tool you can: Save your telemetry data and compare the laps. You can do real-time comparison agains fastest, session fastest or reference lap Real-time track map with the pit window visible (where you will land after good pitstop), Track map can show optimal line, fastest lap line, lines driver for seeing trends on your lines Extensive fuel/race info for getting most out of the racing (e.g. how to end the race with 0.01kg of fuel left) Visual comparison of laps in lap comparison tool Race history, track position history and laptimes graphs Save opponent laps in offline and online races and compare them to your own laps (good way to get better faster). XY Plotters for interesting graphs from the data Game can be on any platform (PC, PS, XBox). Telemetry tool runs on Windows, Linux and Mac, so you can now e.g. put your spare Mac laptop into a good use. You can get this from the RaceDepartment.com Some screenshots Main Telemetry screen Race Info Race history Track position history Comparison, fuel use XY Plotters on suspension

Hi @Hoo, Thank you for the update. My normal gaming setup gives me on the benchmark average 167 FPS (min 125, max 208) and I run the Telemetry typically on 60hz. My users are running in all 30hz, 30Hz and 60Hz modes with varying FPS (from consoles to PC). I haven't heard comments from my users about the G-force values, so my guess is that those on consoles don't notice this, only the higher end gaming PCs will see the issue and typicall people use the saved Telemetry data to analyze offline key inputs vs laptime and/or use the live data/race history to work their race strategies, and none of these need "smooth" Gforce data. I tried to limit the FPS etc with not much success. Only when I enabled the VSYNC, I started getting better data, but still there were occasional dips in the data. For some reason the game is not playable with VSYNC, as I get constant minifreezes, so I cannot use it. Cheers

That is from a saved lap data from prior November 2nd. The first version I have with bad data seems to be from Nov 5th. (I have 5GB saved data trace from October 15th, which still had the proper Gforce data). The bug was not there in the beta or in the early releases.

Hello, Wrote on the UDP specifications, but also writing this here. Found this bug, when testing new version of my Telemetry tool. I haven't really done any driving on the game for few months, but got back now and noticed this issue. Platform: PC/Win 7 Version: Latest 1.21 Tested: All frequencies, broadcast and non-broadcast feed The GForce values (Lat,Lon,Vert) in the UDP Telemetry data are mostly 0 and there are short blips with value. There was similar bug in F1 2018 at some point, but it got fixed. My last good "data" is from early November, where the saved lap data still has proper values from the Telemetry feed. Image of "erroneous data". What it should look like I hope this can still be fixed in the game. Cheers.