Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 46

Thread: PCARS2 UDP API Bug reports

  1. #11
    Kart Driver nabezokodaikon's Avatar
    Join Date
    Apr 2017
    Posts
    39
    Platform
    PC
    In rare cases the NaN value may be in the TIMINGS_DATA sCurrentSectorTime.

  2. #12
    Kart Driver nabezokodaikon's Avatar
    Join Date
    Apr 2017
    Posts
    39
    Platform
    PC
    The data size of sTimingsData#sParticipantInfo has change from 30Byte to 32Byte.

  3. #13
    Rookie
    Join Date
    Jan 2018
    Posts
    4
    Platform
    PC
    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

  4. #14
    Tools/App/Pitstops slave
    Join Date
    Aug 2014
    Posts
    4
    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.
    The following 8 users likes this Post: Brado23, jimmyb_84, Kafumanto, KAMPFBIBER81, Konan, Maskmagog, OddTimer, satco1066


  5. #15
    GT5 Pilot mr_belowski's Avatar
    Join Date
    May 2015
    Posts
    1,445
    Platform
    PC
    Quote Originally Posted by Martin Moravec View Post
    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
    Crew Chief details here http://forum.projectcarsgame.com/sho...r-for-PC-users
    Website, download link and forum: http://thecrewchief.org
    Or make a donation, if you think the chief needs to drink more beer:
    https://www.paypal.com/cgi-bin/websc...=LW33XFXP4DPZE
    The following user likes this Post: Maskmagog


  6. #16
    Tools/App/Pitstops slave
    Join Date
    Aug 2014
    Posts
    4
    Quote Originally Posted by mr_belowski View Post
    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.
    The following 3 users likes this Post: KAMPFBIBER81, M. -VIPER- Morgan, Reiche


  7. #17
    Superkart Pilot MaXyM's Avatar
    Join Date
    Nov 2011
    Location
    Prague
    Posts
    990
    Platform
    PC
    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.
    MSI Z270 Tomahawk | i5 7600K@4.9GHz | 16GB RAM | Scythe Mugen 4 PCGH | MSI GTX1080Ti + Accelero Xtreme IV | HTC Vive | TX+custom wheel+t3pa Pro | custom cockpit
    The following user likes this Post: AEIDOLONE


  8. #18
    GT5 Pilot mr_belowski's Avatar
    Join Date
    May 2015
    Posts
    1,445
    Platform
    PC
    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
    Last edited by mr_belowski; 16-02-2018 at 10:49.
    Crew Chief details here http://forum.projectcarsgame.com/sho...r-for-PC-users
    Website, download link and forum: http://thecrewchief.org
    Or make a donation, if you think the chief needs to drink more beer:
    https://www.paypal.com/cgi-bin/websc...=LW33XFXP4DPZE

  9. #19
    Kart Driver
    Join Date
    Sep 2017
    Posts
    8
    Platform
    PC
    Quote Originally Posted by Martin Moravec View Post
    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
    1. sometimes I received a packet with mPartialPacketNumber = 1 and mPartialPacketIndex = 2... clearly a big problem to collect the stream
    2. 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...);
    3. 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:
    1. ...
    2. eCarPhysics
    3. eTimings
    4. eCarPhysics
    5. eTimings
    6. eCarPhysics
    7. eTimings
    8. eCarPhysics
    9. eTimings
    10. ...


    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!
    The following user likes this Post: Martin Moravec


  10. #20
    Tools/App/Pitstops slave
    Join Date
    Aug 2014
    Posts
    4
    Quote Originally Posted by Kafumanto View Post
    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
    1. sometimes I received a packet with mPartialPacketNumber = 1 and mPartialPacketIndex = 2... clearly a big problem to collect the stream
    2. 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...);
    3. 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.

    Quote Originally Posted by Kafumanto View Post
    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:
    1. ...
    2. eCarPhysics
    3. eTimings
    4. eCarPhysics
    5. eTimings
    6. eCarPhysics
    7. eTimings
    8. eCarPhysics
    9. eTimings
    10. ...


    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.
    The following user likes this Post: Maskmagog


Similar Threads

  1. [BUG REPORTS] What I've found so far..
    By Brado23 in forum General Discussion
    Replies: 8
    Last Post: 27-09-2017, 04:02
  2. 2 bug reports
    By Skullblits69 in forum PS4 - Technical Help & Support
    Replies: 1
    Last Post: 18-05-2015, 17:49

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •