F1 2018 UDP Specification

[ReddishTheGreat]

Hoo said:

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.

@Hoo:

I tried to make this reproducible by restarting, trying various game modes, broadcasting vs unicasting, ..., but I haven't seen any re-occurrence of the phenomenon so far.

I will keep my UDP monitor program open from now on and will get back at you when I see this again. It really did look as if two threads were actively sending out game information packets, and they disagreed on sessionId, frameIndex, sessionTime, etc.

There was only a single instance of F1 2018 running on my LAN/computer at the time. Really does look like a rogue thread from where I stand (one that wasn't somehow ended from an earlier session, or something), I don't know if that is somehow plausible in the way the game implements UDP telemetry.

I also saw that the version was bumped to 1.0.5, I saw the phenomenon with version 1.0.4.

I still see that the first session packet (an Event packet) has the sessionUID of the previous session, if any, in the header. (The first session during a run of the game shows packets with sessionUID 0x0000000000000000). So something is amiss there, and this should be easy to reproduce.

By the way: A very useful feature would be to include the version of the game (eg 0x0104 or 0x0105) in the header. That way, us client developers have an opportunity to work around issues/quirks that depend on the specific version.

[Ho3n3r]

@Hoo Ride height values (in mm) is an integral part of racing telemetry, yet it's not part of what is exposed via UDP. Why is that? Do these values not exist?

[LetMeThrashU]

@Hoo there seems to be a typo in the PacketSessionData struct.

You have put

unint8          m_networkGame;              // 0 = offline, 1 = online

when you probably mean

unint8          m_networkGame;              // 0 = offline, 1 = online

Just thought I would let you know.

[Hoo]

LetMeThrashU said:

@Hoo there seems to be a typo in the PacketSessionData struct.

You have put

unint8          m_networkGame;              // 0 = offline, 1 = online

when you probably mean

uint8          m_networkGame;              // 0 = offline, 1 = online

Just thought I would let you know.

Fixed both typos. ;)

[mrbelowski]

regarding the m_buttonState element, as this is a 32bit uint, are there actually 32 possible 'pressed' buttons?

[LetMeThrashU]

@Hoo is it me, or does enabling broadcast mode create massive amounts of lag? Without broadcast, the data comes through ok. When on broadcast mode, there is a delay of a few seconds. Before, I thought it was the speed of the language and framework I was using, now I know its broadcast mode.

[cjorgens79]

mrbelowski said:

regarding the m_buttonState element, as this is a 32bit uint, are there actually 32 possible 'pressed' buttons?

The available buttons are listed on the first page of this thread after the team/driver id list

[cjorgens79]

LetMeThrashU said:

@Hoo is it me, or does enabling broadcast mode create massive amounts of lag? Without broadcast, the data comes through ok. When on broadcast mode, there is a delay of a few seconds. Before, I thought it was the speed of the language and framework I was using, now I know its broadcast mode.

Your router will be causing the lag. Broadcast packets are treated differently by the router than packets sent to a specific IP. Usually there will be a setting somewhere in the router to fix it, usually a setting related to UDP / multicast or broadcast flood, denial of service protection or something to that effect.

[MiguelRomeral1]

Hi Everyone. @Hoo

Sorry, I'm new developing an app telemetry. I could almost all data in the packets, but I don't know how to get the data for the car motion. I mean, I have the values for worldPosition, worldForwardDir and worldRightDir but I don't know how i should interpret them to print the cars on the track.

Thanks for your attention.

[trenamax]

Hi @Hoo -

Any update on whether we can either increase the frequency of the car status packet to the in-game setting, or, move items like m_drsAllowed and m_ersStoreEnergy to the car telemetery packet ?

Also, I've noticed an issue with m_drsAllowed. Whilst in a DRS zone, if I enable DRS and then disable it (whilst still in the drs zone), I see DRS allowed = 0 briefly, until I receive the next CarStatus packet where it goes back to 1. Of course this would not be a noticeable issue if the car status packet was sent at the frequency game setting, but currently it is noticeable.

Many thanks!

Mike

[LetMeThrashU]

cjorgens79 said:

LetMeThrashU said:

@Hoo is it me, or does enabling broadcast mode create massive amounts of lag? Without broadcast, the data comes through ok. When on broadcast mode, there is a delay of a few seconds. Before, I thought it was the speed of the language and framework I was using, now I know its broadcast mode.

Your router will be causing the lag. Broadcast packets are treated differently by the router than packets sent to a specific IP. Usually there will be a setting somewhere in the router to fix it, usually a setting related to UDP / multicast or broadcast flood, denial of service protection or something to that effect.

Thanks for that. Seems like a problem for me then. My BT Hub 5 doesn't seem to support that then.

[mrbelowski]

cjorgens79 said:

mrbelowski said:

