PDA

View Full Version : PCars 2 API Questions



skipptg
23-10-2017, 08:07
I would like to develop an app for PC2, using shared memory & udp. Is there a published API available, or do I have to go back in time 2 years and join WMD to get it? That doesn't seem to be an option. :)

Chawabax
23-10-2017, 12:06
I would like to develop an app for PC2, using shared memory & udp. Is there a published API available, or do I have to go back in time 2 years and join WMD to get it? That doesn't seem to be an option. :)

I tried already but was not able to find a good time gate

mr_belowski
23-10-2017, 12:51
The API hasn't been published yet so as far as I'm aware it doesn't exist in the game yet. Although some 3rd parties like SimVibe are, apparently, already using it because they require users to set pCARS2 ShareMemory to pCARS2 mode. Which is a bit odd.

skipptg
23-10-2017, 13:14
It's definitely in the game as RS Dash uses the PC2 mode for shared memory. I found an old example C# solution so that should do me for now. It would be nice if the engine HP/Torque figure was available in the PC2 output, if anyone is listening from the dev team :)

Wasserhase
24-10-2017, 12:17
Same holds for me! I want to control and external vibration module for a game seat. I already use the audio out for some bass shakers, but that's not quite what I am up to. I want to couple revolution speed with a vibration element.

So I thought about using the telemetry via UDP (or shared memory). If someone has an idea where to get this info, please let me know!

Wasserhase
24-10-2017, 12:18
Where did you find it?

ZulfoDK
24-10-2017, 12:45
Just a thought, but could you do a wireshark dump on the UDP port that PC2 uses?

mr_belowski
24-10-2017, 13:28
you could, but as the data is just a massive byte array you would have a hard time interpreting it :)

Siberian Tiger
24-10-2017, 13:39
I will try to nudge someone for Infos when it will be released... Stay tuned...

Siberian Tiger
24-10-2017, 18:33
Ok, got some Informations...

The Specifications are beeing finalised so the Release of the pCars 2 API Specs isn't that far away...

Will get back to you Guys when they are Released :)

Wasserhase
24-10-2017, 18:53
Ok, got some Informations...

The Specifications are beeing finalised so the Release of the pCars 2 API Specs isn't that far away...

Will get back to you Guys when they are Released :)

Thanks, appriciated!

With that API a lot of cool stuff is possible... much more than only some monitoring apps... it will be fun to tinker with some actuators and the telemetry...

Ensi Ferrum
24-10-2017, 20:01
Ok, got some Informations...

The Specifications are beeing finalised so the Release of the pCars 2 API Specs isn't that far away...

Will get back to you Guys when they are Released :)

Thanks for the answer.
But I know other other companies in the racing simulation business giving these particular information to the community weeks / months BEFORE the release!
Don't get me wrong Siberian Tiger, not your fault.
But what is so much complicated to CTRL+C, CTRL+V some code from Visual Studio to a Word document?
Missing comments in the code? Good code doesn't need comments.
If the code needs comments, I hand the work over to an apprentice or an intern.

Wasserhase
24-10-2017, 21:32
But what is so much complicated to CTRL+C, CTRL+V some code from Visual Studio to a Word document?
Missing comments in the code? Good code doesn't need comments.
If the code needs comments, I hand the work over to an apprentice or an intern.

There could be millions of reasons: specs not stable, ressources needed for more pressing stuff, licensing issues, unsure of pricing,...

Frankly, Im grateful that there is a working interface available for free after all. A project like this game is hard work and despite all thats still not perfect and flawless yet the guys did a good job.

skipptg
25-10-2017, 07:32
Awesome, another entitled whiner. Be grateful they even release it at all.

That said, please add BHP/Torque outputs and ride height values. :)

tutoo
26-10-2017, 06:59
Although some 3rd parties like SimVibe are, apparently.

Dealman
26-10-2017, 12:30
But what is so much complicated to CTRL+C, CTRL+V some code from Visual Studio to a Word document?
Missing comments in the code? Good code doesn't need comments.
If the code needs comments, I hand the work over to an apprentice or an intern.

If only it was that simple.

The commenting is meant to describe what something is supposed to do, with the key word being supposed. What are most bugs? Code that does not do what it's supposed to do, thus having proper comments describing what a function is supposed to do will not only help you - but also others working with/for you to improve the code further.

