Jump to content Jump to content
F1 2021 | Online Services Down For Maintenance | 26/07/2021 ×

F1 2017 D-Box and UDP Output Specification


Hoo

Recommended Posts

Hoo said:
CanTQuiT said:
Is the closed F1-2018-beta already started?
Not yet. Places are limited, but you can still apply here: https://www.surveymonkey.co.uk/r/F1BetaSignUp. If you are an app developer using the UDP output then please add "UDP" into the answer for question 8 so that the community team can filter out these requests more easily from the other beta applicants.
@Hoo
Awwww i forgot to mention that when i applied! No way to add that now? :O
Link to post
Share on other sites
  • 2 weeks later...

Hi all

I experienced a problem the last two days. I use Codemasters Proxy Server to feed my SLI-Pro and Sim Commander 4. First days it didn't worked correctly. SLI-Pro was fine but Sim Commander doesn't received any data. On Saturday i was able to feed both at the first time. Don't know why. I didn't changed anything. The problem now is I have a 4sec lag on my SLI-Pro and for FFB.

I set the ingame values as described on eksim page for CMPS and SLIMax Manager, except the Output Port ingame. I use 20778 because Sim Commander is hardcoded to 20777.

In CMPS Input Port is set to 20778 and two Outputs 40555 API 5 for SLIMax and 20777 API 3 for Sim Commander. I also tried both outputs with different ports and different API's, as well as 40222 as ingame Output Port. No Change of lag.

If i try Sim Commander only it is fine. If i try SLI-Pro + CMPS only i have the 4sec lag. If i Switch off CMPS and try SLI-Pro only the lag is gone.

Anyone else experienced this Problem and maybe knows how to solve it?

Link to post
Share on other sites
  • 2 weeks later...
@Hoo - with regards to F1 2018, you mentioned that you would be including an option to output in the older F1 2017 telemetry format for compatibility with existing apps? I would like to raise a few concerns about this, as I feel it is important that we have a way to determine if the telemetry feed is actually coming from F1 2017 or from F1 2018 (in compatibility mode).
I would need to disable certain functionality in my apps if F1 2018 telemetry was being received in F1 2017 format, the reason being that I have an online portal for my users which is used to save their session history and I also have my own leaderboards. I would not want to have the leaderboards for F1 2017 being polluted with data from F1 2018, as I would want to have a separate leaderboard for F1 2018. The saved session data is also tied to the source game along with all player stats for that game, so it is important to have accurate source game information.

As it is now, i cant really see an easy way to achieve this with the current telemetry structure. The only possibility being the m_era which i am guessing would say 2018, however if you still offer the 1980 era in F1 2018 then it is still a problem for leaderboards for those vehicles across both games. I would think the best option would be a slight modification to the F1 2017 style protocol to include a game version so we can get this information. Perhaps just added to the end of the packet structure which would mean it would continue to work for any apps not specifically checking the packet length, and for those that are it is a very simple change to make it compatible with both. 

Another consideration with a compatibility option would be that anyone using the team id and driver id would still need to update their apps anyway for new drivers and team names. 

Cheers
Link to post
Share on other sites
Also mentioning the era data, it would be good if we could have the exact year of the car. For example, I want to lock in a digital dashboard for newer cars and analogue for old cars. I don’t want to have to check the car and then determine the year of it. I would much rather be able to check if the year of the car is < x. 
Link to post
Share on other sites
Also mentioning the era data, it would be good if we could have the exact year of the car. For example, I want to lock in a digital dashboard for newer cars and analogue for old cars. I don’t want to have to check the car and then determine the year of it. I would much rather be able to check if the year of the car is < x. 
Cant you just use the era field, it returns 2017 for modern cars and 1980 for classic cars..
Link to post
Share on other sites
Also mentioning the era data, it would be good if we could have the exact year of the car. For example, I want to lock in a digital dashboard for newer cars and analogue for old cars. I don’t want to have to check the car and then determine the year of it. I would much rather be able to check if the year of the car is < x. 
Cant you just use the era field, it returns 2017 for modern cars and 1980 for classic cars..
What about the 2000s and 1990s? TheyI need to know that to know if they should have digital or analogue displays. Just because they are classic doesn’t mean they have analogue dashboards. 
Link to post
Share on other sites
Also mentioning the era data, it would be good if we could have the exact year of the car. For example, I want to lock in a digital dashboard for newer cars and analogue for old cars. I don’t want to have to check the car and then determine the year of it. I would much rather be able to check if the year of the car is < x. 
Cant you just use the era field, it returns 2017 for modern cars and 1980 for classic cars..
What about the 2000s and 1990s? TheyI need to know that to know if they should have digital or analogue displays. Just because they are classic doesn’t mean they have analogue dashboards. 
fair enough, i see what you meant now.
Link to post
Share on other sites
  • Codemasters Staff
