Hoo

Hi @JJgamer, We're sorry to hear that you are having issues accessing the game. Please could you confirm whether this was a purchase through the PlayStation Store and also let us know what country / region you purchased the product from? Thanks.

Thanks for all the feedback so far. We will be going through this next week with the team to identify any bugs that we can fix. Regarding the player names issue, if anyone can provide examples of other current games that also provide player names through a similar API or output system, that would be very helpful for us to use as reference. 🙂

a) That looks correct. v1.01 is missing the DRS activation zone, suggested gear changes and a few bug fixes. b) Hopefully soon!

To confirm, the final UDP spec listed in the first post in this thread applies to v1.02 or later of the main game. Xbox users will need the next update to bring the UDP in line with this specification. I think a couple of the later changes were not available in v1.01. Apologies for the confusion with this.

The 1.03 main game should contain the full UDP implementation used in the final beta version. What specific issues are you seeing?

We've checked this internally and believe the doc to be correct, using 0-3 for the settings. Our test app shows this to be outputting as expected using these values.

That was the last beta update I'm afraid. We aren't planning any further changes to the protocol now. There might be a couple of bugs fixes or perhaps non-breaking changes made to the structs, but any apps built using the current spec should continue to work after launch.

@F1Setups & @StryderIT, Thanks for reporting this issue. The gears should be working in the new beta version, so looks like something has gone wrong here. I'll ask the team to take a look.

Thanks for confirming. I've asked the team to double-check in case there is anything incorrectly marked up.

Hi @LonelyRacer - surface id#12 is our default material which shouldn't be used for the road surface. Can you confirm where on the track you were seeing this? Was it the whole circuit or just a specific section of it? Thanks.

Sorry - there's been a delay with the update. It is now expected next week.

Thanks - I've updated that now.

Hi All, We’ve made some changes to the UDP data based on your feedback. This has resulted in multiple changes to the packet structure, so please check against the latest spec on the first page of this thread to see what has changed. The intention is for this to be the final 2020 specification now – we don’t plan on making any structural changes unless a serious issue is found. We can obviously still fix bugs if the data isn’t working correctly, so please let us know if you spot anything wrong. The changes that have been made are: Beta 2: Added m_secondaryPlayerCarIndex into the PacketHeader to identify the second player in splitscreen mode Beta 2: Updated the comments in the ersDeployMode of the CarStatusData packet to show the correct ERS values Beta 3: Added the MFD panel index to the PacketCarTelemetryData to identify what HUD screen the player is currently viewing Beta 3: Added best sector times and lap numbers to the LapData packet to allow tracking of the best sector times in the session. Note: all sector times have been changed to milliseconds (uint16 instead of float) to reduce the packet size to make room for the extra data Beta 3: Added m_drsFault to the CarStatusData packet to show when DRS has been disabled due to a technical fault Beta 3: Added a Speed trap triggered event (“SPTP”). This provides the vehicleID and speed of the fastest car to pass through the speed trap. Note: the intention is to change this so that it triggers whenever a car beats its own speed trap record, rather than just showing the fastest car. Beta 3: Bug fix to correctly show front wing damage as 100% in the UDP data when wing is removed Beta 3: Bug fix to only show data for active cars Beta 3: Updated driver ID table in the appendices as some drivers were missing or using incorrect IDs Beta 3.1: Added m_drsActivationDistance to CarStatusData to indicate whether the car has passed detection and when it will be available in the subsequent activation zone (next patch) Beta 3.1: Suggested gear added to the car telemetry packet (next patch) The final two points may result in a data mismatch until the updated beta patch comes out with these new fields added. I decided to post the intended final spec rather than changing this multiple times in the same week. Thanks, Hoo.

Sorry, there have been quite a few changes (hopefully the last ones). Unfortunately, I'm trying to pick through these as the current beta version is a touch behind the latest / final spec, so I'm trying to work out what to do with this. I'll update this thread as soon as I can.

