View Full Version : Weird behaviour from UDP

11-01-2018, 20:34
Hi all,

Been trying to figure out how to get race date through UDP on node js. My code is below and it doesn't do any parsing yet. However, when listening to UDP messages I see this.

I pick a car (Dallara IR-12 Chevrolet (Road Course)) I start a race and then I see this message coming in:

server got: c[߬Dallara IR-12 Chevrolet (Road Course) from size 1164

disregarding the weird stuff at the start (I'm thinking this is some sort of encoding issue) I'm going back in to the menu, pick a different car (Caterham SP/300.R) but now, when entering a race I see this:

server got: �7�n��Caterham SP/300.Rrolet (Road Course) from size 1164

What's up with the "rolet (Road Course)" at the end?? How is the previous car name still in there partly? Any thoughts?

My NODE code:

const dgram = require('dgram');
const server = dgram.createSocket('udp4');

server.on('error', (err) => {
console.log(`server error:\n${err.stack}`);

server.on('message', (msg, rinfo) => {
console.log(`server got: ${msg} from ${rinfo.address}:${rinfo.port} size ${rinfo.size}`);

server.on('listening', () => {
const address = server.address();
console.log(`server listening ${address.address}:${address.port}`);


11-01-2018, 23:55
This is killing me, I've tried getting different results using Python (instead of Node) using the pcars library of jamesremuscat

Set the UDP version to one in the game and get the exact same results:
"Caterham SP/300.Rrolet (Road Course)"

How is this possible? Can the UDP api from Project Cars 2 even reliably send out car and track names? Any working examples out there?

12-01-2018, 00:07
Is it possible the problem is on your end, not the UDP stream? It looks as if the msg buffer is not getting cleared and the previous contents are still in there. I dunno...I'm not a JS guy so I could be talking out my ass here.

12-01-2018, 21:43
the string is null terminated. The encoded string in bytes will have a null character in there somewhere (a zero byte) - this marks the end of the string. All the characters after that null should be discarded and may contain junk. Whatever you're using to decode the string will probably have a null-trim method or option somewhere.

The string is encoded using the platform default encoding. You might know what this is - ps4 is generally UTF-8, windows and xbox depends on the region settings. If you don't know what the encoding is you a bit stuffed. Only a bit because most of the string data will be lower byte characters (<127, so ascii) which means they can be decoded using most standard code pages and look OK.

Here's where it gets a bit challenging... Not only is the encoding of the data unknown (it may or may not contain multi-byte UTF-8 characters), but if the game encounters a character it can't encode with the platform's default encoding, it just barfs and gives up on the rest of that string. So if you have a driver name "Leonavičius" it gets as far as the 'č' char then falls in a heap. So you are sent an encoded string with 'Leonavi[null][some random crap]' (if I remember correctly - it might be even worse and skip the null in this case, it's been a while since I was in that part of the code).

It's even more fun if the character that's not in the platform default encoding is the first character of your string. Who knows what the string will contain. It depends on what that field in the data contained the last time it was successfully written. So maybe a different driver name / car name / track name.

Some tracks have weird characters in their names. Laguna Seca is one. No idea why but this contains a single character not in the default Windows codepage (cp1252). I guess it's the same for some car names. Some track names have underscores instead of spaces to separate words. No idea why - some of them even got changed from spaces to underscores after pCARS 2 was released.

If it sound like I'm ranting, it's because i am. It's a complete mess and makes the UDP data for pcars2 utterly unusable for me.

I've raised these issues (particularly the stupid default encoding thing) time and time again - it goes back to to the pCARS 1 days so it's been like 2 years or more.

What really winds me up here is that if the app receiving the data is on a different device to the system running the game, you have no way of knowing what encoding the game is using. It's crazy. The game is full of international driver names which have characters not in windows' default codepage so why can't the game just use UTF-8 all the time?

You should add this as a bug. Or not, because there's nowhere to report bugs in the APIs. I've given up on the pcars 2 UDP mode entirely. Apparently the PS4 version of the game sends empty strings for all the driver names.

18-01-2018, 11:38
Actually missing proper approach to character encoding is PIA in games since I remember. Which I cannot understand, especially since those games are dedicated for multi-langauge communities.
For example rf1 allows to enter characters with diacritics (ie in driver name or chat) using OS default character set. It wouldn't be wrong if this character had not been put into utf8 encoded XML, without transcoding. You can imagine how XML parser reacts on higher byte win1250 character in UTF8 stream.

It was happening in a title released 10 years ago. If this approach continues nowadays, it's really shame.

18-01-2018, 11:47
Raceroom seem able to encode their Strings in UTF-8. No idea why other teams can't do this

18-01-2018, 15:38
because they don't care about it.
Of course having engine which is build over single-byte chars components requires some demand to improve. But my God, there was a lot of time to do that. And acually it's not rocket science and don't require months of mandays.

And actually, speaking about software which struggles with saving data into file, I'm not sure it's fair to blame it for missing proper support of character sets.