PDA

View Full Version : PCARS2 UDP API Bug reports



nabezokodaikon
06-11-2017, 00:55
Let's write a bug of UDPAPI of PCARS2, hoping that the bug information will arrive to PCARS2 developers.

The UDP protocol version is limited to "Project CARS 2".

If possible, ask one post to write one bug.

nabezokodaikon
06-11-2017, 00:58
The sTyreCompound of sTelemetryData is sent with an empty character (all 0 value).

In rare cases, correct values may be acquired.

nabezokodaikon
06-11-2017, 00:59
For timed session with sLapsTimeInEvent of sRaceData, the time value is always 32767.

nabezokodaikon
06-11-2017, 06:31
Tire data of sTelemetryData
# FrontLeft
* sTyreTempRight = Fixed 0
* sTyreTempCenter = Fixed 0
* sTyreTempLeft = Fixed 0
* sAirPressure = Fixed 65467
* sBrakeTempCelsius = Unknown value
* sTyreWear = Unknown value
* sRideHeight = Unknown value
* sSuspensionRideHeight = Unknown value
# FrontRight
* sTyreWear = Increasing or decreasing
# RearLeft
* sTyreWear = It is unknown whether the value is correct when compared with RearRight.
# RearRight
* sTyreWear = It is unknown whether the value is correct when compared with RearLeft.

nabezokodaikon
09-11-2017, 17:14
There are too many bugs, I am tired...

SenorPez
10-11-2017, 20:15
Is there an official way to track API bugs and submit them to SMS? I'm getting caught up after 2 weeks down a real-life rabbit hole, and now that I've been working with the PCARS2 UDP API, I'm finding errors myself. That being said, I want to make sure any efforts to report bugs are at least seen by the powers-that-be... and I hope some of them can be fixed because there's a few doozies.

nabezokodaikon
11-11-2017, 12:50
I also looked for a way to tell the developer, but I could not find it.
Therefore, I set this thread.

SenorPez
11-11-2017, 18:17
The mPartialPacketIndex of PacketBase of sParticipantVehicleNamesData has not been sent up to the value of mPartialPacketNumber.


The mPartialPacketIndex and mPartialPacketNumber of PacketBase of sVehicleClassNamesData are always sent with the same value, and it is impossible to combine data.

These aren't bugs.

sParticipantVehicleNamesData and sVehicleClassNamesData are the same packet type: eParticipantVehicleNames, differentiated by size.

The documentation also states:


// Note: This data is always sent with at least 2 packets. The 1-(n-1) holds the vehicle name for each participant
// The last one holding the class names.


Based on the defined limitations on data (max 32 participants, 60 class names per packet), there are only 2 cases: 2 total packets or 3 total packets, and only one of sVehicleClassNamesData is sent. The contract above also guarantees that the last packet sent is sVehicleClassNamesData.