This is true for API, sure they could probably just hand us a list of functions and we could tinker with it and find out what it does by ourselves. But honestly, that's a rather poor and not a very professional way of doing things. I'm glad they're taking their time with this, making sure things work and are nicely documented so even aspiring beginners can jump into it and have fun.

Not using comments doesn't make you professional - quite the opposite I would say.

Bealdor
28-10-2017, 11:51
https://www.projectcarsgame.com/project-cars-2-api.html?lang=en

skipptg
28-10-2017, 13:08
Thank you! Converting to C# library now...

skipptg
28-10-2017, 13:46
unsigned short sSuspensionRideHeight[4];

This seems to be in the UDP stream but not shared memory, or is it called something else?

skipptg
28-10-2017, 18:25
float mEngineTorque; // [ UNITS = Newton Meters] [UNSET = 0.f ] [ RANGE = 0.0f->... ]

The figure I'm getting through for this isn't anything like the NM figure reported in the HUD page. <confused face>

For example these are the max torque figures the API is reporting giving it max throttle through all gears (6th not revved out). This is way higher than the HUD reports.

https://www.intonet-technology.co.uk/public/PCars/McLarenP1Torque.png

skipptg
28-10-2017, 19:32
Ok I'm guessing this might be to do with gear ratios, but even so the numbers don't make sense to me. For example taking a simpler car, the Formula R.

Final Drive 3.444, 4th gear 1.125.

When the api Reports 106 nm (vMax around Daytona oval) the HUD is showing 78 nm.

I can't make those figures correlate. It's always out by a factor of 1.36.

Ok, 1.36 is the conversion from NM to lb ft. Doh! The HUD is reporting NM when it should be reporting lb ft instead.

eracerhead
28-10-2017, 20:07
unsigned short sSuspensionRideHeight[4];

This seems to be in the UDP stream but not shared memory, or is it called something else?

Nice to see ride height in there, as it's been missing in third-party telemetry since PC's inception.

nabezokodaikon
01-11-2017, 22:43
I watched the data as UDPAPI of PCARS 2 was released, but sTelemetryData-> sTyreCompound is blank. The tire name should be included ....

nabezokodaikon
02-11-2017, 01:27
Where did you find it?

It was on the official page.
Menu > PROJECT CARS2 > HELP > API FOR EXTERNAL APPS

MerlinC
02-11-2017, 10:00
Downloaded the current API version and was looking inside the "sharedmemory.h" what signals are going to be provided.

Looking at the tire temps it seems that pCARS is not providing any information about the temperature distribution across the tyre surface - which is one of the basic information needed to make setup changes like camber adjustments.

Is there any change that we will see inner/middle/outer temperature for every tyre in the future?

Furthermore the mixture of units for temperatures (sometimes kelvin, sometimes celsius) is a little error-prone.


// Wheels / Tyres
unsigned int mTyreFlags[TYRE_MAX]; // [ enum (Type#10) Tyre Flags ]
unsigned int mTerrain[TYRE_MAX]; // [ enum (Type#11) Terrain Materials ]
float mTyreY[TYRE_MAX]; // [ UNITS = Local Space Y ]
float mTyreRPS[TYRE_MAX]; // [ UNITS = Revolutions per second ]
float mTyreSlipSpeed[TYRE_MAX]; // OBSOLETE, kept for backward compatibility only
float mTyreTemp[TYRE_MAX]; // [ UNITS = Celsius ] [ UNSET = 0.0f ]
float mTyreGrip[TYRE_MAX]; // OBSOLETE, kept for backward compatibility only
float mTyreHeightAboveGround[TYRE_MAX]; // [ UNITS = Local Space Y ]
float mTyreLateralStiffness[TYRE_MAX]; // OBSOLETE, kept for backward compatibility only
float mTyreWear[TYRE_MAX]; // [ RANGE = 0.0f->1.0f ]
float mBrakeDamage[TYRE_MAX]; // [ RANGE = 0.0f->1.0f ]
float mSuspensionDamage[TYRE_MAX]; // [ RANGE = 0.0f->1.0f ]
float mBrakeTempCelsius[TYRE_MAX]; // [ UNITS = Celsius ]
float mTyreTreadTemp[TYRE_MAX]; // [ UNITS = Kelvin ]
float mTyreLayerTemp[TYRE_MAX]; // [ UNITS = Kelvin ]
float mTyreCarcassTemp[TYRE_MAX]; // [ UNITS = Kelvin ]
float mTyreRimTemp[TYRE_MAX]; // [ UNITS = Kelvin ]
float mTyreInternalAirTemp[TYRE_MAX]; // [ UNITS = Kelvin ]

Diluvian
03-11-2017, 09:50
@MerlinC it seems only the UDP version has the inner/middle/outer temperatures

MerlinC
03-11-2017, 10:03
@MerlinC it seems only the UDP version has the inner/middle/outer temperatures

Quickly looked that up in the UDP Definition file - and you are right there you can find the telemetry data. What I do not understand is that there are different data types defined dependend on the communication interface (Shared Memory, UDP) being used. If you read there Web-Site UDP is supposed to be used in those cases were shared memory isn't possible. But no indication that the level of information is different.

Quit confusing and error prone software architecture.



struct sTelemetryData
{
static const unsigned int sPacketSize = 374;
PacketBase sBase; // 0 12
// Participant info
signed char sViewedParticipantIndex; // 12 1
// Unfiltered input
...
unsigned char sTyreFlags[4]; // 136 4
unsigned char sTerrain[4]; // 140 4
float sTyreY[4]; // 144 16
float sTyreRPS[4]; // 160 16
unsigned char sTyreTemp[4]; // 176 4
float sTyreHeightAboveGround[4]; // 180 16
unsigned char sTyreWear[4]; // 196 4
unsigned char sBrakeDamage[4]; // 200 4
unsigned char sSuspensionDamage[4]; // 204 4
signed short sBrakeTempCelsius[4]; // 208 8
unsigned short sTyreTreadTemp[4]; // 216 8
unsigned short sTyreLayerTemp[4]; // 224 8
unsigned short sTyreCarcassTemp[4]; // 232 8
unsigned short sTyreRimTemp[4]; // 240 8
unsigned short sTyreInternalAirTemp[4]; // 248 8
unsigned short sTyreTempLeft[4]; // 256 8
unsigned short sTyreTempCenter[4]; // 264 8
unsigned short sTyreTempRight[4]; // 272 8
...
}

skipptg
03-11-2017, 10:08
Actually I understood it that UDP is the backup and Shared Memory was the preferred method, *because* it allowed more data through. I don't think this API is fully mature yet, in any case.

MerlinC
03-11-2017, 10:12
Actually I understood it that UDP is the backup and Shared Memory was the preferred method, *because* it allowed more data through. I don't think this API is fully mature yet, in any case.


... and if UDP is the backup for shared memory and shared memory is the preferred solution to go with we would all think that the data submitted is identical, wouldn't we?

I'm concerned that you are right that the API part of the software is pre-mature as well.

skipptg
03-11-2017, 10:14
Was the Shared Memory Api in PC1 more exhaustive than UDP? I'm sure I read that somewhere. Either way it seems remiss for them to be so out of sync. Some of the fields are also hard to fathom what they actually represent too.

Diluvian
03-11-2017, 10:17
Shared memory is PC only and iirc it's the most efficient (fastest) way to share data between different running programs (e.g. pcars2 and the telemetry app) which could be perfect to sample the data in a high frequency. UDP is a transport protocol which can be used to stream the data through the network (e.g. to your android device but you can still use this, too, to send the data to another app on your PC but not as fast as shared memory (iirc)) and is available on all platforms (xbox,ps4,pc).

I don't know either why the data differs between those two.