regarding the m_buttonState element, as this is a 32bit uint, are there actually 32 possible 'pressed' buttons?

The available buttons are listed on the first page of this thread after the team/driver id list

yeah, i saw that but the bit masks make it look like the field is a 16bit int, not 32bit int. I was confused

[LetMeThrashU]

Who knows how to calculate the delta time between the driver in front and driver behind?

Edit: solved now!

[EnsiFerrum]

Hint:
LapData is an Array, so you need the the index of the player, the car ahead and the car behind.
f_DeltaFront = m_LapData[DriverFront] - m_LapData[PlayerIndex];

[LetMeThrashU]

EnsiFerrum said:

Hint:
LapData is an Array, so you need the the index of the player, the car ahead and the car behind.
f_DeltaFront = m_LapData[DriverFront] - m_LapData[PlayerIndex];

I know. All ready done that. I then tried doing time = distance/speed on the car in front and the player. I then subtracted both to get the difference. That didn’t work. 

[IJS84]

@Hoo

The issue with the network names still exists in 1.05. I've just got my database up and running neatly now and on the race I am spectating, the player called "Suspect-Jay86" is showing in the data as "Player -Jay86"

Is this something we can get sorted in the next patch? It's such a great benefit if it's working correctly

[Lopensky]

Working with this new data packets is waaaay easier and faster than before, and finally the bigger part of the last year's problems (ie no telemetry in spectator mode, no telemetry if paused, etc..) have been solved.

I also have to thank @Hoo for supporting my "petition" to make possible to hide the in-game left part of the hud while spectating, where live standings are.

Great job, really. ;)

Now it's time for me to work on it B)

[LetMeThrashU]

Lopensky said:

Working with this new data packets is waaaay easier and faster than before, and finally the bigger part of the last year's problems (ie no telemetry in spectator mode, no telemetry if paused, etc..) have been solved.

I also have to thank @Hoo for supporting my "petition" to make possible to hide the in-game left part of the hud while spectating, where live standings are.

Great job, really. ;)

Now it's time for me to work on it B)

This layout is also good in that we just have to receive and convert the data we want. Thanks @Hoo

[cjorgens79]

LetMeThrashU said:

cjorgens79 said:

LetMeThrashU said:

@Hoo is it me, or does enabling broadcast mode create massive amounts of lag? Without broadcast, the data comes through ok. When on broadcast mode, there is a delay of a few seconds. Before, I thought it was the speed of the language and framework I was using, now I know its broadcast mode.

Your router will be causing the lag. Broadcast packets are treated differently by the router than packets sent to a specific IP. Usually there will be a setting somewhere in the router to fix it, usually a setting related to UDP / multicast or broadcast flood, denial of service protection or something to that effect.

Thanks for that. Seems like a problem for me then. My BT Hub 5 doesn't seem to support that then.

Yeah BT Hubs are a pain. Try the following tip that I got from one of my users (for BT hub 6, but might work for 5)

"I finally managed to get RSDash working with BT Smarthub 6.  The approach also work with Virgin Media’s Superhub 3.0.  It’s really simple and doesn’t require port forwarding. All you have to do is set the PS4 with a static IP address which requires a manual network setup and then put that IP address as a DMZ on the router. 

​So for manual setup on PS4 you select your IP address within your routers IP range:

BT is 192.168.1.nnn

Virgin is 192.168.0.nnn

So select your IP address (making sure it’s not already assigned)

Eg 192.168.1.64

Subnet 255.255.255.0

Gateway and Primary DNS as per previous settings for BT both 192.168.1.254

On the BT router go to advanced settings >> Firewall >> Port Forwarding >> Configuration

Set DMZ to on and select the PS4 by IP address and save setting.

Similar menu options on Virginmedia. 

I’d restart the router and PS4 then you’re good to go.

[LetMeThrashU]

cjorgens79 said:

LetMeThrashU said:

cjorgens79 said:

LetMeThrashU said:

@Hoo is it me, or does enabling broadcast mode create massive amounts of lag? Without broadcast, the data comes through ok. When on broadcast mode, there is a delay of a few seconds. Before, I thought it was the speed of the language and framework I was using, now I know its broadcast mode.

Your router will be causing the lag. Broadcast packets are treated differently by the router than packets sent to a specific IP. Usually there will be a setting somewhere in the router to fix it, usually a setting related to UDP / multicast or broadcast flood, denial of service protection or something to that effect.

Thanks for that. Seems like a problem for me then. My BT Hub 5 doesn't seem to support that then.

Yeah BT Hubs are a pain. Try the following tip that I got from one of my users (for BT hub 6, but might work for 5)

"I finally managed to get RSDash working with BT Smarthub 6.  The approach also work with Virgin Media’s Superhub 3.0.  It’s really simple and doesn’t require port forwarding. All you have to do is set the PS4 with a static IP address which requires a manual network setup and then put that IP address as a DMZ on the router. 