So in the minimum case of 2, the sParticipantVehicleNamesData packet will have mPartialPacketIndex 1 and mPartialPacketNumber 2. The sVehicleClassNamesData will have mPartialPacketIndex 2 (since it's always the last packet sent) and mPartialPacketNumber 2 (the total number of eParticipantVehicleNames packets sent).

So in the case of 3, the sParticipantVehicleNamesData packets will have mPartialPacketIndex 1 and 2 and mPartialPacketNumber 3. The sVehicleClassNamesData will have mPartialPacketIndex 3 (since it's always the last packet sent) and mPartialPacketNumber 3 (the total number of eParticipantVehicleNames packets sent).

nabezokodaikon
14-11-2017, 15:47
I see. ParticipantVehicleNamesData and sVehicleClassNamesData are data that is continuous.
I understood that it was not a bug, so I will erase it.

nabezokodaikon
28-11-2017, 14:56
Patch 1.3.0.0

There is no modification of the tire relationship.
I have not confirmed everything yet, but the data size of TELEMETRY_DATA, PARTICIPANTS_DATA and TIMINGS_DATA has changed. Just adding unknown data to the end, it seems no problem.

Bugs have increased ...

nabezokodaikon
29-11-2017, 03:33
In rare cases the NaN value may be in the TIMINGS_DATA sCurrentSectorTime.

nabezokodaikon
30-11-2017, 06:06
The data size of sTimingsData#sParticipantInfo has change from 30Byte to 32Byte.

kvb
12-01-2018, 00:06
The car name in sParticipantVehicleNamesData can contain characters from earlier chosen cars

See this thread:
forum projectcarsgame com/showthread.php?60030-Weird-behaviour-from-UDP

Martin Moravec
16-02-2018, 10:30
Hi guys, so, finally chew through the other bugs to get to UPD interface again.
Went through the above



The sTyreCompound of sTelemetryData is sent with an empty character (all 0 value).

>> cannot repro here, presumably fixed with a general string bug fix missed patch 4 cutoff



For timed session with sLapsTimeInEvent of sRaceData, the time value is always 32767.

>> found here and fixed, will be sorted in the next patch



# FrontLeft
* sTyreTempRight = Fixed 0
* sTyreTempCenter = Fixed 0
* sTyreTempLeft = Fixed 0
* sAirPressure = Fixed 65467
* sBrakeTempCelsius = Unknown value
* sTyreWear = Unknown value
* sRideHeight = Unknown value
* sSuspensionRideHeight = Unknown value
# FrontRight
* sTyreWear = Increasing or decreasing
# RearLeft
* sTyreWear = It is unknown whether the value is correct when compared with RearRight.
# RearRight
* sTyreWear = It is unknown whether the value is correct when compared with RearLeft.

>> found here and fixed, will be sorted in the next patch



In rare cases the NaN value may be in the TIMINGS_DATA sCurrentSectorTime.

>> cannot repro, but put check in place to prevent such data to be passed over UPD further, if you can repro that and would post the situation ( track/race setup, exact moment, platform etc. ) that would be awesome.



The data size of sTimingsData#sParticipantInfo has change from 30Byte to 32Byte.

>> Correct, the updated header published with Patch3 contains an extra field (sMPParticipantIndex - to match it with index directly)
but alas the version number was not bumped to make it clear, so that will be fixed in the upcoming patch

Please do continue to fill this thread with bugs if you find them :]

The string encoding will not be fixed in the next patch - since that is simply beyond the time resources we have and it is not a simple API interface fix.

mr_belowski
16-02-2018, 10:49
The string encoding will not be fixed in the next patch - since that is simply beyond the time resources we have and it is not a simple API interface fix.

There are many players and AI drivers with names containing characters not in the default codepage for most Windows (and presumably) XBox systems. It's a while since I looked into this but, if I remember correctly, these strings are encoded up to the first char not in the codepage and are then terminated. So a driver name of, say, arčhie will be sent by the APIs as "ar". A driver named "čolin" would have no name at all.

I know I'm beating a drum here but for an international game with a worldwide audience that uses Steam player tags as player names, only supporting Cp1252 or whatever in the APIs is incredibly disappointing

Martin Moravec
16-02-2018, 11:23
There are many players and AI drivers with names containing characters not in the default codepage for most Windows (and presumably) XBox systems. It's a while since I looked into this but, if I remember correctly, these strings are encoded up to the first char not in the codepage and are then terminated. So a driver name of, say, arčhie will be sent by the APIs as "ar". A driver named "čolin" would have no name at all.

I know I'm beating a drum here but for an international game with a worldwide audience that uses Steam player tags as player names, only supporting Cp1252 or whatever in the APIs is incredibly disappointing

I do understand that - it is one of mine pet hates as well.

MaXyM
16-02-2018, 11:34
I can imagine that proper encoding might be a problem, since whole system should be touched in some way.
Maybe as a compromise, you could consider replacing all national characters by their ascii substitute, for example replace ěę by e etc. It would match API scope and afaik shouldn't take much time.

mr_belowski
16-02-2018, 11:47
I don't think it's as simple as that - while there are some substitutions that might be OK many just aren't possible. These are Steam names remember, so folks have all sorts of weird non-letter chars in there that don't have a sensible ASCII (or rather, Cp1252 which is ASCII + a bunch of accented letter) equivalent.

Knowing what code page is actually being used would help a little bit for non-ascii characters as Cp1252 and UTF-8 don't match for the last 50 or so characters - if the client app is running on a different device, it has to guess what encoding is being used which has its own problems.

Really, the only proper solution here is to use UTF-8 globally, as games like RaceRoom do. Internally, the strings are just unicode so the game is quite happy to handle non-Latin chars. They're only encoded when they're exported as binary data (i.e. when they're transformed to bytes for the APIs). But I do appreciate that it's not as simple as just switching the charset in the encoding. But please keep it in the backlog if you can Martin, it's a very frustrating thing to try and work around

Kafumanto
16-02-2018, 14:13
Please do continue to fill this thread with bugs if you find them :]

Great and waited news! Thanks :)

Premise: I abandoned support for UDP v2 protocol long time ago as it was unusable, so all I'll write below is retrieved from my memory ;)

Bugs

