Jump to content Jump to content

F1 2021 UDP Specification


BarryBL
 Share

Recommended Posts

17 minutes ago, Hoo said:

Hi @Lopensky - we already proposed this solution but it was rejected as the algorithm could be simple to reverse-engineer against known gamertags. 😞 

Just a thought… but now Codemasters own SMS, and the PCARS games send gamer tags in the telemetry, can your legal eagles not talk to their legal eagles and see what they did/why it was OK for them? 

It’s just a crying shame and a glaring omission - I hear from so many racers, especially league drivers about the lack of names, and all I can do is shrug and blame the game. 🤷‍♂️

Link to comment
Share on other sites

8 hours ago, Hoo said:

Hi @Lopensky - we already proposed this solution but it was rejected as the algorithm could be simple to reverse-engineer against known gamertags. 😞 

Using a salted hash as is standard for secure storage of passwords is not reversible, then b64 or hex it so its displayable. There would need to be considerations though as to the length of the resulting hash string to ensure it fits in the allocated space for driver names. 

  • Agree 3
Link to comment
Share on other sites

17 hours ago, Hamdor said:

The table in chapter "Packet Types" in incomplete in the current version of the docx. The double type is missing which is used in "FinalClassificationData" now.

What did I miss ? Was there a change to the data format ?

This is why i wanted the spec here in plain text in the post, so we can easily see what's changed by looking at the edit dates rather than having to search through a proprietary format file 😡

Link to comment
Share on other sites

12 minutes ago, AndyHamp said:

What did I miss ? Was there a change to the data format ?

This is why i wanted the spec here in plain text in the post, so we can easily see what's changed by looking at the edit dates rather than having to search through a proprietary format file 😡

There is no change. The m_totalRaceTime was double in F1 2020's PacketFinalClassificationData packets, as it is now and both packets have same size in F1 2020 and F1 2021.

So if your code around that packet worked last year, it will work this year.

If you are new developer and don't know how many bytes is a double, you might want to do some studying/research. For the Integers the size + unsigned/signed is critical, for double there is only one size, but if you do the conversion by hand, you must take into account endianness.

@HooMaybe you need to add the double's size info to the docs too. ;-).

Cheers.

Link to comment
Share on other sites

In the 2019 game the SEND event was always the last data packet from a session.