For anyone helping to develop the UDP system in the beta, the new specs are posted here: http://forums.codemasters.com/discussion/133253/f1-2018-udp-specification. We will move this into thread into the main technical support thread once it has been finalised ahead of the game release. 

Link to post
Share on other sites
Hoo said:
For anyone helping to develop the UDP system in the beta, the new specs are posted here: http://forums.codemasters.com/discussion/133253/f1-2018-udp-specification. We will move this into thread into the main technical support thread once it has been finalised ahead of the game release. 

 :(  awww I don't have beta access and I can't even see what the specs are
Link to post
Share on other sites
Hi @Hoo, could I ask how the origin points of the world coordinates m_x, m_y and m_z are taken please? I noticed that the m_z outputs had to be multiplied by -1 in order to get the correct 2D plots, such that any given horizontal coordinate is given by (m_x, -m_z), but for instance the origin (0,0) for Austin is north of the track, when for Abu Dhabi it is somewhere in the middle such that the whole circuit goes around it.



Link to post
Share on other sites
Hi guys, I have made an f1 steering wheel with all telemetry data and interfaces behavior the same as real one (Ferrari SF71H).
You can see the steering wheel in action here:
https://www.youtube.com/watch?v=TAx4kTZJ6H0

What do you think?
Link to post
Share on other sites
  • 2 weeks later...
Is there any information yet on how different the 2018 data will be ?  Is it an evolution or total revolution ?

For those of us no of the public beta when will we get anything ? Or will it all happen after the 24th Aug ?

Link to post
Share on other sites
  • Codemasters Staff
AndyHamp said:
Is there any information yet on how different the 2018 data will be ?  Is it an evolution or total revolution ?

For those of us no of the public beta when will we get anything ? Or will it all happen after the 24th Aug ?

It will be a re-evolution! ;)

The 2017 UDP format will still be available, so you should be able to use that as before. The new format sees the packet broken down into sections that contain specific types of data, allowing us to include more data than if using a single packet. These details are currently being worked on, so once this stabilises we will post the specs in the public forum. Hopefully this will happen a few weeks before game launch.
Link to post
Share on other sites
Hoo said:
It will be a re-evolution! ;)

The 2017 UDP format will still be available, so you should be able to use that as before. The new format sees the packet broken down into sections that contain specific types of data, allowing us to include more data than if using a single packet. These details are currently being worked on, so once this stabilises we will post the specs in the public forum. Hopefully this will happen a few weeks before game launch.
@hoo any details on how you might break it down ? For example geospatial (location, speed etc) .... car (temps, settings) .... etc or something different ?
Link to post
Share on other sites
Hi everyone,

I'm writing an application that receives the data sent from game but I'm having trouble decoding it. Does anyone can provide me an example on how to decode the information in Python?

Thanks very much!
Link to post
Share on other sites
  • 2 weeks later...
Hoo said:
AndyHamp said:
Is there any information yet on how different the 2018 data will be ?  Is it an evolution or total revolution ?

For those of us no of the public beta when will we get anything ? Or will it all happen after the 24th Aug ?

It will be a re-evolution! ;)

The 2017 UDP format will still be available, so you should be able to use that as before. The new format sees the packet broken down into sections that contain specific types of data, allowing us to include more data than if using a single packet. These details are currently being worked on, so once this stabilises we will post the specs in the public forum. Hopefully this will happen a few weeks before game launch.
Information currently missing that I would like is: the SC/VSC deployment status, and the associated SC delta.
Hopefully this falls under the new data you already have planned, if not, could you consider adding it?
Link to post
Share on other sites
  • 3 weeks later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...