We've had a look into this and the DRS event is a bit tricky to do as it involves us changing game logic. Currently, DRS is never available at the start of a race session, and is always available in Qualifying, Practice and Time Trial unless it is wet, so it should be possible to use the existing session information to provide the current DRS state. The speed trap event should be possible though.

Good spot! I've updated the comments on the first post to show this.

Hi @StryderIT, We've logged the wing issue with the dev team. I'm not sure showing a damage value is appropriate for the DRS being unavailable due to a temporary fault. I wonder if perhaps an event message would be a better way to report this, or maybe updating the DRS status field in the CarStatusData with a value for a technical fault? Thanks, Hoo.

Hi @LonelyRacer , It looks like there was a bug introduced elsewhere that broke the LobbyInfo packet. This will be fixed for the next beta. Thanks.

We added an extra field into the PacketHeader struct to allow you to identify the second player in splitscreen. I've updated the spec in the original post. Apologies for not identifying this - I didn't think any of our recent changes had made it into Beta 2, but it looks like this one found its way in!

Thanks for all of the feedback so far everyone. We're looking into some of these issues now. In terms of delta times, we're not considering adding this in at the moment as the data should exist for everyone to do what they need. As stated above, delta time has so many different approaches and uses that it isn't something that we can add in to accommodate everyone's own use case. For example, there have been requests for the gap to the car in front, pitting delta, realtime delta used in Time Trial. Even something a simple as gap to the car in front comes with lots of design interpretation to make it work correctly: If we simply work out the gap time gap between each car passing the specified point in the circuit, how do we interpolate between differences in track position reported by the car as these don't usually align? What happens when cars enter the pit lane or go off track? Do we consider using predictive deltas, or based them retrospectively on cars passing the same point in the track? What happens if you are not racing the car in front due to lapping them or alternative pitting strategies? What happens if cars are on in-laps or out-laps? ... and so on. The game already uses a few different approaches to delta times and even more have been suggested by the community. As each one is a subjective design choice, we prefer to just provide the lap and time data and let you all choose how to use this. We'll provide an update on the various changes and bug fixes ahead of the next beta phase. Thanks.

Hi @Oasis81, In single player mode the session ends once the player has finished their session, so the UDP data simply reflects what the game is doing. If the game were to allow the session to continue and the player to spectate for the rest of the session (like it does in multiplayer) then this should just work in the UDP data. However, this is a bigger feature request that is beyond the scope of the UDP telemetry data. I can pass the suggestion back to the team if that is what you are proposing. For the second point, the LapData packet currently keeps only the latest sector information. These times can obviously be stored by your app if needed. Are you suggesting that we should add a set of "best sector" times into the LapData packet? Thanks, Hoo.

This isn't something we plan on doing as delta time implementation is a design choice that involves specific logic to evaluate rather than an objective piece of real-time data. There are too many different approaches to this to give a "correct" delta, so we will simply provide the time and positional data for the cars and app developers can work out how they want to interpret this.