In 2021 (Don't know about 2020, maybe it was the same there) we now see Session History and Final Classification messages AFTER the SEND event

How are people determining when there's no more data to be received ? In my existing code i use the STRT and SEND as the delimiters for the data i'm saving for analysis etc and for determining when i can clean up internal state. But if i use SEND i might be missing useful data that can come many seconds after the SEND

Is the SEND not being the last packet sent a bug @Hoo ?

 

Link to comment
Share on other sites

15 minutes ago, LonelyRacer said:

There is no change. The m_totalRaceTime was double in F1 2020's PacketFinalClassificationData packets, as it is now and both packets have same size in F1 2020 and F1 2021.

So if your code around that packet worked last year, it will work this year.

If you are new developer and don't know how many bytes is a double, you might want to do some studying/research. For the Integers the size + unsigned/signed is critical, for double there is only one size, but if you do the conversion by hand, you must take into account endianness.

@HooMaybe you need to add the double's size info to the docs too. ;-).

Cheers.

I was confused by @Hamdor's post... I couldn't see any changes from the doc i originally downloaded or in the data so wonder what he was posing about. If it was a difference to the 2020 format then i'd not have seen it as i never added 2020 support in my code

Link to comment
Share on other sites

1 hour ago, AndyHamp said:

In the 2019 game the SEND event was always the last data packet from a session.

In 2021 (Don't know about 2020, maybe it was the same there) we now see Session History and Final Classification messages AFTER the SEND event

How are people determining when there's no more data to be received ? In my existing code i use the STRT and SEND as the delimiters for the data i'm saving for analysis etc and for determining when i can clean up internal state. But if i use SEND i might be missing useful data that can come many seconds after the SEND

Is the SEND not being the last packet sent a bug @Hoo ?

 

Already in 2020 there is that behaviour, I think that is expected. So SEND marks that "racing" time of session is done and then when results screen comes on we get Final Classification packet. Best way to use that packet as delimiter.

Link to comment
Share on other sites

2 minutes ago, mfivnismo said:

How do I run multiple udp ports as I have a motion rig running Sim Racing Studio and a Grid Engineering Display running simhub?

You either enable the UDP Broadcast option in the game or your app needs to act as a proxy and forward the UDP packets to your other device(s)

Link to comment
Share on other sites

Looks like there might be a bug regarding broadcast mode not working correctly. I’ve had several reports of broadcast mode not actually broadcasting, and instead doing a standard unicast to the previously entered IP address, even though that field is disabled when broadcast mode is on. I’ve tested this on PS5 and I don’t get the issue, everything works as expected. All of the users that reported the bug so far have been on Xbox Series X which may or may not be relevant. Anyone else seen this issue, on any platform?

  • Agree 1
Link to comment
Share on other sites

On 7/16/2021 at 8:12 PM, SimRacingStudio said:

One of our customers found a very annoying bug, that we will need your help to be addressed with the EA/codemasters developers.

 

Check out this video, left side is the SRS showing the telemetry that is receiving from F12021 and right side is the F12021 in the menu:

https://photos.google.com/share/AF1QipMGg-fnEguBQEtcYFFFMoTqAaF1nUJcPHSm58yq0X7vQdb7IZv6h8vp5CgMGa2dHA?key=VXl0S05YNFFvUDBLZ2Y2WVhpTHp5ak8zaVJfcExR

 

Every time I change the menu, the F12021 is sending the telemetry for about 1 second.

This did not happen in any previous version of F1 games, all the way up to F12011.

 

It's major issue for Motion platform users, every time it switches the menu, it goes from the 0 position, all the way to where the car was when you pressed pause, it sends you to the roof literally.

 

 

On 7/16/2021 at 10:17 PM, EnsiFerrum said:

Can confirm, have the same problem.

@Hoo
Any news on this bug?
I disabled the the Events (I do not need them to show some telemetry data and let the leds light up) and still get telemetry send to the hardware every time I press a button on the steering wheel.
I think CM simple forgot to set a flag to disable this piece of telemetry to be sent through any kind of SDK. 

Link to comment
Share on other sites

  • Codemasters Staff
49 minutes ago, EnsiFerrum said:

 

@Hoo
Any news on this bug?
I disabled the the Events (I do not need them to show some telemetry data and let the leds light up) and still get telemetry send to the hardware every time I press a button on the steering wheel.
I think CM simple forgot to set a flag to disable this piece of telemetry to be sent through any kind of SDK. 

We can't see the issue here. It looks like the telemetry data needs filtering out based on the button events.

Link to comment
Share on other sites

2 hours ago, Hoo said:

We can't see the issue here. It looks like the telemetry data needs filtering out based on the button events.

@Hoo @EnsiFerrum

I tested this and it works as expected.

In driving, the game sends out all packages as expected.

If you pause the game, only the PacketEventData packets are sent, so no Telemetry/Lapdata etc is sent when the game enters the pause. If you move around the menus or press controller buttons, this triggers the PacketEventData BUTN, again as expected.

So @EnsiFerrum you need to a) filter out the PacketEventData BUTN packets from the feed on the receiving end or b) if you do some motion platform, only trigger "stuff"/movement, when there is new PacketMotionData packet (with new FrameId) from the game. If you always trigger stuff when any packet comes out from the game, you will get many triggers per frame, which most likely is not what you want to do anyway.

Cheers.

Link to comment
Share on other sites

On 7/23/2021 at 12:16 AM, DaveyGravy said:

Looks like there might be a bug regarding broadcast mode not working correctly. I’ve had several reports of broadcast mode not actually broadcasting, and instead doing a standard unicast to the previously entered IP address, even though that field is disabled when broadcast mode is on. I’ve tested this on PS5 and I don’t get the issue, everything works as expected. All of the users that reported the bug so far have been on Xbox Series X which may or may not be relevant. Anyone else seen this issue, on any platform?

I have seen some of my users having issue also relating to the broadcast mode. In consoles, if they turn on the broadcast mode, the game doesn't send motion packets. I haven't been able to test this, as I don't have console. But after they turned off the broadcast mode in the game, the motion packets and other packets started arriving correctly. Could be related.

Cheers

Edited by LonelyRacer
Small typo fixes/wording changes
Link to comment
Share on other sites

LapHistoryData data package:

Isn't uint16 a little bit too small for m_sector(X)TimeInMS data for slow drivers, when they need more than 65,535 seconds per sector?

We have then an overflow value problem.

 

Edited by CanTQuiT
  • Like 1
Link to comment
Share on other sites

Hello 👋🏻 

I play on PS4 with RS Dash for the telemetry.

Why can I see in multiplayer mode „player255“ only on my timelist?

in F1 2020 was this Player100 till Player120 , so I can nearly see which player is it. But when all players have the same name, it’s little bit ...

Can you insert Telemetrie Names inGame? Like MSC or other individual shortcuts, which the players can use?

My option for public Telemetry is on, but my body see only player255, too.

Shown the PSN ID or InGameName where the best option, when the Telemetry is open for public.

thanks

Link to comment
Share on other sites

5 minutes ago, LeSansTalents said:

Hello 👋🏻 

I play on PS4 with RS Dash for the telemetry.

Why can I see in multiplayer mode „player255“ only on my timelist?

in F1 2020 was this Player100 till Player120 , so I can nearly see which player is it. But when all players have the same name, it’s little bit ...