sometimes I received a packet with mPartialPacketNumber = 1 and mPartialPacketIndex = 2... clearly a big problem to collect the stream :)
some packet version numbers have not been updated with last revision (rev 3) of the protocol, so to detect the proper packet version we have to look at a mixture of packet sizes, "nominal" packet versions and fallbacks - it's quite hard to manage it safely... (I have a function of 128 lines just to guess the packet version...);
in the same game session, the same packet type is received sometime with version N and sometime with version N-1 - making it impossible to manage properly the whole protocol;


Extra field needed
In general there is an important missing information when you are trying to reconstruct the whole stream for telemetry analysis: you can't group data by "temporal instant" (i.e. same game frame number). In detail: while racing you receive a sequence of packets as:

...
eCarPhysics
eTimings
eCarPhysics
eTimings
eCarPhysics
eTimings
eCarPhysics
eTimings
...


The point is that's impossible to group them correctly by instant: are physics data in packet #4 associated with timings in packet #3 or #5? When working with telemetry analysis this information is crucial.

Thanks for the all the fixes! :)

Martin Moravec
16-02-2018, 15:57
Great and waited news! Thanks :)

Premise: I abandoned support for UDP v2 protocol long time ago as it was unusable, so all I'll write below is retrieved from my memory ;)

Bugs

sometimes I received a packet with mPartialPacketNumber = 1 and mPartialPacketIndex = 2... clearly a big problem to collect the stream :)
some packet version numbers have not been updated with last revision (rev 3) of the protocol, so to detect the proper packet version we have to look at a mixture of packet sizes, "nominal" packet versions and fallbacks - it's quite hard to manage it safely... (I have a function of 128 lines just to guess the packet version...);
in the same game session, the same packet type is received sometime with version N and sometime with version N-1 - making it impossible to manage properly the whole protocol;



The packet version numbering will be bumped where necessary in the next patch, the rest is bit of a mystery to me and should not be (was not) existing. If you have any logs please forward them to me via PM.



Extra field needed
In general there is an important missing information when you are trying to reconstruct the whole stream for telemetry analysis: you can't group data by "temporal instant" (i.e. same game frame number). In detail: while racing you receive a sequence of packets as:

...
eCarPhysics
eTimings
eCarPhysics
eTimings
eCarPhysics
eTimings
eCarPhysics
eTimings
...


The point is that's impossible to group them correctly by instant: are physics data in packet #4 associated with timings in packet #3 or #5? When working with telemetry analysis this information is crucial.


Ok, that can be done.

nabezokodaikon
17-02-2018, 14:15
The time has come for this thread to be useful!
Thank you!

Sampo
18-02-2018, 00:04
This is for the shared memory API, not for UDP, so sorry for that. I'm still wondering about the tyre layer and tyre tread temps. Are those two mixed up in the data or is it just me not understanding what they are? When I lock my fronts, the tyre layer temp rises, not the tyre tread as I would think.

UPDATE: I got my answer from Jussi. All is good now :)

cjorgens79
24-03-2018, 05:32
Hi guys, so, finally chew through the other bugs to get to UPD interface again.
Went through the above


>> cannot repro here, presumably fixed with a general string bug fix missed patch 4 cutoff


>> found here and fixed, will be sorted in the next patch


>> found here and fixed, will be sorted in the next patch


>> cannot repro, but put check in place to prevent such data to be passed over UPD further, if you can repro that and would post the situation ( track/race setup, exact moment, platform etc. ) that would be awesome.


>> Correct, the updated header published with Patch3 contains an extra field (sMPParticipantIndex - to match it with index directly)
but alas the version number was not bumped to make it clear, so that will be fixed in the upcoming patch

Please do continue to fill this thread with bugs if you find them :]

The string encoding will not be fixed in the next patch - since that is simply beyond the time resources we have and it is not a simple API interface fix.

Once the next patch comes out with the fixes you mentioned for the data around the tyre temps onwards being corrupt then I will give it a good test and send through any feedback as well, at the moment the data is just too messed up to work with. Any indications when the next patch is likely, weeks, months etc? Certainly won't hold you to anything, its just handy to have a rough idea when planning what I will be working on with my apps.

mr_belowski
05-04-2018, 16:55
Not sure if this is the right thread for it, but have any API changes or fixes been included in patch 5?

Sampo
05-04-2018, 18:01
Not sure if this is the place, but the help text for UDP Frequency is still backwards (at least for PC2 mode). A setting of 1 sends the data more often, and 9 sends it less often. It's not that big of a deal, but some people might have it at 1, expecting less network traffic and having trouble with their network.

cjorgens79
06-04-2018, 06:22
Not sure if this is the right thread for it, but have any API changes or fixes been included in patch 5?

