@ThibaudPHP wrote:Yes,
there are other event who are send it's a racer and when it's spectator
Why would a spectator not receive all the same Event Packets as a driver? And is there a way for a spectator to get the Fastest Lap event and all the others?
I monitor the Fastest lap without event. i compare lap when they came via packet 2. and update if is it better.
Each day i have problem.
sorry for spamming guys.
I dev a tool for league and all racers must have their telemetry public.
Today 5 races on 7 have telemetry issue. Racer have telemetry public, but sensitive data (wears tyres / damage / ers / fuel) are send like telemetry was limited.
On 4 races all the lobby was impacted, on one lobby 4 racers have data send not the other.
I try to know if it was because the relay (the one who send the lobby telemetry) dont put public : No.
I try to know if it was related because crossplay : No
It's very annoying. Did some of you already experimented that ?
Did EA update his server ?
someone have an idea ?
like you can see, if someone have restricted telemetry he had a red square on last column and his fuel is lean (0.00) and ERS 0%
We have only data for 4 racers on this.
** crying ***
FYI patch 1.10 solved those 2 issues;
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
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