Appendices Here are the values used for the team ID, driver ID and track ID parameters. N.B. Driver IDs in network games differ from the actual driver IDs. All the IDs of human players start at 100 and are unique within the game session, but don’t directly correlate to the player. Team IDs ID Team ID Team ID Team 0 Mercedes 21 Red Bull 2010 42 Art GP ’19 1 Ferrari 22 Ferrari 1976 43 Campos ’19 2 Red Bull Racing 23 ART Grand Prix 44 Carlin ’19 3 Williams 24 Campos Vexatec Racing 45 Sauber Junior Charouz ’19 4 Racing Point 25 Carlin 46 Dams ’19 5 Renault 26 Charouz Racing System 47 Uni-Virtuosi ‘19 6 Alpha Tauri 27 DAMS 48 MP Motorsport ‘19 7 Haas 28 Russian Time 49 Prema ’19 8 McLaren 29 MP Motorsport 50 Trident ’19 9 Alfa Romeo 30 Pertamina 51 Arden ’19 10 McLaren 1988 31 McLaren 1990 53 Benetton 1994 11 McLaren 1991 32 Trident 54 Benetton 1995 12 Williams 1992 33 BWT Arden 55 Ferrari 2000 13 Ferrari 1995 34 McLaren 1976 56 Jordan 1991 14 Williams 1996 35 Lotus 1972 15 McLaren 1998 36 Ferrari 1979 16 Ferrari 2002 37 McLaren 1982 17 Ferrari 2004 38 Williams 2003 18 Renault 2006 39 Brawn 2009 19 Ferrari 2007 40 Lotus 1978 20 McLaren 2008 41 F1 Generic car 255 My Team Driver IDs ID Driver ID Driver ID Driver 0 Carlos Sainz 37 Peter Belousov 70 Rashid Nair 1 Daniil Kvyat 38 Klimek Michalski 71 Jack Tremblay 2 Daniel Ricciardo 39 Santiago Moreno 74 Antonio Giovinazzi 6 Kimi Räikkönen 40 Benjamin Coppens 75 Robert Kubica 7 Lewis Hamilton 41 Noah Visser 78 Nobuharu Matsushita 9 Max Verstappen 42 Gert Waldmuller 79 Nikita Mazepin 10 Nico Hulkenburg 43 Julian Quesada 80 Guanya Zhou 11 Kevin Magnussen 44 Daniel Jones 81 Mick Schumacher 12 Romain Grosjean 45 Artem Markelov 82 Callum Ilott 13 Sebastian Vettel 46 Tadasuke Makino 83 Juan Manuel Correa 14 Sergio Perez 47 Sean Gelael 84 Jordan King 15 Valtteri Bottas 48 Nyck De Vries 85 Mahaveer Raghunathan 17 Esteban Ocon 49 Jack Aitken 86 Tatiana Calderon 19 Lance Stroll 50 George Russell 87 Anthoine Hubert 20 Arron Barnes 51 Maximilian Günther 88 Guiliano Alesi 21 Martin Giles 52 Nirei Fukuzumi 89 Ralph Boschung 22 Alex Murray 53 Luca Ghiotto 23 Lucas Roth 54 Lando Norris 24 Igor Correia 55 Sérgio Sette Câmara 25 Sophie Levasseur 56 Louis Delétraz 26 Jonas Schiffer 57 Antonio Fuoco 27 Alain Forest 58 Charles Leclerc 28 Jay Letourneau 59 Pierre Gasly 29 Esto Saari 62 Alexander Albon 30 Yasar Atiyeh 63 Nicholas Latifi 31 Callisto Calabresi 64 Dorian Boccolacci 32 Naota Izum 65 Niko Kari 33 Howard Clarke 66 Roberto Merhi 34 Wilheim Kaufmann 67 Arjun Maini 35 Marie Laursen 68 Alessio Lorandi 36 Flavio Nieves 69 Ruben Meijer Track IDs ID Track 0 Melbourne 1 Paul Ricard 2 Shanghai 3 Sakhir (Bahrain) 4 Catalunya 5 Monaco 6 Montreal 7 Silverstone 8 Hockenheim 9 Hungaroring 10 Spa 11 Monza 12 Singapore 13 Suzuka 14 Abu Dhabi 15 Texas 16 Brazil 17 Austria 18 Sochi 19 Mexico 20 Baku (Azerbaijan) 21 Sakhir Short 22 Silverstone Short 23 Texas Short 24 Suzuka Short 25 Hanoi 26 Zandvoort Nationality IDs ID Nationality ID Nationality ID Nationality 1 American 31 Greek 61 Panamanian 2 Argentinean 32 Guatemalan 62 Paraguayan 3 Australian 33 Honduran 63 Peruvian 4 Austrian 34 Hong Konger 64 Polish 5 Azerbaijani 35 Hungarian 65 Portuguese 6 Bahraini 36 Icelander 66 Qatari 7 Belgian 37 Indian 67 Romanian 8 Bolivian 38 Indonesian 68 Russian 9 Brazilian 39 Irish 69 Salvadoran 10 British 40 Israeli 70 Saudi 11 Bulgarian 41 Italian 71 Scottish 12 Cameroonian 42 Jamaican 72 Serbian 13 Canadian 43 Japanese 73 Singaporean 14 Chilean 44 Jordanian 74 Slovakian 15 Chinese 45 Kuwaiti 75 Slovenian 16 Colombian 46 Latvian 76 South Korean 17 Costa Rican 47 Lebanese 77 South African 18 Croatian 48 Lithuanian 78 Spanish 19 Cypriot 49 Luxembourger 79 Swedish 20 Czech 50 Malaysian 80 Swiss 21 Danish 51 Maltese 81 Thai 22 Dutch 52 Mexican 82 Turkish 23 Ecuadorian 53 Monegasque 83 Uruguayan 24 English 54 New Zealander 84 Ukrainian 25 Emirian 55 Nicaraguan 85 Venezuelan 26 Estonian 56 North Korean 86 Welsh 27 Finnish 57 Northern Irish 87 Barbadian 28 French 58 Norwegian 88 Vietnamese 29 German 59 Omani 30 Ghanaian 60 Pakistani Surface types These types are from physics data and show what type of contact each wheel is experiencing. ID Surface 0 Tarmac 1 Rumble strip 2 Concrete 3 Rock 4 Gravel 5 Mud 6 Sand 7 Grass 8 Water 9 Cobblestone 10 Metal 11 Ridged Button flags These flags are used in the telemetry packet to determine if any buttons are being held on the controlling device. If the value below logical ANDed with the button status is set then the corresponding button is being held. Bit Flag Button 0x0001 Cross or A 0x0002 Triangle or Y 0x0004 Circle or B 0x0008 Square or X 0x0010 D-pad Left 0x0020 D-pad Right 0x0040 D-pad Up 0x0080 D-pad Down 0x0100 Options or Menu 0x0200 L1 or LB 0x0400 R1 or RB 0x0800 L2 or LT 0x1000 R2 or RT 0x2000 Left Stick Click 0x4000 Right Stick Click Penalty types ID Penalty meaning 0 Drive through 1 Stop Go 2 Grid penalty 3 Penalty reminder 4 Time penalty 5 Warning 6 Disqualified 7 Removed from formation lap 8 Parked too long timer 9 Tyre regulations 10 This lap invalidated 11 This and next lap invalidated 12 This lap invalidated without reason 13 This and next lap invalidated without reason 14 This and previous lap invalidated 15 This and previous lap invalidated without reason 16 Retired 17 Black flag timer Infringement types ID Infringement meaning 0 Blocking by slow driving 1 Blocking by wrong way driving 2 Reversing off the start line 3 Big Collision 4 Small Collision 5 Collision failed to hand back position single 6 Collision failed to hand back position multiple 7 Corner cutting gained time 8 Corner cutting overtake single 9 Corner cutting overtake multiple 10 Crossed pit exit lane 11 Ignoring blue flags 12 Ignoring yellow flags 13 Ignoring drive through 14 Too many drive throughs 15 Drive through reminder serve within n laps 16 Drive through reminder serve this lap 17 Pit lane speeding 18 Parked for too long 19 Ignoring tyre regulations 20 Too many penalties 21 Multiple warnings 22 Approaching disqualification 23 Tyre regulations select single 24 Tyre regulations select multiple 25 Lap invalidated corner cutting 26 Lap invalidated running wide 27 Corner cutting ran wide gained time minor 28 Corner cutting ran wide gained time significant 29 Corner cutting ran wide gained time extreme 30 Lap invalidated wall riding 31 Lap invalidated flashback used 32 Lap invalidated reset to track 33 Blocking the pitlane 34 Jump start 35 Safety car to car collision 36 Safety car illegal overtake 37 Safety car exceeding allowed pace 38 Virtual safety car exceeding allowed pace 39 Formation lap below allowed speed 40 Retired mechanical failure 41 Retired terminally damaged 42 Safety car falling too far back 43 Black flag timer 44 Unserved stop go penalty 45 Unserved drive through penalty 46 Engine component change 47 Gearbox change 48 League grid penalty 49 Retry penalty 50 Illegal time gain 51 Mandatory pitstop