Can you insert Telemetrie Names inGame? Like MSC or other individual shortcuts, which the players can use?

My option for public Telemetry is on, but my body see only player255, too.

Shown the PSN ID or InGameName where the best option, when the Telemetry is open for public.

thanks

Hi,

Thanks for letting me know, I will check it out and get it sorted. For RS Dash specific support questions, you are best emailing support@pocketplayground.net directly.

With regards to having actual player names (or PSN ID, etc) , this is a limitation of the game itself. Codemasters legal department does not currently allow personal account identifiers to be transmitted over the telemetry feed. If you check page 2 of this forum topic there is discussion about this topic (sending gamer tags) with Codemasters staff.

Cheers

Link to comment
Share on other sites

Has anyone else ween any issues with Type3 Event messages in Time Trial ?

At the end of a TT session i see a SEND and then an unexpected SSTA

2021-07-26 12:13:09.626+3,3293516312674155847,192.168.1.10,219.97751,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:13:09.733+3,3293516312674155847,192.168.1.10,219.97751,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:13:10.439+3,3293516312674155847,192.168.1.10,0,0,2021.1.4|SEND
2021-07-26 12:13:10.440+3,14788111507831082358,192.168.1.10,0,0,2021.1.4|SSTA
2021-07-26 12:14:17.907+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:14:17.939+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000000,0


Then going back in to do a new TT, the data just starts ... BUT the UUID has changed

2021-07-26 12:40:14.233+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:40:14.376+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:40:14.455+1,9122755524027100801,192.168.1.10,0.012398557,0,2021.1.4|0,31,2


Then at the end i get another SEND and SSTA

2021-07-26 12:42:21.456+3,9122755524027100801,192.168.1.10,113.699394,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:42:21.581+3,9122755524027100801,192.168.1.10,113.699394,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:42:22.242+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|SEND
2021-07-26 12:42:22.244+3,8475959009886494307,192.168.1.10,0,0,2021.1.4|SSTA
2021-07-26 12:42:25.610+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1

 

Format of the log is:
Date/Time+ MsgType, UID, SourceIP, SessionTime, PlayIndex, Version| DataBeingLogged

Outside TT it seems correct so far....

Link to comment
Share on other sites

21 hours ago, AndyHamp said:

Has anyone else ween any issues with Type3 Event messages in Time Trial ?

At the end of a TT session i see a SEND and then an unexpected SSTA




2021-07-26 12:13:09.626+3,3293516312674155847,192.168.1.10,219.97751,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:13:09.733+3,3293516312674155847,192.168.1.10,219.97751,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:13:10.439+3,3293516312674155847,192.168.1.10,0,0,2021.1.4|SEND
2021-07-26 12:13:10.440+3,14788111507831082358,192.168.1.10,0,0,2021.1.4|SSTA
2021-07-26 12:14:17.907+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:14:17.939+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000000,0


Then going back in to do a new TT, the data just starts ... BUT the UUID has changed




2021-07-26 12:40:14.233+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:40:14.376+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:40:14.455+1,9122755524027100801,192.168.1.10,0.012398557,0,2021.1.4|0,31,2


Then at the end i get another SEND and SSTA




2021-07-26 12:42:21.456+3,9122755524027100801,192.168.1.10,113.699394,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:42:21.581+3,9122755524027100801,192.168.1.10,113.699394,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:42:22.242+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|SEND
2021-07-26 12:42:22.244+3,8475959009886494307,192.168.1.10,0,0,2021.1.4|SSTA
2021-07-26 12:42:25.610+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1

 

Format of the log is:
Date/Time+ MsgType, UID, SourceIP, SessionTime, PlayIndex, Version| DataBeingLogged

Outside TT it seems correct so far....

@Hoo  I have opened a support report for this bug 

 

Link to comment
Share on other sites

Hi everyone,

Has anybody ever found a value of "12" for a "surface type" on which wheels are running, and knows what it means?

The CM documentation states that surface types go from 0 (tarmac) to 11 (ridged), so that's 12 different values, but in Suzuka I managed to get a "12" value and thus my app crashed, because it was missing this enum case...

Documentation seems to be lacking at least one value, meanwhile I've tagged it as "yet to be defined"...

Thanks!

Link to comment
Share on other sites

2 hours ago, Poulpix said:

Hi everyone,

Has anybody ever found a value of "12" for a "surface type" on which wheels are running, and knows what it means?

The CM documentation states that surface types go from 0 (tarmac) to 11 (ridged), so that's 12 different values, but in Suzuka I managed to get a "12" value and thus my app crashed, because it was missing this enum case...

Documentation seems to be lacking at least one value, meanwhile I've tagged it as "yet to be defined"...

Thanks!

