Codemasters Staff Hoo Posted August 23, 2018 Codemasters Staff Share Posted August 23, 2018 OVERVIEW The F1 series of games support the outputting of key game data via a UDP data stream. This data can be interpreted by external apps or connected peripherals for a range of different uses, including providing additional telemetry information, customised HUD displays, motion platform hardware support or providing force feedback data for custom steering wheels. The following information is a summary of the data that is outputted so that developers of supporting hardware or software are able to configure these to work with the F1 game correctly. If the information you require is not contained here, or if you have any issues with the UDP data itself, then please let us know and a member of the dev team will respond to your query as soon as possible. Link to comment Share on other sites More sharing options...
Codemasters Staff Hoo Posted August 23, 2018 Author Codemasters Staff Share Posted August 23, 2018 PACKET TYPES The main change for 2018 is the introduction of multiple packet types: each packet can now carry different types of data rather than having one packet which contains everything. A header has been added to each packet as well so that versioning can be tracked and it will be easier for applications to check they are interpreting the incoming data in the correct way. Each packet has the following header: struct PacketHeader { uint16 m_packetFormat; // 2018 uint8 m_packetVersion; // Version of this packet type, all start from 1 uint8 m_packetId; // Identifier for the packet type, see below uint64 m_sessionUID; // Unique identifier for the session float m_sessionTime; // Session timestamp uint m_frameIdentifier; // Identifier for the frame the data was retrieved on uint8 m_playerCarIndex; // Index of player's car in the array }; Link to comment Share on other sites More sharing options...
Codemasters Staff Hoo Posted August 23, 2018 Author Codemasters Staff Share Posted August 23, 2018 MOTION PACKET The motion packet gives physics data for all the cars being driven. There is additional data for the car being driven with the goal of being able to drive a motion platform setup. N.B. For the normalised vectors below, to convert to float values divide by 32767.0f. 16-bit signed values are used to pack the data and on the assumption that direction values are always between -1.0f and 1.0f. Frequency: Rate as specified in menus Size: 1341 bytes struct CarMotionData { float m_worldPositionX; // World space X position float m_worldPositionY; // World space Y position float m_worldPositionZ; // World space Z position float m_worldVelocityX; // Velocity in world space X float m_worldVelocityY; // Velocity in world space Y float m_worldVelocityZ; // Velocity in world space Z int16 m_worldForwardDirX; // World space forward X direction (normalised) int16 m_worldForwardDirY; // World space forward Y direction (normalised) int16 m_worldForwardDirZ; // World space forward Z direction (normalised) int16 m_worldRightDirX; // World space right X direction (normalised) int16 m_worldRightDirY; // World space right Y direction (normalised) int16 m_worldRightDirZ; // World space right Z direction (normalised) float m_gForceLateral; // Lateral G-Force component float m_gForceLongitudinal; // Longitudinal G-Force component float m_gForceVertical; // Vertical G-Force component float m_yaw; // Yaw angle in radians float m_pitch; // Pitch angle in radians float m_roll; // Roll angle in radians }; struct PacketMotionData { PacketHeader m_header; // Header CarMotionData m_carMotionData[20]; // Data for all cars on track // Extra player car ONLY data float m_suspensionPosition[4]; // Note: All wheel arrays have the following order: float m_suspensionVelocity[4]; // RL, RR, FL, FR float m_suspensionAcceleration[4]; // RL, RR, FL, FR float m_wheelSpeed[4]; // Speed of each wheel float m_wheelSlip[4]; // Slip ratio for each wheel float m_localVelocityX; // Velocity in local space float m_localVelocityY; // Velocity in local space float m_localVelocityZ; // Velocity in local space float m_angularVelocityX; // Angular velocity x-component float m_angularVelocityY; // Angular velocity y-component float m_angularVelocityZ; // Angular velocity z-component float m_angularAccelerationX; // Angular velocity x-component float m_angularAccelerationY; // Angular velocity y-component float m_angularAccelerationZ; // Angular velocity z-component float m_frontWheelsAngle; // Current front wheels angle in radians }; SESSION PACKETThe session packet includes details about the current session in progress. Frequency: 2 per second Size: 147 bytes struct MarshalZone { float m_zoneStart; // Fraction (0..1) of way through the lap the marshal zone starts int8 m_zoneFlag; // -1 = invalid/unknown, 0 = none, 1 = green, 2 = blue, 3 = yellow, 4 = red }; struct PacketSessionData { PacketHeader m_header; // Header uint8 m_weather; // Weather - 0 = clear, 1 = light cloud, 2 = overcast // 3 = light rain, 4 = heavy rain, 5 = storm int8 m_trackTemperature; // Track temp. in degrees celsius int8 m_airTemperature; // Air temp. in degrees celsius uint8 m_totalLaps; // Total number of laps in this race uint16 m_trackLength; // Track length in metres uint8 m_sessionType; // 0 = unknown, 1 = P1, 2 = P2, 3 = P3, 4 = Short P // 5 = Q1, 6 = Q2, 7 = Q3, 8 = Short Q, 9 = OSQ // 10 = R, 11 = R2, 12 = Time Trial int8 m_trackId; // -1 for unknown, 0-21 for tracks, see appendix uint8 m_era; // Era, 0 = modern, 1 = classic uint16 m_sessionTimeLeft; // Time left in session in seconds uint16 m_sessionDuration; // Session duration in seconds uint8 m_pitSpeedLimit; // Pit speed limit in kilometres per hour uint8 m_gamePaused; // Whether the game is paused uint8 m_isSpectating; // Whether the player is spectating uint8 m_spectatorCarIndex; // Index of the car being spectated uint8 m_sliProNativeSupport; // SLI Pro support, 0 = inactive, 1 = active uint8 m_numMarshalZones; // Number of marshal zones to follow MarshalZone m_marshalZones[21]; // List of marshal zones – max 21 uint8 m_safetyCarStatus; // 0 = no safety car, 1 = full safety car // 2 = virtual safety car uint8 m_networkGame; // 0 = offline, 1 = online }; LAP DATA PACKETThe lap data packet gives details of all the cars in the session. Frequency: Rate as specified in menus Size: 841 bytesstruct LapData { float m_lastLapTime; // Last lap time in seconds float m_currentLapTime; // Current time around the lap in seconds float m_bestLapTime; // Best lap time of the session in seconds float m_sector1Time; // Sector 1 time in seconds float m_sector2Time; // Sector 2 time in seconds float m_lapDistance; // Distance vehicle is around current lap in metres – could // be negative if line hasn’t been crossed yet float m_totalDistance; // Total distance travelled in session in metres – could // be negative if line hasn’t been crossed yet float m_safetyCarDelta; // Delta in seconds for safety car uint8 m_carPosition; // Car race position uint8 m_currentLapNum; // Current lap number uint8 m_pitStatus; // 0 = none, 1 = pitting, 2 = in pit area uint8 m_sector; // 0 = sector1, 1 = sector2, 2 = sector3 uint8 m_currentLapInvalid; // Current lap invalid - 0 = valid, 1 = invalid uint8 m_penalties; // Accumulated time penalties in seconds to be added uint8 m_gridPosition; // Grid position the vehicle started the race in uint8 m_driverStatus; // Status of driver - 0 = in garage, 1 = flying lap // 2 = in lap, 3 = out lap, 4 = on track uint8 m_resultStatus; // Result status - 0 = invalid, 1 = inactive, 2 = active // 3 = finished, 4 = disqualified, 5 = not classified // 6 = retired }; struct PacketLapData { PacketHeader m_header; // Header LapData m_lapData[20]; // Lap data for all cars on track }; EVENT PACKETThis packet gives details of events that happen during the course of the race. Frequency: When the event occurs Size: 25 bytes struct PacketEventData { PacketHeader m_header; // Header uint8 m_eventStringCode[4]; // Event string code, see above }; PARTICIPANTS PACKETThis is a list of participants in the race. If the vehicle is controlled by AI, then the name will be the driver name. If this is a multiplayer game, the names will be the Steam Id on PC, or the LAN name if appropriate. On Xbox One, the names will always be the driver name, on PS4 the name will be the LAN name if playing a LAN game, otherwise it will be the driver name. Frequency: Every 5 seconds Size: 1082 bytes struct ParticipantData { uint8 m_aiControlled; // Whether the vehicle is AI (1) or Human (0) controlled uint8 m_driverId; // Driver id - see appendix uint8 m_teamId; // Team id - see appendix uint8 m_raceNumber; // Race number of the car uint8 m_nationality; // Nationality of the driver char m_name[48]; // Name of participant in UTF-8 format – null terminated // Will be truncated with … (U+2026) if too long }; struct PacketParticipantsData { PacketHeader m_header; // Header uint8 m_numCars; // Number of cars in the data ParticipantData m_participants[20]; }; CAR SETUPS PACKETThis packet details the car setups for each vehicle in the session. Note that in multiplayer games, other player cars will appear as blank, you will only be able to see your car setup and AI cars. Frequency: Every 5 seconds Size: 841 bytes struct CarSetupData { uint8 m_frontWing; // Front wing aero uint8 m_rearWing; // Rear wing aero uint8 m_onThrottle; // Differential adjustment on throttle (percentage) uint8 m_offThrottle; // Differential adjustment off throttle (percentage) float m_frontCamber; // Front camber angle (suspension geometry) float m_rearCamber; // Rear camber angle (suspension geometry) float m_frontToe; // Front toe angle (suspension geometry) float m_rearToe; // Rear toe angle (suspension geometry) uint8 m_frontSuspension; // Front suspension uint8 m_rearSuspension; // Rear suspension uint8 m_frontAntiRollBar; // Front anti-roll bar uint8 m_rearAntiRollBar; // Front anti-roll bar uint8 m_frontSuspensionHeight; // Front ride height uint8 m_rearSuspensionHeight; // Rear ride height uint8 m_brakePressure; // Brake pressure (percentage) uint8 m_brakeBias; // Brake bias (percentage) float m_frontTyrePressure; // Front tyre pressure (PSI) float m_rearTyrePressure; // Rear tyre pressure (PSI) uint8 m_ballast; // Ballast float m_fuelLoad; // Fuel load }; struct PacketCarSetupData { PacketHeader m_header; // Header CarSetupData m_carSetups[20]; }; CAR TELEMETRY PACKETThis packet details telemetry for all the cars in the race. It details various values that would be recorded on the car such as speed, throttle application, DRS etc. Frequency: Rate as specified in menus Size: 1085 bytes struct CarTelemetryData { uint16 m_speed; // Speed of car in kilometres per hour uint8 m_throttle; // Amount of throttle applied (0 to 100) int8 m_steer; // Steering (-100 (full lock left) to 100 (full lock right)) uint8 m_brake; // Amount of brake applied (0 to 100) uint8 m_clutch; // Amount of clutch applied (0 to 100) int8 m_gear; // Gear selected (1-8, N=0, R=-1) uint16 m_engineRPM; // Engine RPM uint8 m_drs; // 0 = off, 1 = on uint8 m_revLightsPercent; // Rev lights indicator (percentage) uint16 m_brakesTemperature[4]; // Brakes temperature (celsius) uint16 m_tyresSurfaceTemperature[4]; // Tyres surface temperature (celsius) uint16 m_tyresInnerTemperature[4]; // Tyres inner temperature (celsius) uint16 m_engineTemperature; // Engine temperature (celsius) float m_tyresPressure[4]; // Tyres pressure (PSI) }; struct PacketCarTelemetryData { PacketHeader m_header; // Header CarTelemetryData m_carTelemetryData[20]; uint32 m_buttonStatus; // Bit flags specifying which buttons are being // pressed currently - see appendices }; CAR STATUS PACKETThis packet details car statuses for all the cars in the race. It includes values such as the damage readings on the car. Frequency: 2 per second Size: 1061 bytesstruct CarStatusData { uint8 m_tractionControl; // 0 (off) - 2 (high) uint8 m_antiLockBrakes; // 0 (off) - 1 (on) uint8 m_fuelMix; // Fuel mix - 0 = lean, 1 = standard, 2 = rich, 3 = max uint8 m_frontBrakeBias; // Front brake bias (percentage) uint8 m_pitLimiterStatus; // Pit limiter status - 0 = off, 1 = on float m_fuelInTank; // Current fuel mass float m_fuelCapacity; // Fuel capacity uint16 m_maxRPM; // Cars max RPM, point of rev limiter uint16 m_idleRPM; // Cars idle RPM uint8 m_maxGears; // Maximum number of gears uint8 m_drsAllowed; // 0 = not allowed, 1 = allowed, -1 = unknown uint8 m_tyresWear[4]; // Tyre wear percentage uint8 m_tyreCompound; // Modern - 0 = hyper soft, 1 = ultra soft // 2 = super soft, 3 = soft, 4 = medium, 5 = hard // 6 = super hard, 7 = inter, 8 = wet // Classic - 0-6 = dry, 7-8 = wet uint8 m_tyresDamage[4]; // Tyre damage (percentage) uint8 m_frontLeftWingDamage; // Front left wing damage (percentage) uint8 m_frontRightWingDamage; // Front right wing damage (percentage) uint8 m_rearWingDamage; // Rear wing damage (percentage) uint8 m_engineDamage; // Engine damage (percentage) uint8 m_gearBoxDamage; // Gear box damage (percentage) uint8 m_exhaustDamage; // Exhaust damage (percentage) int8 m_vehicleFiaFlags; // -1 = invalid/unknown, 0 = none, 1 = green // 2 = blue, 3 = yellow, 4 = red float m_ersStoreEnergy; // ERS energy store in Joules uint8 m_ersDeployMode; // ERS deployment mode, 0 = none, 1 = low, 2 = medium // 3 = high, 4 = overtake, 5 = hotlap float m_ersHarvestedThisLapMGUK; // ERS energy harvested this lap by MGU-K float m_ersHarvestedThisLapMGUH; // ERS energy harvested this lap by MGU-H float m_ersDeployedThisLap; // ERS energy deployed this lap }; struct PacketCarStatusData { PacketHeader m_header; // Header CarStatusData m_carStatusData[20]; }; Link to comment Share on other sites More sharing options...
Codemasters Staff Hoo Posted August 23, 2018 Author Codemasters Staff Share Posted August 23, 2018 Appendices for the various IDs used in the UDP output: (Hoo: IDs have been updated on 10th Sept 2018 as several of them were missing) Link to comment Share on other sites More sharing options...
Codemasters Staff Hoo Posted August 23, 2018 Author Codemasters Staff Share Posted August 23, 2018 FAQS How do I enable the UDP Telemetry Output?In F1 2018, UDP telemetry output is controlled via the 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. 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=”2018” /> ... </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. 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. Is the data packed? Yes, all data is packed. Will my F1 2017 app still work with F1 2018? F1 2018 uses a new format for the UDP data. However, the F1 2017 implementation is still supported by the game and is referred to as the “legacy” format. This should allow most apps implemented using the previous data format to work with little or no change from the developer. To use the old format, please enter the UDP options menu and set “UDP Format” to “legacy”. Specifications for the legacy format can be seen here: http://forums.codemasters.com/discussion/53139/f1-2017-d-box-and-udp-output-specification/p1. How do I enable D-BOX output?D-BOX output is currently supported on the PC platform. In F1 2018, 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. Link to comment Share on other sites More sharing options...
Alex35zombi Posted August 23, 2018 Share Posted August 23, 2018 I have one question is the data streamed on replay mode and spectator? Link to comment Share on other sites More sharing options...
gaetanomatonti Posted August 23, 2018 Share Posted August 23, 2018 Wow that's a big load of data being transmitted, good job! Link to comment Share on other sites More sharing options...
Codemasters Staff Hoo Posted August 24, 2018 Author Codemasters Staff Share Posted August 24, 2018 Alex35zombi said: I have one question is the data streamed on replay mode and spectator? Yes. :) Let us know if encounter any problems with this. Link to comment Share on other sites More sharing options...
carlucio24 Posted August 24, 2018 Share Posted August 24, 2018 Hi, great job with this new telemetry protocol.What are MarshalZones ? Link to comment Share on other sites More sharing options...
trenamax Posted August 24, 2018 Share Posted August 24, 2018 Hi Hoo -I wish I'd spotted this issue during the Beta so apologies about that. I play the game with fully functional replica F1 wheels (see here: https://www.youtube.com/watch?v=hrq2cmSdp04). I have an LED which illuminated when DRS is allowed, and an additional one which illuminates when DRS is active.I've noticed whilst playing this evening there seems to be a delay in the DRS Legal LED illuminating when entering a DRS zone, and now I realise it's because m_drsAllowed is in the Car Status packet (only sent twice a second), whereas m_drs is in the Car Telemetery Data packet (sent at game setting which is 60hz in my case). My DRS LED works instantly I should add. Both worked perfectly in F1 2015-2017.Is there any chance we can move m_drsAllowed into the Car Telemetery Data packet so it's sent at a descent rate please? It seems like the two should be sent in the same packet.Many thanks, and loving the full version of the game :)Mike Link to comment Share on other sites More sharing options...
LonelyRacer Posted August 26, 2018 Share Posted August 26, 2018 Hoo said: CAR TELEMETRY PACKETThis packet details telemetry for all the cars in the race. It details various values that would be recorded on the car such as speed, throttle application, DRS etc. Frequency: Rate as specified in menus Size: 1085 bytes struct CarTelemetryData { uint16 m_speed; // Speed of car in kilometres per hour uint8 m_throttle; // Amount of throttle applied (0 to 100) int8 m_steer; // Steering (-100 (full lock left) to 100 (full lock right)) uint8 m_brake; // Amount of brake applied (0 to 100) uint8 m_clutch; // Amount of clutch applied (0 to 100) int8 m_gear; // Gear selected (1-8, N=0, R=-1) uint16 m_engineRPM; // Engine RPM uint8 m_drs; // 0 = off, 1 = on uint8 m_revLightsPercent; // Rev lights indicator (percentage) uint16 m_brakesTemperature[4]; // Brakes temperature (celsius) uint16 m_tyresSurfaceTemperature[4]; // Tyres surface temperature (celsius) uint16 m_tyresInnerTemperature[4]; // Tyres inner temperature (celsius) uint16 m_engineTemperature; // Engine temperature (celsius) float m_tyresPressure[4]; // Tyres pressure (PSI) }; Thank you for the data.Been converting my Telemetry Tool to accept the new data. I haven't looked into the data too deeply yet, but will do that during the coming days.Classic driversOne note. When you do the race in Classic era, there are drivers (e.g. m_driverId 41), which are not listed in the table above. Any change to send the updated list here?Speed etc in Floats instead of Ints?Would it be possible to provide the m_speed, m_throttle, m_steer and m_brake as floats instead of ints? It would only add few bytes to the CarTelemetryData, but for people doing the telemetry for Wheel users, the more granular data would be super helpful.Thanks. Link to comment Share on other sites More sharing options...
EnsiFerrum Posted August 27, 2018 Share Posted August 27, 2018 Found a bug: ParticipantData.m_teamId returns 35, no matter in which historic car I am.Tested in Time-Trial mode. This makes any per car setting useless.Edit: It occurs only in Time Trial mode. After a quick look in my notes I can say we had this bug already in F1-2017. Never got fixed. Hope it will be adressed in the next patch, please. Link to comment Share on other sites More sharing options...
cjorgens79 Posted August 28, 2018 Share Posted August 28, 2018 @Hoo - what is the difference between m_tyresWear and m_tyresDamage in the Car Status packet? From what i can tell they always seem to have the exact same value. I thought that perhaps m_tyresDamage was related to the suspension or rim damage, however it just seems to be the same as the tyre wear percentage. Link to comment Share on other sites More sharing options...
cjorgens79 Posted August 28, 2018 Share Posted August 28, 2018 There appears to be some issues with the timing data for Time Trial, it seems to contain data for a number of additional non-existant players. The m_numCars is 1, however there are multiple entries in the lap data record that appear to be active. They show as lap 1, position 1 and for all intensive purposes appear to be an active player (albeit with overlapping race positions). They even have valid x/y/z world co-ordinates. At the moment I have had to work around it by doing a check for m_numCars = 1, in which case i know there is only the "player", so i can use the m_playerCarIndex to make sure i grab the right entry, as they all overlap each other in terms of their result (race position). Link to comment Share on other sites More sharing options...
ReddishTheGreat Posted August 28, 2018 Share Posted August 28, 2018 Is there any chance we can move m_drsAllowed into the Car Telemetery Data packet so it's sent at a descent rate please? It seems like the two should be sent in the same packet. A possible alternative would be to change the m_drs field in the Car Telemetry Packet to be a bitfield: 0 == no DRS allowed; 2 == DRS allowed but inactive; 3 == DRS allowed and active.(We should never see 1, normally -- well perhaps if there is a 'DRS stuck open' fault mode). Link to comment Share on other sites More sharing options...
ReddishTheGreat Posted August 28, 2018 Share Posted August 28, 2018 Bug report (F1 2018 TELEMETRY): At the beginning of a new session, some UDP packets are transmitted with the sessionUID field set to the previous session's UID. In the first session after starting the game, a few packets with sessionUID equal to zero are transmitted.Seems that the sessionUID field is set after enabling UDP telemetry, where it should be set before. So this may well be easy to fix. EDIT: bug reported as top-level post, see: http://forums.codemasters.com/discussion/138130/bug-f1-2018-pc-v1-0-4-udp-telemetry-bad-session-uid-in-first-few-packets-of-a-session Link to comment Share on other sites More sharing options...
ReddishTheGreat Posted August 28, 2018 Share Posted August 28, 2018 Suggested improvement to telemetry:It would be very useful to get a telemetry value for terrain type (perhaps one per wheel, perhaps one for the car center). It could be as simple as an enumeration: 0==ASPHALT, 1==CURB, 2==GRASS, 3==GRAVEL. Link to comment Share on other sites More sharing options...
willgarling Posted August 28, 2018 Share Posted August 28, 2018 Can anyone tell me which platforms would be compatible with this game? Link to comment Share on other sites More sharing options...
HassanKLD Posted August 30, 2018 Share Posted August 30, 2018 Hello!Firstly thanks for posting this @Hoo. I'm currently creating something for myself, but found the forum a little tedious to keep coming back to for the info, so I created a quick reference doc for myself. Others might find it useful. Link here. It's not fully complete I still need to port of the full appendices. @Hoo If you or anyone at Codemasters would like to take ownership of this I'm more than happy to. It's just a github repo, and the docs are written in Markdown and auto generated.Ok so on the actual UDP spec side, I picked up a few things and just wanted to clarify/point few things out.the buffer size for Motion packet is 1341 Bytes, after accounting for everything in the structs I get a total of 1221 Bytes. Is this correct? If so whats in the remaining 120 Bytes? anything useful or can it be simply ignored.The m_eventStringCode in the PacketEventData Struct are mentioned to be UInt8[4], but in the table below it shows code as 'SSTA' and 'SEND'. is the UInt8 an error as they should be CharsI agree with @trenamax to move the m_drsAllowed to the carTelemetryPacketI would really like to have the track limits in the data stream, maybe m_trackLimitLeft and m_tackLimitRight maybe on the MotionData Packet. Edit: thinking more about this, I think it would be useful to get the world x,y, z of the left and right limitthanks! Hass Link to comment Share on other sites More sharing options...
trenamax Posted August 30, 2018 Share Posted August 30, 2018 Hi @HassanKLD -I wrote an app during the beta, and can confirm that the motion data packet does indeed total to 1341 bytes all used. So you must have missed something somewhere.You might find this mapping spreadsheet I put together useful:https://btcloud.bt.com/web/app/share/invite/cCKudhtU11Pleased you agree about DRS Legal moving to the car telemetry packet, its really noticeable for me whilst driving. Link to comment Share on other sites More sharing options...
HassanKLD Posted August 30, 2018 Share Posted August 30, 2018 Hi @trenamax Thanks for that spreadsheet, that helped. You are correct, was missing all the m_worldRgihtDirection entries in my app. Link to comment Share on other sites More sharing options...
Alex35zombi Posted August 30, 2018 Share Posted August 30, 2018 I'm using C# and my UDPClient is only able to access to the bytes from the PacketCarTelemetryData, any way I could make my client to receive the bytes from all structures?UdpClient client = new UdpClient(20777); IPEndPoint ep = new IPEndPoint(IPAddress.Any, 0); void UpdateData() { while (true) { byte[] arr = client.Receive(ref ep); Console.WriteLine(arr.Length.ToString()); // Output: 1085 (PacketCarTelemetryData byte size) } } Link to comment Share on other sites More sharing options...
LetMeThrashU Posted August 30, 2018 Share Posted August 30, 2018 What is the total value that the ERS battery can store and harvest? Looking at the rules, the MGU-K can recover unto 2MJ/lap and the MGU-H is unlimited. What values do the steering wheels in your game use for max harvest and total energy? Link to comment Share on other sites More sharing options...
Drospy Posted August 30, 2018 Share Posted August 30, 2018 Hi all,please Codemaster change the frequency for "Car Status Packet", 2 second is too high.m_drsAllowed, m_vehicleFiaFlags, m_pitLimiterStatus and m_fuelMix are very important. Link to comment Share on other sites More sharing options...
EnsiFerrum Posted August 30, 2018 Share Posted August 30, 2018 LetMeThrashU said: What is the total value that the ERS battery can store and harvest? Looking at the rules, the MGU-K can recover unto 2MJ/lap and the MGU-H is unlimited. What values do the steering wheels in your game use for max harvest and total energy? Battery is 4MJHarvest is 2MJ Link to comment Share on other sites More sharing options...
IJS84 Posted August 30, 2018 Share Posted August 30, 2018 Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)@Hoo Link to comment Share on other sites More sharing options...
fierogt4 Posted August 31, 2018 Share Posted August 31, 2018 how are you doing to put f1 2017 profile to f1 2018 for next level racing platform Link to comment Share on other sites More sharing options...
Son4R Posted August 31, 2018 Share Posted August 31, 2018 IJS84 said: Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)@Hoo I'm receiving the correct AI names in career, and online I receive "Player" everyone.Wondering if I am doing something wrong. Link to comment Share on other sites More sharing options...
LetMeThrashU Posted August 31, 2018 Share Posted August 31, 2018 Son4R said: IJS84 said: Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)@Hoo I'm receiving the correct AI names in career, and online I receive "Player" everyone.Wondering if I am doing something wrong. Do you have some code to show so that we can tell if there is an error? If you have a StackOverflow account, feel free to create a post there and link it here. Link to comment Share on other sites More sharing options...
LonelyRacer Posted August 31, 2018 Share Posted August 31, 2018 Son4R said: IJS84 said: Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)@Hoo I'm receiving the correct AI names in career, and online I receive "Player" everyone.Wondering if I am doing something wrong. Well, at least last year Hoo said that because of the privacy rules, they cannot push the player names to the UDP stream. I don't know if that has changed for this year. Link to comment Share on other sites More sharing options...
sonder774 Posted August 31, 2018 Share Posted August 31, 2018 Why is broadcast mode blatantly broken in both F1 2017 and F1 2018?Am I misunderstanding something? It's supposed to allow multiple apps to listen/connect to the UDP port. Never have gotten it to work.. There's a 3rd party program written specfically for this issue, and F1 2018 is still bugged? Mates... Fernando is faster than you. Link to comment Share on other sites More sharing options...
IJS84 Posted August 31, 2018 Share Posted August 31, 2018 LonelyRacer said: Son4R said: IJS84 said: Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)@Hoo I'm receiving the correct AI names in career, and online I receive "Player" everyone.Wondering if I am doing something wrong. Well, at least last year Hoo said that because of the privacy rules, they cannot push the player names to the UDP stream. I don't know if that has changed for this year. Yeah for PS4 it does transmit the name - just seems to replace the first 7 characters with 'Player[null]', and the spec says it's LAN names for ps4 online sessions Link to comment Share on other sites More sharing options...
SimShaker Posted September 1, 2018 Share Posted September 1, 2018 Hi guys,I'm trying to use m_gForceLongitudinal (Longitudinal G-Force component) data, capturing it from 2018 format Motion type packets, but getting multiple drop-outs to zero level as you can see on the screenshot attached. To compare, m_yaw (Yaw angle in radians) values coming in the same packets seem to be unbroken. Couldn't see such a problems with a Legacy telemetry format. Any suggestions? Link to comment Share on other sites More sharing options...
mrdezibel Posted September 2, 2018 Share Posted September 2, 2018 can someone please test if this still works, in legacy mode?https://play.google.com/store/apps/details?id=b4a.f1displayi have users telling me its Buggy and "shifting" the data…but i am not sure if they using it with the right gamesettings…any idea how to avoid the app showing data from the "wrong" mode ?is the first value of f1 2018 always the beginning of the header with m_packetFormat saying 2018?could be a way to differentiate the modes.. Link to comment Share on other sites More sharing options...
Son4R Posted September 2, 2018 Share Posted September 2, 2018 IJS84 said: Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)@Hoo You're correct. I've done some changes to my code, and I now receive Player 37 (name is SonaR1337).I seriously hope this isn't done intentionally like @LonelyRacer says, since this is the only way I can link users on my website to the data. Link to comment Share on other sites More sharing options...
LetMeThrashU Posted September 2, 2018 Share Posted September 2, 2018 @Hoo The CarStatus packet is also too slow for the ERS charge. Link to comment Share on other sites More sharing options...
ReddishTheGreat Posted September 3, 2018 Share Posted September 3, 2018 sonder774 said: Why is broadcast mode blatantly broken in both F1 2017 and F1 2018?Am I misunderstanding something? It's supposed to allow multiple apps to listen/connect to the UDP port. Never have gotten it to work.. There's a 3rd party program written specfically for this issue, and F1 2018 is still bugged? Mates... Fernando is faster than you. You are putting the blame at the wrong side. The game does proper UDP broadcasting. It's the receiving programs that are sloppy. Receiving programs need to indicate to the operating system's network stack that the port they use for UDP reception may be reused by other programs, (i.e., that they don't claim the port on the computer for exclusive use). The way they should do that is to call ... setsockopt(socket, SO_REUSEADDR, 1); ... before executing bind(), assuming they are running on Windows. If they don't, bind()ing multiple sockets to the same UDP port will fail on their side, after the first program claims the port. A good explanation on how this works can be found here: https://stackoverflow.com/questions/14388706. You should really not be pointing fingers without an understanding of the technical issues. EDIT: fixed stack overflow URL Link to comment Share on other sites More sharing options...
ReddishTheGreat Posted September 3, 2018 Share Posted September 3, 2018 Does anyone else see really strange behavior while monitoring the stream of incoming UDP packets?At the start of a session, I see two Event Start ("SSTA") packets, and at the end I see two Event Stop ("SSTO") packets. Also, I sometimes see short periods where alternating streams of UDP packets arrive with different sessionUID fields, and with different 'frameIndex' fields.It looks to me as if there are multiple threads running inside the game that broadcast UDP info which are not properly terminated or synchronised. It's quite a mess. Link to comment Share on other sites More sharing options...
Codemasters Staff Hoo Posted September 3, 2018 Author Codemasters Staff Share Posted September 3, 2018 LetMeThrashU said: What is the total value that the ERS battery can store and harvest? Looking at the rules, the MGU-K can recover unto 2MJ/lap and the MGU-H is unlimited. What values do the steering wheels in your game use for max harvest and total energy? I believe the max deployment per lap is 4MJ. Link to comment Share on other sites More sharing options...
Codemasters Staff Hoo Posted September 3, 2018 Author Codemasters Staff Share Posted September 3, 2018 ReddishTheGreat said: Does anyone else see really strange behavior while monitoring the stream of incoming UDP packets?At the start of a session, I see two Event Start ("SSTA") packets, and at the end I see two Event Stop ("SSTO") packets. Also, I sometimes see short periods where alternating streams of UDP packets arrive with different sessionUID fields, and with different 'frameIndex' fields.It looks to me as if there are multiple threads running inside the game that broadcast UDP info which are not properly terminated or synchronised. It's quite a mess. Please can you confirm what game mode you are running and whether you are using broadcast mode and we'll see if we can repeat the issue that you are seeing? Thanks. Link to comment Share on other sites More sharing options...
LetMeThrashU Posted September 3, 2018 Share Posted September 3, 2018 Ignore me, figured it out. Link to comment Share on other sites More sharing options...
SimShaker Posted September 3, 2018 Share Posted September 3, 2018 ReddishTheGreat said: setsockopt(socket, SO_REUSEADDR, 1); ... before executing bind(), assuming they are running on Windows. If they don't, bind()ing multiple sockets to the same UDP port will fail on their side, after the first program claims the port. A good explanation on how this works can be found here: https://stackoverflow.com/questions/14388706. You should really not be pointing fingers without an understanding of the technical issues. The explanation link seems to be broken... Link to comment Share on other sites More sharing options...
Codemasters Staff Hoo Posted September 3, 2018 Author Codemasters Staff Share Posted September 3, 2018 sonder774 said: Why is broadcast mode blatantly broken in both F1 2017 and F1 2018?Am I misunderstanding something? It's supposed to allow multiple apps to listen/connect to the UDP port. Never have gotten it to work.. There's a 3rd party program written specfically for this issue, and F1 2018 is still bugged? Mates... Fernando is faster than you. Broadcast mode transmits data to the subnet that the game is connected to. Any listening app on the same subnet should be able to read the data. It should not require a specific IP/port to work. There was a bug in the original 2017 UDP implementation where specifying an IP would stop the broadcast feature working correctly, but that has since been fixed. Link to comment Share on other sites More sharing options...
Codemasters Staff Hoo Posted September 3, 2018 Author Codemasters Staff Share Posted September 3, 2018 SimShaker said: Hi guys,I'm trying to use m_gForceLongitudinal (Longitudinal G-Force component) data, capturing it from 2018 format Motion type packets, but getting multiple drop-outs to zero level as you can see on the screenshot attached. To compare, m_yaw (Yaw angle in radians) values coming in the same packets seem to be unbroken. Couldn't see such a problems with a Legacy telemetry format. Any suggestions? Does the frequency of the packet updates affect the results that you are seeing? If you have a similar graph for the 2017 format that gives different results then that would be very interesting to see. Link to comment Share on other sites More sharing options...
Alex35zombi Posted September 3, 2018 Share Posted September 3, 2018 The player in carrer mode has the ID 1, why it isn't specified in the documentation? Link to comment Share on other sites More sharing options...
evian004 Posted September 3, 2018 Share Posted September 3, 2018 Hello guys,i'm new to this but I want to play a little bit bit the data to make an app. Are there any good tutorials how you can start with it because I don't know what language you should use to read the data and convert it to the structure that is given.Thanks in advance Link to comment Share on other sites More sharing options...
SimShaker Posted September 3, 2018 Share Posted September 3, 2018 Hoo said: SimShaker said: Hi guys,I'm trying to use m_gForceLongitudinal (Longitudinal G-Force component) data, capturing it from 2018 format Motion type packets, but getting multiple drop-outs to zero level as you can see on the screenshot attached. To compare, m_yaw (Yaw angle in radians) values coming in the same packets seem to be unbroken. Couldn't see such a problems with a Legacy telemetry format. Any suggestions? Does the frequency of the packet updates affect the results that you are seeing? If you have a similar graph for the 2017 format that gives different results then that would be very interesting to see. I tried 60 Hz and 20 Hz, couldn't see any difference. Currently 20Hz is set.In 2017 telemetry format it looks different. There is a couple of kind of drop-outs (I mean first two from the left), but their are not absolute zeros as that with 2018 format, just very small numbers. Link to comment Share on other sites More sharing options...
LetMeThrashU Posted September 3, 2018 Share Posted September 3, 2018 Whats the difference between tyresWear and tyresDamage? Tyres damage shows 8%, 7% 11% and 10%. This is what I thought tyresWear was. Tyres wear just shows all values as 0%. Link to comment Share on other sites More sharing options...
Son4R Posted September 3, 2018 Share Posted September 3, 2018 Son4R said: IJS84 said: Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)@Hoo You're correct. I've done some changes to my code, and I now receive Player 37 (name is SonaR1337).I seriously hope this isn't done intentionally like @LonelyRacer says, since this is the only way I can link users on my website to the data. @hoo could you take a look at this? Would like to know if this is intentionally or not, so I could start working around this. Link to comment Share on other sites More sharing options...
ReddishTheGreat Posted September 4, 2018 Share Posted September 4, 2018 SimShaker said: The explanation link seems to be broken... Fixed it, thanks for pointing that out. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.