FAQS How do I enable the UDP Telemetry Output? In F1 2020, UDP telemetry output is controlled via the in-game menus. To enable this, enter the options menu from the main menu (triangle / Y), then enter the settings menu - the UDP option will be at the bottom of the list. From there you will be able to enable / disable the UDP output, configure the IP address and port for the receiving application, toggle broadcast mode and set the send rate. Broadcast mode transmits the data across the network subnet to allow multiple devices on the same subnet to be able to receive this information. When using broadcast mode it is not necessary to set a target IP address, just a target port for applications to listen on. Advanced PC Users: You can additionally edit the game’s configuration XML file to configure UDP output. The file is located here (after an initial boot of the game): ...\Documents\My Games\<game_folder>\hardwaresettings\hardware_settings_config.xml You should see the tag: <motion> ... <udp enabled="false" broadcast=”false” ip="127.0.0.1" port="20777" sendRate=”20” format=”2020” yourTelemetry=”restricted” /> ... </motion> Here you can set the values manually. Note that any changes made within the game when it is running will overwrite any changes made manually. Note the enabled flag is now a state. What has changed since last year? F1 2020 sees the following changes to the UDP specification: Penalties have been added as a new Event Type Weather forecast data is now available in session packets for upcoming sessions Reduced the size of the surface and inner tyre temperature fields in the Car Telemetry to reduce overall packet size as more vehicles need to be added My Team allows an extra team to race – this means that all the places in the packets where 20 cars were used, 22 are now needed. N.B. this will not be fixed in old formats (2019, 2018, legacy) – if you are in the “My Team” career mode with any format other than 2020 specified, no data will be output. All other game modes will function as before Added Vietnamese and Barbadian nationalities Added Final Classification packet for end of race results Made m_gridPosition the actual numerical position, not 0-based (only in 2020 data) Added Lobby Info packet to send data to UDP when in a multiplayer lobby Added number of laps the current set of tyres have been used for in status packet Split the tyre pressures in Car Setups packet into RL, RR, FL, FR to reflect the game changes Added secondary player car index to packet headers for splitscreen Added MFD Panel Index to the car telemetry packet for both players Added best sector times and lap numbers to the laps packet as they cannot always be recorded correctly (e.g. fast-forwarding time) – N.B. the order has been slightly rearranged to tidy up Changed all sector times in lap data packet to be in milliseconds (uint16 instead of float) to reduce packet size so other things can be added Added indicator for DRS faults to the car status packet Updated ERS mode values Speed trap triggered event added Added DRS activation distance to indicate whether the car has passed detection and DRS will be available in the subsequent activation zone Suggested gear added to the car telemetry packet What is the order of the wheel arrays? All wheel arrays are in the following order: 0 – Rear Left (RL) 1 – Rear Right (RR) 2 – Front Left (FL) 3 – Front Right (FR) Do the vehicle indices change? During a session, each car is assigned a vehicle index. This will not change throughout the session and all the arrays that are sent use this vehicle index to dereference the correct piece of data. What encoding format is used? All values are encoded using Little Endian format. Are the data structures packed? Yes, all data is packed, there is no padding used. Will there always be 20 cars in the data structures? No, for F1 2020, there is a new feature called “My Team” which allows an extra team to be present on the grid. This means that all previous places where 20 cars were used, 22 is now the maximum. If “My Team” is not active however, most games modes will act as before and have a maximum of 20. Note that if your UDP format is 2019, 2018 or legacy and you are in “My Team” career mode, no UDP output will be produced because of this imitation. There is still the data item called m_numActiveCars in the participants packet which tells you how many cars are active in the race. However, you should check the individual result status of each car in the lap data to see if that car is actively providing data. If it is not “Invalid” or “Inactive” then the corresponding vehicle index has valid data. How often are updated packets sent? For the packets which get updated at “Rate as specified in the menus” you can be guaranteed that on the frame that these get sent they will all get sent together and will never be separated across frames. This of course relies on the reliability of your network as to whether they are received correctly as everything is sent via UDP. Other packets that get sent at specific rates can arrive on any frame. If you are connected to the game when it starts transmitting the first frame will contain the following information to help initialise data structures on the receiving application: Packets sent on Frame 1: (All packets sent on this frame have “Session timestamp” 0.000) Session Participants Car Setups Lap Data Motion Data Car Telemetry Car Status As an example, assuming that you are running at 60Hz with 60Hz update rate selected in the menus then you would expect to see the following packets and timestamps: Packets sent on Frame 2: (All packets sent on this frame have “Session timestamp” 0.016) Lap Data Motion Data Car Telemetry Car Status … Packets sent on Frame 31: (All packets sent on this frame have “Session timestamp” 0.5) Session (since 2 updates per second) Car Setups (since 2 updates per second) Lap Data Motion Data Car Telemetry Car Status Will my old app still work with F1 2020? F1 2020 uses a new format for the UDP data. However, earlier formats of the data are still supported so that most older apps implemented using the previous data formats should work with little or no change from the developer. To use the old formats, please enter the UDP options menu and set “UDP Format” to either “F1 2019”, “F1 2018” or “Legacy” (for F1 2017 and earlier). Specifications for the legacy format can be seen here: http://forums.codemasters.com/discussion/53139/f1-2017-d-box-and-udp-output-specification/p1. Specifications for the F1 2018 format can be seen here: https://forums.codemasters.com/topic/30601-f1-2018-udp-specification/. How do I enable D-BOX output? D-BOX output is currently supported on the PC platform. In F1 2020, the D-BOX activation can be controlled via the menus. Navigate to Game Options->Settings->UDP Telemetry Settings->D-BOX to activate this on your system. Advanced PC Users: It is possible to control D-BOX by editing the games’ configuration XML file. The file is located here (after an initial boot of the game): ...\Documents\My Games\<game_folder>\hardwaresettings\hardware_settings_config.xml You should see the tag: <motion> <dbox enabled="false" /> … </motion> Set the “enabled” value to “true” to allow the game to output to your D-BOX motion platform. Note that any changes made within the game when it is running will overwrite any changes made manually. How can I disable in-game support for LED device? The F1 game has native support for some of the basic features supported by some external LED devices, such as the Leo Bodnar SLI Pro and the Fanatec steering wheels. To avoid conflicts between Codemasters’ implementation and any third-party device managers on the PC platform it may be necessary to disable the native support. This is done using the following led_display flags in the hardware_settings_config.xml. The file is located here (after an initial boot of the game): ...\Documents\My Games\<game_folder>\hardwaresettings\hardware_settings_config.xml The flags to enabled/disable LED output are: <led_display fanatecNativeSupport="true" sliProNativeSupport="true" /> The sliProNativeSupport flag controls the output to SLI Pro devices. The fanatecNativeSupport flag controls the output to Fanatec (and some related) steering wheel LEDs. Set the values for any of these to “false” to disable them and avoid conflicts with your own device manager. Please note there is an additional flag to manually control the LED brightness on the SLI Pro: <led_display sliProForceBrightness="127" /> This option (using value in the range 0-255) will be ignored when setting the sliProNativeSupport flag to “false”. Also note it is now possible to edit these values on the fly via the Game Options->Settings->UDP Telemetry Settings menu. Can I configure the UDP output using an XML File? PC users can edit the game’s configuration XML file to configure UDP output. The file is located here (after an initial boot of the game): ...\Documents\My Games\<game_folder>\hardwaresettings\hardware_settings_config.xml You should see the tag: <motion> ... <udp enabled="false" broadcast=”false” ip="127.0.0.1" port="20777" sendRate=”20” format=”2020” yourTelemetry="restricted" /> ... </motion> Here you can set the values manually. Note that any changes made within the game when it is running will overwrite any changes made manually.

It's possible that the issue is related to framerate, where running very high fps in 1920 might be giving anomalous readings for some of the physics-based data. It's possible that clamping the frame rate will resolve this, although this will introduce potential undesirable changes in the handling. We are investigating this issue at the moment.