I just really hope that there will be soon a telemetry app which is capable of capturing all those data send via the UDP protocol :(

MerlinC
03-11-2017, 10:21
Shared memory is PC only and iirc it's the most efficient (fastest) way to share data between different running programs (e.g. pcars2 and the telemetry app) which could be perfect to sample the data in a high frequency. UDP is a transport protocol which can be used to stream the data through the network (e.g. to your android device but you can still use this, too, to send the data to another app on your PC but not as fast as shared memory (iirc)) and is available on all platforms (xbox,ps4,pc).

I don't know either why the data differs between those two.

The only rational I have is that two independent teams are working on the API interface for "shared memory" and "UDP" ?! Do we have to issue a bug report know for an inconsitent API interface?

mr_belowski
03-11-2017, 10:31
SMS are aware that the UDP data and shared memory data are inconsistent and incomplete in difference places, and need to be sorted out. The reasons for this are partly historical - shared memory came first, UDP was added later with additional fields that weren't back-ported to shared memory.

My understanding (and this may be incorrect) is that there'll be some work to fill in the missing data and fix some of the issues when other more pressing things have been sorted out. From my perspective, I don't think the pcars2 UDP implementation is ready to be used and I'm holding off completing the Crew Chief UDP work until it is - hopefully it won't take too long

nabezokodaikon
05-11-2017, 11:03
Where can I report UDP malfunction?

mr_belowski
05-11-2017, 20:30
not sure - maybe post a new thread here?

nabezokodaikon
05-11-2017, 23:48
let's do it.

nabezokodaikon
06-11-2017, 07:26
Two questions about telemetry information on game screen.
Do you represent something on the image curve?
What does the cm next to BUMP stand for?244611

CXR PhilGDUK
06-11-2017, 07:31
Two questions about telemetry information on game screen.
Do you represent something on the image curve?
What does the cm next to BUMP stand for?244611

cm = Centimeters

I'd love this bit of info in the apps, would be nice for setting up the car.

nabezokodaikon
06-11-2017, 10:08
Thank you response.

But sorry.

I know that cm = centimeters.
With UDP of PCARS 2, TRAVEL is sTelemetryData.sSpensionTravel, HEIGHT is sTelemetryData.sRideHeight, and I do not understand the remaining BUMP and curved bar.

skipptg
06-11-2017, 20:07
There doesn't appear to be any field in shared memory which tells you the type of tyre fitted - can we have that please?

nabezokodaikon
06-11-2017, 21:20
I'm sorry. I am not good at English.
Does it mean that there is no way to acquire that value now?

AndrewTurner
01-12-2017, 01:27
Hello,

Wondering if anyone can help out with a UDP C# project. The datastream i'm receiving produces the following String when using ASCIIEncoding.ASCIIGetString() method. I'm using a new thread to run the UDPClient but haven't included all the associated code below, only the byte array i'm receiving. This is what my string conversion produces. Does this look correct?

"??\u0002\0Qx\u0001\0\u0001\u0001\0\u0002\0\0?\0\0\n?\0?\0?\0Q\0:\0??\0?\u000e?2>4]q>W\n?.\0`d\0???@rJ??\u0018???:C\v;8?!??6d>????\u001d???=3d>~\u00024???h?x\"?8'??;??x??u?@\u0019$??????nt?@I?4?\0\0\0\05B\u0001??.??\a\a\a\a\u0006\0\0\0\u0001?[<??]<???<?M?<\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0???\0`??\0?7?\0?5???Q?\0\0\0\0\0\0\0\0N\0%\0%\0%\0P\0<\u0001<\u0001<\u0001>\u0001>\u0001>\u0001>\u00014\u00014\u00014\u00014\u00015\u00015\u00015\u00015\u00015\u00015\u00015\u00015\u0001\0\0+\0+\0+\0\0\0+\0+\0+\0\0\0+\0+\0+\0B??<\u0003??<DV\"=??\"=\u007f\u0018t>?4?<X[\u001c=:X\u001c= ?\"???]<???<?M?<S?\f>\0\0\0\0\0\0\0\0\0\0\0\0?Jz?\u0003\0\u0003\0???\0i\0i\0\0\0?CL8\u0013?\0\0\0\0\n\0\0\0\0\0Soft Slick\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0Soft Slick\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0Soft Slick\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0Soft Slick\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\n?ZFs?YB?s??^&?Cr"


Conversion Code

UdpClient c = (UdpClient)((UdpState)ar.AsyncState).c;
IPEndPoint wantedIpEndPoint = (IPEndPoint)((UdpState)(ar.AsyncState)).e;
IPEndPoint receivedIpEndPoint = new IPEndPoint(IPAddress.Any, 0);
Byte[] receiveBytes = c.EndReceive(ar, ref receivedIpEndPoint);

string receivedText = ASCIIEncoding.ASCII.GetString(receiveBytes);

Thanks in advance.

SenorPez
05-12-2017, 15:17
String data is UTF-8, not ASCII.

OOPS.

mr_belowski
05-12-2017, 15:59
If only that were true. The string data is 'platform default'. It may be utf-8 or Cp1252, or something else depending on the platform