Last year it was "Generic Surface", which you were not supposed to find anywhere. In F1 2020 I found one location, when I by accident drove super hard out from the track into the barriers on Sochi T6.

In my tool I have for all Enums a catcher for unknown Ids, which the tool then writes into a file, where I can check, if there are some odd Ids reported by the game.

Cheers

Edited by LonelyRacer
Just wrote about the Enum Unknown Id catcher.
  • Thanks 1
Link to comment
Share on other sites

On 7/22/2021 at 4:16 PM, DaveyGravy said:

Looks like there might be a bug regarding broadcast mode not working correctly. I’ve had several reports of broadcast mode not actually broadcasting, and instead doing a standard unicast to the previously entered IP address, even though that field is disabled when broadcast mode is on. I’ve tested this on PS5 and I don’t get the issue, everything works as expected. All of the users that reported the bug so far have been on Xbox Series X which may or may not be relevant. Anyone else seen this issue, on any platform?

I am by no way an expert when it comes to networking.

 

I also originally thought the UDP broadcast mode on my XboxOne X didn't work but then I realized it was actually because my UDP client needed to support multicast which is a different socket setup than just a regular UDP socket.  Here's the article I used to create a feature toggle in my app so that I could use a IP bound UDP socket or a multicast socket. https://stackoverflow.com/questions/603852/how-do-you-udp-multicast-in-python

 

But then it again it's not always so straight forward to diagnose this type of issue. It could also be a network device(s) that don't fully support multicast as most non-enterprise or non-managed devices can have spotty support for multicast and or mutlicast forwarding. Generally if you are on the same subnet as your console then most network devices should support multicast. 

 

Another thing to possibly consider is wired network vs wireless network. I've only every used a wired network connection for my console.

 

For what it's worth I use Ubiquiti UAP-ACLR access points for my home network.  In order to use multicast with wireless devices on the same subnet I had to enable "Permit Multicast" on each ESSID on my network.

Link to comment
Share on other sites

On 8/5/2021 at 3:07 AM, codylane482 said:

I am by no way an expert when it comes to networking.

 

I also originally thought the UDP broadcast mode on my XboxOne X didn't work but then I realized it was actually because my UDP client needed to support multicast which is a different socket setup than just a regular UDP socket.  Here's the article I used to create a feature toggle in my app so that I could use a IP bound UDP socket or a multicast socket. https://stackoverflow.com/questions/603852/how-do-you-udp-multicast-in-python

 

But then it again it's not always so straight forward to diagnose this type of issue. It could also be a network device(s) that don't fully support multicast as most non-enterprise or non-managed devices can have spotty support for multicast and or mutlicast forwarding. Generally if you are on the same subnet as your console then most network devices should support multicast. 

 

Another thing to possibly consider is wired network vs wireless network. I've only every used a wired network connection for my console.

 

For what it's worth I use Ubiquiti UAP-ACLR access points for my home network.  In order to use multicast with wireless devices on the same subnet I had to enable "Permit Multicast" on each ESSID on my network.

UDP broadcast is working in my client from Playstation so I'm fairly confident it's not my app, as a broadcast packet should be a broadcast packet, regardless of what platform sent it. 

I don't have access to an Xbox myself so can only go on what the increasing number of reports of it not working say, but they're all pretty consistent. If you enable broadcast mode on Xbox, it ignores the setting, and continues to send data out to the last previously entered IP address. Any thoughts @Hoo?

Multicast is a very different beast to broadcast, so I'd be surprised if you're able to collect the data that way. Unless this is what is different in the Xbox version?

Thanks

Link to comment
Share on other sites

On 8/7/2021 at 12:38 AM, DaveyGravy said:

UDP broadcast is working in my client from Playstation so I'm fairly confident it's not my app, as a broadcast packet should be a broadcast packet, regardless of what platform sent it. 

I don't have access to an Xbox myself so can only go on what the increasing number of reports of it not working say, but they're all pretty consistent. If you enable broadcast mode on Xbox, it ignores the setting, and continues to send data out to the last previously entered IP address. Any thoughts @Hoo?

Multicast is a very different beast to broadcast, so I'd be surprised if you're able to collect the data that way. Unless this is what is different in the Xbox version?

Thanks

 

I could be wrong but I'm fairly certain that when the F1 game means "broadcast" they truly mean "mulitcast" because once I created a multicast listening socket I was able to receive all expected packets from my console on my home network to my app regardless of WIFI or wired connection. It's true I do experience some issues but I blame that on my network and my app. I could also blame Microsoft for not truly following normal RFC guidelines when it comes to networking. MS has had a tendency in the past to do their own things when it comes to networking not following the normal RFC protocols which can cause issues that are hard to troubleshoot and diagnose. Also, that said, each WIFI router can have it's own interpretation of what "broadcast" or "multicast" means which complicates the issue further.

 