​So for manual setup on PS4 you select your IP address within your routers IP range:

BT is 192.168.1.nnn

Virgin is 192.168.0.nnn

So select your IP address (making sure it’s not already assigned)

Eg 192.168.1.64

Subnet 255.255.255.0

Gateway and Primary DNS as per previous settings for BT both 192.168.1.254

On the BT router go to advanced settings >> Firewall >> Port Forwarding >> Configuration

Set DMZ to on and select the PS4 by IP address and save setting.

Similar menu options on Virginmedia. 

I’d restart the router and PS4 then you’re good to go.

Think I have been reading too much on North Korea. I read DMZ as DeMilitarisedZone. Haha. Thanks for the instructions, released I do have a Hub 6. I may try another time.

[DaveyGravy]

Think I have been reading too much on North Korea. I read DMZ as DeMilitarisedZone. Haha. Thanks for the instructions, released I do have a Hub 6. I may try another time.

That is what it stands for in networking too. It’s a segment of your network that is more trusted than the internet but less trusted than the LAN itself.

[Lopensky]

I'm working with this new packets and i'm facing some issues i wuold love to share with you guys hoping you can help me getting out of this troubles.

DriverIDs

While in single player mode they appear to work accordingly to the new defined identifiers, but in online mode i continue reading the ID "1" for one of mercedes drivers that has no sense, and make it really hard to work with. :s

Main problem is that i NEED to map the game drivers to real drivers in a db, and at the moment i do this using the driverId, which i suppose to be unique for each driver accordingly to the selected one. Making it clear with an example, if in an online lobby i choose to race using Bottas, i expect my data in the udp packets to be linked to the driver with teamId equal to "0" and driverId equal to "15".

Problem is that i find a driverId into ParticipantData packet that is equal to "1".. a value that - accordingly with the provided ref list - should not be present at all, never.

It's stranger since in offline it all works properly.

Broken data

Another problem i'm facing is this. It happens quite often to see the in-game app broke up with strange issues, like drivers struck in pit lane, no data at all, etc.. . When this happens, it seems  that UDP data related to all drivers go trough the same problems. Am i the only one having this problems? If yes, what to do? :#

[cjorgens79]

Lopensky said:

I'm working with this new packets and i'm facing some issues i wuold love to share with you guys hoping you can help me getting out of this troubles.

DriverIDs

While in single player mode they appear to work accordingly to the new defined identifiers, but in online mode i continue reading the ID "1" for one of mercedes drivers that has no sense, and make it really hard to work with. :s

Main problem is that i NEED to map the game drivers to real drivers in a db, and at the moment i do this using the driverId, which i suppose to be unique for each driver accordingly to the selected one. Making it clear with an example, if in an online lobby i choose to race using Bottas, i expect my data in the udp packets to be linked to the driver with teamId equal to "0" and driverId equal to "15".

Problem is that i find a driverId into ParticipantData packet that is equal to "1".. a value that - accordingly with the provided ref list - should not be present at all, never.

It's stranger since in offline it all works properly.

Broken data

Another problem i'm facing is this. It happens quite often to see the in-game app broke up with strange issues, like drivers struck in pit lane, no data at all, etc.. . When this happens, it seems  that UDP data related to all drivers go trough the same problems. Am i the only one having this problems? If yes, what to do? :#

I did a heap of multiplayer testing yesterday with v1.5 and all the timing stuff worked perfectly, including the team/driver ids. The telemetry perfectly matches what the game was telling me. 

Having said that, I am a PC user so I guess its possible there could be issues on the PS4 that aren't on the PC. Further to that, I have actually had reports of timing problems from one of my users who does a lot of testing for me, he is using a PS4. He is going to run a telemetry capture program to try and capture an instance of the issue he experienced, in which case I will be able to see if the problem is in the telemetry data itself or if its a problem with my app.

Given that you've said you are seeing weird data in the game itself, it does sound like a possible game issue to me. Personally I've not had any issues whatsoever with the PC version, so it may be platform specific.

[Lopensky]

@cjorgens79 

I took a look at the "old" discussion in the beta section about UDP Specification and found an image posted by you at page 7 where is clearly visible that there is a driver with ID 1.. really strange :s

@Hoo can you help with this? :/

[cjorgens79]

Lopensky said:

@cjorgens79 

I took a look at the "old" discussion in the beta section about UDP Specification and found an image posted by you at page 7 where is clearly visible that there is a driver with ID 1.. really strange :s

@Hoo can you help with this? :/

Fair point, I just checked the code and realised that I am not using the driverId field anymore now that the telemetry output includes the player's name in the data. So its quite possible that ID 1 (or other unlisted ID's) are being sent and I wouldn't have noticed.