I just want to clarify something from the IS_RES packet (result confirmation). From the InSim.txt doc:

Quote from InSim.txt :

struct IS_RES // RESult (qualify or confirmed finish)
{
byte Size; // 84
byte Type; // ISP_RES
byte ReqI; // 0 unless this is a reply to a TINY_RES request
byte PLID; // player's unique id (0 = player left before result was sent)

char UName[24]; // username
char PName[24]; // nickname
char Plate[8]; // number plate - NO ZERO AT END!
char CName[4]; // skin prefix

unsigned TTime; // race time (ms)
unsigned BTime; // best lap (ms)

byte SpA;
byte NumStops; // number of pit stops
byte Confirm; // confirmation flags : disqualified etc - see below
byte SpB;

word LapsDone; // laps completed
word Flags; // player flags : help settings etc - see below

byte ResultNum; // finish or qualify pos (0 = win / 255 = not added to table)
byte NumRes; // total number of results (qualify doesn't always add a new one)
word PSeconds; // penalty time in seconds (already included in race time)
};

The ResultNum is either the qualifying position for the lap or the race finish position. The documentation covers values from 0-255 (e.g. 0 = 1st position, 4 = 5th position, 255 = not given a finish position). However, in a qualifying session it's possible to get a value of -1 for the ResultNum. From testing I think this -1 value is received when the player completes a lap that is slower than their fastest lap in the session. So, for example, a driver does a 1:32.16 lap and that lap has a ResultNum of 0 (i.e. that lap was good enough for provisional pole). Then the same driver does another lap of 1:32.99 (which is slower than their 1:32.16 lap) and the ResultNum is -1. Am I correct in my thinking?

Hmm, I'm not sure how you're getting -1 because a byte is unsigned. Not sure of the conversion of -1 signed to unsigned but my guess is, the real value is 255.

Quote from Stuff :

Hmm, I'm not sure how you're getting -1 because a byte is unsigned. Not sure of the conversion of -1 signed to unsigned but my guess is, the real value is 255.

I'm using a Java library (JInSim) and Java does have signed bytes (max value 127, min value -128), but of course the values sent through InSim are unsigned, which I'd forgotten. Thanks.

Quote from amp88 :

I'm using a Java library (JInSim) and Java does have signed bytes (max value 127, min value -128), but of course the values sent through InSim are unsigned, which I'd forgotten. Thanks.

So the problem was that you where reading it as a signed byte.

Quote from Dygear :

So the problem was that you where reading it as a signed byte.

The library is, yes. The problem is that Java doesn't have unsigned bytes, so to be able to represent the range of an unsigned byte (i.e. 0-255) you would have to read the unsigned byte into a short (16 bits) or an int (32 bits).

It's strange that Java does not support unsigned data types. Whenever I've done anything regarding file formats or networking I've always run into a pretty liberal use of unsigned types. In my mind a byte is 0 to 255 and that's the way it should be represented. Take C# .NET for instance, in that all integer types are signed by default, except for the byte which is unsigned. Ah anyway, I don't wanna start a religious discussion, but it is strange.

Quote from DarkTimes :

Ah anyway, I don't wanna start a religious discussion, but it is strange.

Agreed, but to solution was found, and this thread has served it's use. Preemptive lock might be in order. (One waits and sees)

To get the correct result from the getResultPosition method that returns a byte just perform an bitwise & operation:

int resultPosition = resultResponse.getResultPosition() & 0xFF;

I'll keep in mine to update the getters for bytes so that this is performed internally.
e.g. change


to

Thanks