If I could make one recommendation to sort this out then I would recommend providing some network packet captures using something like tcpdump or wireshark to capture packets on the local xbox network and upload those captures here. I am a linux/unix guy so I generally stick to the command line and use tcpdump to capture packets with a rule something like this and then use wireshark to analyze the packets.

sudo tcpdump -i eth0 -vv -s0 udp port 20777 -w debug.cap

 

I wonder if some of your clients could capture some packets for us so we could analyze them? Again, I hate to use the words "it works for me" but once I add the feature toggle to either accept multicast packets or regular targeted UDP packets my app started working like a charm for both cases on my xbox one x. I have no packet loss and it works flawlessly as long as I have my mulitcast settings configured properly on "ALL" of my network gear.

 

I will continue to investigate and report my findings as this is something I really want to help diagnose.

Edited by codylane482
clarification
Link to comment
Share on other sites

On 8/7/2021 at 12:38 AM, DaveyGravy said:

UDP broadcast is working in my client from Playstation so I'm fairly confident it's not my app, as a broadcast packet should be a broadcast packet, regardless of what platform sent it. 

I don't have access to an Xbox myself so can only go on what the increasing number of reports of it not working say, but they're all pretty consistent. If you enable broadcast mode on Xbox, it ignores the setting, and continues to send data out to the last previously entered IP address. Any thoughts @Hoo?

Multicast is a very different beast to broadcast, so I'd be surprised if you're able to collect the data that way. Unless this is what is different in the Xbox version?

Thanks

Another thought I had and I'm not sure if you are open to this idea or not but if you can grant/provide me a copy of race dash for f1 2021, I'd be happy to continue to troubleshoot this for you and see if I am able to diagnose the issue and or find a reproduce the errors that your clients are seeing? I've not used Race Dash before but I've heard great things about it.

 

FWIW, I am an open source developer and enjoy helping the community when I have spare time.

Link to comment
Share on other sites

On 8/8/2021 at 7:18 AM, codylane482 said:

 

I could be wrong but I'm fairly certain that when the F1 game means "broadcast" they truly mean "mulitcast" because once I created a multicast listening socket I was able to receive all expected packets from my console on my home network to my app regardless of WIFI or wired connection. It's true I do experience some issues but I blame that on my network and my app. I could also blame Microsoft for not truly following normal RFC guidelines when it comes to networking. MS has had a tendency in the past to do their own things when it comes to networking not following the normal RFC protocols which can cause issues that are hard to troubleshoot and diagnose. Also, that said, each WIFI router can have it's own interpretation of what "broadcast" or "multicast" means which complicates the issue further.

Multicast is very specialist and uses a reserved IP range (224.x.x.x), so I'd be very surprised if this is what the game is using. All previous versions of the game used broadcast packets in broadcast mode as well. A couple of users say that the game still sends direct only to the previously entered IP, even when they've enabled broadcast mode so this part is definitely a bug at least (Xbox only). Quite why/how you're able to collect the broadcast data using multicast is a bit of a mystery to me but if it's working...

One user did use a different app as well and confirmed that one didn't work with broadcast mode from the Xbox either.

Feel free to try my app - it's a free download and there's a very basic dash that'll work out the box to test functionality.

Cheers

 

Link to comment
Share on other sites

1 minute ago, ericgvmaia said:

Hello!

How can I determine do % of ERS available?

The values sent by the game are not very clear...

What is the maximum capacity of the batteries?

Is ersStoreEnergy representing the current energy available?

 

Thanks!

I read it on other udp topic, but i will give you my formula :

$nPourcentErs = $nErsRemaining * 100 / 4000000;

 

Enjoy

Link to comment
Share on other sites

On 8/7/2021 at 2:38 AM, DaveyGravy said:

UDP broadcast is working in my client from Playstation so I'm fairly confident it's not my app, as a broadcast packet should be a broadcast packet, regardless of what platform sent it. 

I don't have access to an Xbox myself so can only go on what the increasing number of reports of it not working say, but they're all pretty consistent. If you enable broadcast mode on Xbox, it ignores the setting, and continues to send data out to the last previously entered IP address. Any thoughts @Hoo?

Multicast is a very different beast to broadcast, so I'd be surprised if you're able to collect the data that way. Unless this is what is different in the Xbox version?

Thanks

Skilled telemetry app user for xbox here and can confirm BROADCAST Mode for Xbox Series X is completely broken.  Switching to broadcast mode only enables the telemetry for the device IP that is input for non-broadcast mode so I know it isn't the devices themselves... has codemasters made any acknowedgement of this issue?  Is there going to be a fix??  I can't imagine it is an issue with RS Dash itself.

  • Thanks 1
Link to comment
Share on other sites

4 minutes ago, RoNiNs8 said:

Skilled telemetry app user for xbox here and can confirm BROADCAST Mode for Xbox Series X is completely broken.  Switching to broadcast mode only enables the telemetry for the device IP that is input for non-broadcast mode so I know it isn't the devices themselves... has codemasters made any acknowedgement of this issue?  Is there going to be a fix??  I can't imagine it is an issue with RS Dash itself.

FYI try manually using the broadcast address instead and see if that works, I wonder if the series x has some networking restrictions that are causing issues. I would suggest trying a subnet broadcast first. To do this, make sure the broadcast option in the game is turned off, and in the IP address put the IP of one of your devices but change the last number to 255. So if your device was 192.168.100.40, then you would set the IP to 192.168.100.255

The alternative is a global broadcast, for this you would use 255.255.255.255 as the IP address, however this tends to be less compatible with some hardware than a subnet broadcast, so i would suggest trying the subnet broadcast first.

Link to comment
Share on other sites

6 hours ago, RoNiNs8 said:

Skilled telemetry app user for xbox here and can confirm BROADCAST Mode for Xbox Series X is completely broken.  Switching to broadcast mode only enables the telemetry for the device IP that is input for non-broadcast mode so I know it isn't the devices themselves... has codemasters made any acknowedgement of this issue?  Is there going to be a fix??  I can't imagine it is an issue with RS Dash itself.

Thanks for confirming. No, I doubt it's RS Dash at fault as my app Race Dash has the same problem. Both are apps that have worked fine for years with broadcast mode (And still do on platforms other than XB).  I've not seen any acknowledgement so it's probably worth one of us logging it through the correct channels. As the first piece of data they want is the report code, as an XBox owner I'm afraid that job might fall to you... sorry 😌

Link to comment
Share on other sites

6 hours ago, cjorgens79 said:

FYI try manually using the broadcast address instead and see if that works, I wonder if the series x has some networking restrictions that are causing issues. I would suggest trying a subnet broadcast first. To do this, make sure the broadcast option in the game is turned off, and in the IP address put the IP of one of your devices but change the last number to 255. So if your device was 192.168.100.40, then you would set the IP to 192.168.100.255

The alternative is a global broadcast, for this you would use 255.255.255.255 as the IP address, however this tends to be less compatible with some hardware than a subnet broadcast, so i would suggest trying the subnet broadcast first.

I did try using 192.168.x.255 as the unicast address at the time on my Playstation and it didn't work, which is a shame as it would have been a nice work around for XB users. I didn't try the global broadcast address as it seemed a long shot, but you never know.

Link to comment
Share on other sites

2 hours ago, DaveyGravy said:

I did try using 192.168.x.255 as the unicast address at the time on my Playstation and it didn't work, which is a shame as it would have been a nice work around for XB users. I didn't try the global broadcast address as it seemed a long shot, but you never know.

255.255.255.255 is what the Project CARS games all use for their UDP telemetry. It's also possible that the game itself may do some sort of validation on the IP address entered and disable telemetry if it doesn't like the look of it.

Link to comment
Share on other sites

  • Codemasters Staff
11 hours ago, dwin20 said:

@Hoo What is the equation - given the current dataset to figure out whether your car is bottoming out or not - thanks

There is whole bunch of physics that works this all out, so not really something that we can provide through the data in the UDP system. We have a simplified version for remotely-controlled players in a network session, but this is still something that we can't really give a simple answer to.

Link to comment
Share on other sites

On the CarStatusData, why is m_tyresAgeLaps so inconsistent?

For example, on a 3 lap race:

End of lap 1 = m_tyresAgeLaps=0.
End of lap 2 = m_tyresAgeLaps=1.
End of lap 3 = m_tyresAgeLaps=3.

Shouldn't it be 1 to 3? or at least 0 to 2...

Also, when a driver pits, first and second lap after the pit is always m_tyresAgeLaps=0.

It does not increment...

Am I doing something wrong?

Link to comment
Share on other sites

10 hours ago, ericgvmaia said:

On the CarStatusData, why is m_tyresAgeLaps so inconsistent?

For example, on a 3 lap race:

End of lap 1 = m_tyresAgeLaps=0.
End of lap 2 = m_tyresAgeLaps=1.
End of lap 3 = m_tyresAgeLaps=3.

Shouldn't it be 1 to 3? or at least 0 to 2...

Also, when a driver pits, first and second lap after the pit is always m_tyresAgeLaps=0.

It does not increment...

Am I doing something wrong?

You miss something in decode.... post your unpack for us... this values its possible vehicleFiaFlags

Link to comment
Share on other sites

I have a very weird problem and i would like some make the same test as me to know if i am crazy or not. If one of you want to loose 5 minutes...

i am on PS5 // patch 1.06

I am going on solo mode. I choose  grand prix mode. track barhain. no qualif / no practice / only race 5 laps.

I choose lewis hamilton.

My objective was to track bug on warning and penalties on packet 2, because i have the feeling something don't work, but i found another thing...

