Codemasters TeamThe telemetry public who send no (sentive) data continue despite the telemetry put on public. it's totally random. Did dev change something on server ?
it's new one since saturday. and update was only monday
@HoobiechoobieI really need help on this one please
Codemasters Team
@ThibaudPHP wrote:
The telemetry public who send no (sentive) data continue despite the telemetry put on public. it's totally random. Did dev change something on server ?
it's new one since saturday. and update was only monday
@HoobiechoobieI really need help on this one please
Are you able to provide a report code (16-digit 4x4 code seen in the bottom-left corner of the Settings screen on the pause / options menu) along with the table showing the which players in the session were using public / restricted settings? Thanks.
Codemasters TeamHi @ThibaudPHP,
I've logged this issue with the dev team to investigate further. At the moment, we are struggling to reproduce it though. Are you able to provide a full set of steps that we can follow to reproduce this issue, including platform, whether crossplay was enabled, number of players in the session, role of the UDP-capturing computer (client, host, spectator), when the UDP data was being collected, and anything else significant that might have occurred during the session (e.g. players quitting session, host migration, etc.).
Thanks,
Hoo.
Hi,
the tool I've developed doesn't rely on public telemetry but I log the information.
So far I've not noticed any strange behaviour, usually who has it public it sends data to all the sessions.
The only small issue that I've noticed, but not yet investigated is that time to time from one session to another the same user doesn't send anymore the public name.
I guess it's unlikely that someone changes it manually.
@ThibaudPHP did you notice if also it stops to send the public ID in your case?
I'm having a difficult time finding a "good" way to assign "broadcast" names to drivers. I was using driver #, but try as I might, I can not get all drivers to reliably choose/update their driver number for the race. Using the UTF-8 formatted m_name from the participants data is also troublesome, because you can't easily figure out which driver it is referring too, especially if they did not turn on "show name" in the telemetry settings.
We're going to try and create a drag and drop configuration page that will display all the participant data like driver number, team name, nationality, and that string name, and then drag, and/or type in, a "broadcast" name on to the corresponding participant... hopefully it's enough data for our broadcasters to quickly determine which participant is which.
Any advice on better ways to do this?
Thanks,
Bryan
Is anyone else having issues with m_pitStopTimerInMS, from the Lap Data packet? This frequently continues to count up even after the person leaves the box, but not all the time. It should only count up until they leave the box. m_pitLaneTimeInLaneInMS seems to work as intended and stops counting up when they exit the pit lane. When m_pitStopTimerInMS fails to stop counting after they leave the box it will finally stop counting up when m_pitLaneTimeInLaneInMS stops counting after the driver leaves the pit lane. The m_pitStatus flag seems to be working fine, so I am currently using this to capture the current m_pitStopTimerInMS once the m_pitStatus flag changes from a 2 to a 1. This kinda works but is not always perfectly accurate, especially when a driver is serving a penalty in the pits. This is because even though the m_pitStatus flag changes from a 1 to 2 when a driver enters the pit box, if they are serving a penalty the m_pitStopTimerInMS doesn't start counting until penalty is served and the mechanics start working on the car... even though they are sitting stationary in the box the whole time.
Can we get this looked into?
Codemasters Team
@ThibaudPHP wrote:
...If during the formation lap someone is DSQ. i will receive the packet 7 for them. If nobody is DSQ. No packet 7.
Thanks for the info. I've asked the test team to take a look at this.
Codemasters Team
@ThibaudPHP wrote:
If during the formation lap someone is DSQ. i will receive the packet 7 for them. If nobody is DSQ. No packet 7.
Please test it, and told me i am right and you will fix it.
Hi @ThibaudPHP,
We've tried testing this again using the steps that you provided, but we are not able to repeat this problem unless we point multiple clients at a single receiving app using the same IP/port combination. This configuration isn't something that would be supported by the current UDP system. Are you able to confirm if this is what is happening in your tests?
Codemasters Team
@ThibaudPHP wrote:
@Hoobiechoobie Hi
When the formation lap is active, my system receive no packet 7.
if during 'immersive / manual' someone is DSQ (missing the grid position) for him, the packet 7 is receive.
Only 1 person (generally a spectator) is the one who enter the specific IP + Port to send the udp packet to my server.
all racers must just have "your telemetry to public" and share online ID to on
We will take another look at this one. Does this issue resolve itself once the start lights go out for the race, or does this issue persist for the whole race if the player does not get disqualified from the formation lap?
Hi. Not sure if it was already raised here but I ask anyway.
I asked Sir David Greco about AI car setup, pointing out that all AI drivers seem to use same setup suggested to gamers, at least based on UDP telemetry.
However, he said that AI cars have different front/rear wings and ride heights.
I am using @IkoRein's telemetry tool and raw data shows all AI drivers' setups have same values as one of pre-defined car setups (usually the setup suggested to gamers for that track). And I assume it shows whatever game offers in telemetry packets.
So is it possible to see in UDP telemetry the actual car setups AI drivers have in each session and quali/race?
@P4st3l1ak wrote:Hi. Not sure if it was already raised here but I ask anyway.
I asked Sir David Greco about AI car setup, pointing out that all AI drivers seem to use same setup suggested to gamers, at least based on UDP telemetry.
However, he said that AI cars have different front/rear wings and ride heights.
I am using @IkoRein's telemetry tool and raw data shows all AI drivers' setups have same values as one of pre-defined car setups (usually the setup suggested to gamers for that track). And I assume it shows whatever game offers in telemetry packets.
So is it possible to see in UDP telemetry the actual car setups AI drivers have in each session and quali/race?
+1, same with PXG Telemetry UDP 2021
@Hoobiechoobie I ask you about this some days ago.
Can you let us know what the dev team thinks about the warnings matter?
Simhub couldn't read the Events packet. I know this is not EA/Codemasters problem, but also know Simhub is one of the most used tools to read telemetry, the one that GSI wheels or Cube Controls wheels use in their most recent wheels, for instance. You can find hundreds of dashboards on RaceDepartment made with Simhub.
F1 games do not have a White/Black flag, but before the last change, we can use the m_warnings to count how many times a driver exceed track limits gaining time
Please revert the change and return this possibility to us.
Because also, I don't see what use it has to count all the incidents that a driver has. Can anyone find what utility it has?
Thank you
Codemasters Team
@ThibaudPHP wrote:
@Hoobiechoobie it's persist.
Hi @ThibaudPHP,
We are still unable to repeat the issue here. Please can you confirm the following:
Thanks,
Hoo.
Codemasters Team
@navarreitor wrote:
@Hoobiechoobie I ask you about this some days ago.
Please revert the change and return this possibility to us.
Hi @navarreitor,
As this change was a result of a fix to incorrect functionality, it is not desirable for us to revert this. We are discussing options of introducing a new field that explicitly identifies corner cut warnings for a future revision of the UDP system.
Thanks,
Hoo.