I haven't tested myself yet, but this post (http://forum.projectcarsgame.com/showthread.php?56963-PCARS2-UDP-API-Bug-reports&p=1476950&viewfull=1#post1476950) from Martin indicates the some of the fixes that should have been included in this patch

Maskmagog
19-06-2018, 19:41
Any news on API development? Very few developers seem to be using version 2, unfortunately.

cjorgens79
01-07-2018, 02:33
whats the plan with the vehicle classes? Currently the class names are never sent in the telemetry. The enum (eVehicleClassNames = 9) has been removed, but the structure (sVehicleClassNamesData) still exists in the hpp file. The sVehicleInfo struct contains the uint sClass field, but without the sVehicleClassNamesData we dont know what class each value represents. I guess we really don't need the sVehicleClassNamesData packet itself, we could instead use a fixed list of classes mapped to id's, so could we please get the list of classes and class id's?

Edit: never mind, sorted out.

Sampo
01-07-2018, 03:19
I do get the class names just how it's described in the .hpp

Edit: I'm talking about version 2.

cjorgens79
01-07-2018, 11:15
I do get the class names just how it's described in the .hpp

Edit: I'm talking about version 2.

ah thanks you are right, I still had some code expecting an earlier structure where the class names were their own distinct packet type. I hadn't noticed the comment that was added saying that it was sent as part of alternating participant vehicle names

cjorgens79
02-07-2018, 13:14
Has anyone been able to make use of the vehicle names for MP sessions? It seems that there are some issues with the data currently. I am seeing the following.

struct sParticipantInfo,
unsigned short sCarIndex; // 18 -- top bit shows if participant is (local or remote) human player or not

In single player sessions (ie custom race), sCarIndex appears to be correct for all AI players, however for the actual player the value is always 65535. The appropriate car index from the vehicle names data is 2. Even excluding the top bit which is supposed to represent human or AI player still results in 32767 which is not a valid car index in the vehicle names data.

In multiplayer sessions, sCarIndex is 65535 for ALL players.

Its as if instead of setting the high bit to indicate human player, all bits are getting set in that field.

@Martin, could you please check if this is the case. Due to this it does not seem possible to determine the correct vehicle for an opponent in MP sessions. Have I missed something or is this a bug in the current implementation?

Ivan_xXx
07-07-2018, 21:52
Hi,

in the udp protocol the steering (both unfiltered inputs and processed) are signed 8bit integers. With a standard 900 degree wheel this makes for 4.5 degree resolution. Is it possible to change to a 16 bit integer for more resolution?

This will make data overlays for steering much more useful.

Thank you

cjorgens79
08-07-2018, 11:44
Has anyone been able to make use of the vehicle names for MP sessions? It seems that there are some issues with the data currently. I am seeing the following.

struct sParticipantInfo,
unsigned short sCarIndex; // 18 -- top bit shows if participant is (local or remote) human player or not

In single player sessions (ie custom race), sCarIndex appears to be correct for all AI players, however for the actual player the value is always 65535. The appropriate car index from the vehicle names data is 2. Even excluding the top bit which is supposed to represent human or AI player still results in 32767 which is not a valid car index in the vehicle names data.

In multiplayer sessions, sCarIndex is 65535 for ALL players.

Its as if instead of setting the high bit to indicate human player, all bits are getting set in that field.

@Martin, could you please check if this is the case. Due to this it does not seem possible to determine the correct vehicle for an opponent in MP sessions. Have I missed something or is this a bug in the current implementation?

bump

cjorgens79
21-07-2018, 04:29
Has anyone been able to make use of the vehicle names for MP sessions? It seems that there are some issues with the data currently. I am seeing the following.

struct sParticipantInfo,
unsigned short sCarIndex; // 18 -- top bit shows if participant is (local or remote) human player or not

In single player sessions (ie custom race), sCarIndex appears to be correct for all AI players, however for the actual player the value is always 65535. The appropriate car index from the vehicle names data is 2. Even excluding the top bit which is supposed to represent human or AI player still results in 32767 which is not a valid car index in the vehicle names data.

In multiplayer sessions, sCarIndex is 65535 for ALL players.

Its as if instead of setting the high bit to indicate human player, all bits are getting set in that field.

@Martin, could you please check if this is the case. Due to this it does not seem possible to determine the correct vehicle for an opponent in MP sessions. Have I missed something or is this a bug in the current implementation?

@Moderators @Martin @AnyoneAtSMS
Could we please get this (quoted above) fixed for the next patch so the PCARS2 protocol is actual usable for anyone that wants to do leaderboard timing related stuff. At the moment the actual player's vehicle cant be determined in single or multiplayer due to sCarIndex always being 65535, and for MP sessions vehicles for any player can be determined for the same reason.