the race start, my telemetry told me via the header part that PlayerCarIndex = 19

i check on packet 4 who is index 19 : IndexJoueur: 19 | AiControlled: 0 | DriverId: 7 | NetworkId: 255 | TeamId: 0 (Mercedes) | MyTeam: 0 | RaceNumber: 44 | Nationality: 10 (Britannique) | Nom: HAMILTON | YourTelemetry: 1

we are good.

now, i wrote a little code where on packet 2, this fields (m_currentLapNum, m_penalties, m_warnings) have an update, it's wrote something on my terminal to show me the update

I start the race, i let everyone overtook me and i stay at 15 seconds behind schumarer's son.

and at a moment, i am still on lap 1 at 15s, my code display :
 

Player 19 | LastLapTime : 109195 | CurrentLapTime : 50 | Sector1TimeInMS : 0 | Sector2TimeInMS : 0 | LapDistance : 4.2529296875 | TotalDistance : 5413.138671875 | SafetyCarDelta : -0 | CarPosition : 12 | CurrentLapNum : 2 | PitStatus : 0 | NumPitStop : 0 | Sector : 0 | CurrentLapInvalid : 0 | Penalties : 0 | Warnings : 0 | UnservedDriveThroughPen : 0 | UnservedStopGoPens : 0 | GridPosition
 

Obviously, the index 19 on packet 2, is not me. I am in position 20, the packet 2 - index 19 told me I am 12...

Can someone can test to see if he had the same behavior please ???
 

Edited by ThibaudPHP
Link to comment
Share on other sites

1 hour ago, ThibaudPHP said:

I have a very weird problem and i would like some make the same test as me to know if i am crazy or not. If one of you want to loose 5 minutes...

i am on PS5 // patch 1.06

I am going on solo mode. I choose  grand prix mode. track barhain. no qualif / no practice / only race 5 laps.

I choose lewis hamilton.

My objective was to track bug on warning and penalties on packet 2, because i have the feeling something don't work, but i found another thing...

the race start, my telemetry told me via the header part that PlayerCarIndex = 19

i check on packet 4 who is index 19 : IndexJoueur: 19 | AiControlled: 0 | DriverId: 7 | NetworkId: 255 | TeamId: 0 (Mercedes) | MyTeam: 0 | RaceNumber: 44 | Nationality: 10 (Britannique) | Nom: HAMILTON | YourTelemetry: 1

we are good.

now, i wrote a little code where on packet 2, this fields (m_currentLapNum, m_penalties, m_warnings) have an update, it's wrote something on my terminal to show me the update

I start the race, i let everyone overtook me and i stay at 15 seconds behind schumarer's son.

and at a moment, i am still on lap 1 at 15s, my code display :
 

Player 19 | LastLapTime : 109195 | CurrentLapTime : 50 | Sector1TimeInMS : 0 | Sector2TimeInMS : 0 | LapDistance : 4.2529296875 | TotalDistance : 5413.138671875 | SafetyCarDelta : -0 | CarPosition : 12 | CurrentLapNum : 2 | PitStatus : 0 | NumPitStop : 0 | Sector : 0 | CurrentLapInvalid : 0 | Penalties : 0 | Warnings : 0 | UnservedDriveThroughPen : 0 | UnservedStopGoPens : 0 | GridPosition
 

Obviously, the index 19 on packet 2, is not me. I am in position 20, the packet 2 - index 19 told me I am 12...

Can someone can test to see if he had the same behavior please ???
 

Okay guys, i am stupid. I found my mistake

I let my other post here to remember to me, to better check before to post. £

Shame : 1 - Thibaud : 0

 

  • Haha 1
Link to comment
Share on other sites

On 8/11/2021 at 6:12 AM, Hoo said:

There is whole bunch of physics that works this all out, so not really something that we can provide through the data in the UDP system. We have a simplified version for remotely-controlled players in a network session, but this is still something that we can't really give a simple answer to.

@Hoo Created a thread on this in setups- but should have come back to you on this - sorry. Here is what I posted:

In trying to come up with a way to know whether a car bottomed out in the telemetry programs - the variables would seem to be ride height (reference plane) -10 (thickness of plank) and the four wheel suspension positions. The wheel positions in the UDP data seem to be set very close to 0 when the car is not moving - so 0 would seem to be when that wheel is at ride height (for front or back). So couldn't you figure what the real-time plane of the plank is - given the four different wheel suspension position, -10 for the actual thickness of the plank... and then whether there is part of the plank (or all) touching the ground. 

The problem seems to be that while there is useful data for the movement of the four wheel suspension positions - that is not true for front and rear ride height which is abstracted and not realistically measurable. So if Codemasters would assign a real height value we could figure bottoming out - but without it...  

Or are my calculations just way off base?

Thanks

Link to comment
Share on other sites