For me (RS Dash), this is really the only thing that is preventing me from being able to consider releasing a version using this.

Another minor issue is that there is inconsistency in the vehicle naming, some are formatted correctly, others don't contain any spaces. It would be nice if this could be cleaned up to be consistent for all entries. For example it outputs "PaganiZondaRevolucion" and "McLarenP1GTR" (ie no spacing), whereas in the same packet you can have correctly spaced names such as "Renault Sport R.S. 01 GT3" or "Mercedes-Benz SLS AMG GT3".

cjorgens79
21-07-2018, 04:47
Oh and if there is any chance of a structure change, we could do with having the penalty information for drivers in the telemetry (more so for the results, ie if they have a 10 second penalty we need to know about it so we can add it to their race time)

cjorgens79
29-07-2018, 02:21
I have also noticed that the participant based structures don't get cleared between sessions which means you can potentially end up reading data from a previous session.

For example if your previous session had 20 players, and you have now joined a new session which only has 10 players, the sTimingData.sParticipants, sTimeStatsData.sParticipantsStats and sParticipantsData all have data for 20 players. The first 10 are actually updated correctly, the extra 10 are in the same state they were at the end of the previous session. The only way to tell if they are valid or not is to look at the sNumParticipants in the sTimingData, which is fine for dealing with the sTimingData structure, but does not work for the other two structures as they are sent before the first sTimingData structure when joining a new session. The "left over" data means there can potentially be duplicate references in there, for example the sTimeStatsData which has the fastest laps for a player could have the same player in their twice (once for the new session and once for the old session if their array index was in the upper range for that previous session). This would result in potentially getting the wrong fastest lap data for the participant.

These issues can be easily solved by clearing the structures between each session.

Sampo
29-07-2018, 05:25
Why not just use sTimeStatsData only after you got the sTimingData? Does sParticipantsChangedTimestamp not work for those packets?

cjorgens79
30-07-2018, 13:14
Why not just use sTimeStatsData only after you got the sTimingData? Does sParticipantsChangedTimestamp not work for those packets?

can do, but it just means you need temporary data until then and you are discarding the vast majority of those informational packets that are sent when joining a session. It would be nice if we didn't have to put hacks in everywhere to deal with bad data. Some of the reports relate to cleaning up the interface data to make it easier and more logical for others to follow.

At this point though, I'm not sure that this thread is even being monitored by anyone at SMS, its been almost a full month since my earlier post about it being impossible to determine the player's or any multiplayer opponents vehicle and class. In the past (ie back with PC1) we had good communications, the report would have been acknowledged that they would look into it so you know it had been seen.

mr_belowski
14-08-2018, 13:33
Have you had any info about these bugs since this update? I'm still waiting for the version 2 UDP stream to actually be usable :/

Maskmagog
14-08-2018, 13:41
In the RSDash thread, the creator cjorgens apparently had some good news: http://forum.projectcarsgame.com/showthread.php?54342-RS-Dash-(pCars-Dash-successor)-companion-telemetry-app&p=1533513#post1533513

cjorgens79
14-08-2018, 13:44
Have you had any info about these bugs since this update? I'm still waiting for the version 2 UDP stream to actually be usable :/

Not sure about all the bugs reported, but the ones affecting the player and human MP opponents car/class detection have been acknowledged and noted for fixing.

davidt33
14-08-2018, 16:40
Way due needing addressing IMO.

Maskmagog
12-09-2018, 21:06
Anybody had a chance to see if anything's been fixed?

mr_belowski
13-09-2018, 06:35
I noticed the RainDensity now works correctly.

As for other stuff, no idea. I don't have the time or energy to go rummaging around in the data stream looking for stuff that might, or might not have been fixed. I really don't understand why SMS don't just *tell us* what's changed. It's quite annoying

cjorgens79
13-09-2018, 11:59
I did a quick test yesterday on the new version and the bugs affecting the player and human MP opponents car/class detection have not been fixed yet.

mr_belowski
13-09-2018, 12:04
thanks for the update dude, it saves me a pile of testing work

Maskmagog
10-11-2018, 19:55
Question: Does anybody get correct readings from sLastSectorTime (with UDP v2)?
I get the same value as sLastLapTime. Can't find an app that uses both UDP v2 and LastSectorTime to check. Chances are high that it's me who is messing something up, or possibly a bug in the library I'm using. But if it's a bug in the UDP stream we need to report it. Yes, I'm a diehard optimist. :)

EDIT: Nevermind, a possible documentation bug in the library (or a brain melt here). Indexes were shifted by 1. LastSector seems to work fine, as does FastestSector values.