17 hours ago, GambaDoCerrado said:

You miss something in decode.... post your unpack for us... this values its possible vehicleFiaFlags

I don't think I am missing anything, all the other values are correct, including ERS and the vehicleFiaFlags.

I think there is something wrong with the last lap data...

Here's how I get the CarStatusData:

carStatus.setTractionControl(buffer.getNextUInt8AsInt());
        carStatus.setAntiLockBrakes(buffer.getNextUInt8AsBoolean());
        carStatus.setFuelMix(buffer.getNextUInt8AsInt());
        carStatus.setFrontBrakeBias(buffer.getNextUInt8AsInt());
        carStatus.setPitLimiterOn(buffer.getNextUInt8AsBoolean());
        
        carStatus.setFuelInTank(buffer.getNextFloat());
        carStatus.setFuelCapacity(buffer.getNextFloat());
        carStatus.setFuelRemainingLaps(buffer.getNextFloat());
        
        carStatus.setMaxRpm(buffer.getNextUInt16AsInt());
        carStatus.setIdleRpm(buffer.getNextUInt16AsInt());
        
        carStatus.setMaxGears(buffer.getNextUInt8AsInt());
        carStatus.setDrsAllowed(buffer.getNextUInt8AsInt());        
        carStatus.setDrsActivationDistance(buffer.getNextUInt16AsInt());
        
        carStatus.setActualTyreCompound(buffer.getNextUInt8AsInt());
        carStatus.setVisualTyreCompound(buffer.getNextUInt8AsInt());
        carStatus.setTyreAgeLaps(buffer.getNextUInt8AsInt());
            
        carStatus.setVehicleFiaFlags(buffer.getNextInt8AsInt());
        
        carStatus.setErsStoreEnergy(buffer.getNextFloat());
        carStatus.setErsDeployMode(buffer.getNextUInt8AsInt());
        
        carStatus.setErsHarvestedThisLapMGUK(buffer.getNextFloat());
        carStatus.setErsHarvestedThisLapMGUH(buffer.getNextFloat());
        carStatus.setErsDeployedThisLap(buffer.getNextFloat());
        
        carStatus.setNetworkPaused(buffer.getNextUInt8AsBoolean());

Link to comment
Share on other sites

On 8/11/2021 at 10:15 AM, GambaDoCerrado said:

Hi guys. I very happy with new telemetry structure... its more logical... I need some help.
@Hoo can you confirm this: "

  • "UDP: LapHistoryDate will now be correctly sent for an active car after another has retired."

    Thanks.

@Hoocan you confirm please? I received missing packets yet...

Link to comment
Share on other sites

On 8/9/2021 at 6:38 AM, DaveyGravy said:

Multicast is very specialist and uses a reserved IP range (224.x.x.x), so I'd be very surprised if this is what the game is using. All previous versions of the game used broadcast packets in broadcast mode as well. A couple of users say that the game still sends direct only to the previously entered IP, even when they've enabled broadcast mode so this part is definitely a bug at least (Xbox only). Quite why/how you're able to collect the broadcast data using multicast is a bit of a mystery to me but if it's working...

One user did use a different app as well and confirmed that one didn't work with broadcast mode from the Xbox either.

Feel free to try my app - it's a free download and there's a very basic dash that'll work out the box to test functionality.

Cheers

 

After spending the last week troubleshooting, I too experience this now and it requires some fiddling with the IP address even when broadcast mode is turned on. But yeah, I think it's important to admit when you are wrong, and so far I've been totally wrong. As others have mentioned and I would agree it's most likely the Xbox networking implementation.

For now, it's far easier to run  my app with IPv4 address: 0.0.0.0:20777 and then in my Xbox F1 game settings set the IP address to the IP of my app.

I'm starting to wonder now if it's a subnet issue. For example, I use DHCP for my network and it's a wired connection. My DHCP server is running Linux and I know it's configured correctly to provide the correct subnet for all of it's DHCP clients. The one weird thing I've always noticed is that when my Xbox gets it's DHCP address it never gets the right netmask. It's always set to 255.0.0.0 but it should be 255.255.255.0 so I have to manually go in and set the IP and netmask.

 

I will continue to run some more tests and see if I can nail this down. 

Link to comment
Share on other sites

Hi,

Wondering if you can help. I'm trying to pull the driver name, specifically the Steam ID. In the telemetry sheet, it says either m_networkId or m_name[48] should be what I use to get this (I think?)

When I use networkID I get a number, which isn't helpful and when I use m_name I can only do it by Position [GameRawData.PlayerParticipantData.m_name01] and that only returns the letter P, despite no-one in our session starting with that letter.

Ideally, and I'd assume this is possible, like to pull the SteamID of the user and also be able to pull the steamID of everyone in the session. Can you help with what I'm doing wrong?

 

  

  • Sad 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...