It seems like the lap time counter resets to 0 once it reaches 256 minutes. This causes a problem with the Qualif mode of RaceManager, with the server set on Practice. People are allowed to race as many laps as they want, and RM tracks the best laps for everyone set on the server for a whole week. But, when spending some time in the garage, the timer can often be close to or over this limit.

Since S2, we've seen a few laps such as:
SP1: 255:05.62
SP2: 255:27.41
Lap time: 0:02.04
This example is quite obvious, but there are times that would be a lot harder to detect.

Would it be possible to increase the maximum number of minutes, or having Insim sending a LAP error message of some sort (or set the lap time as 0:00:00 or 255:99:99), as well as resetting the timer when someone exits the garage (I think that's when it happens)?

This requires a change in the InSim protocol

Minutes are coded on a single byte, allowing 255 as max value. As this case is not that frequent, I don't think the whole protocol need to be broken to comply with thgis specific case.
Impacted packets are :
IS_LAP : lap time
IS_SPX : split time
IS_RES : race result (races longer than 4 hours may cause pb also... more disturbing)


(YES TODAY IS THE BEGINNING OF MY HOLIDAYS!!!!)

the racemanger could look, if the lap-time is (much) smaller than one of the split-times... then you can recalculate the laptime, which should be a lap out of the pit, so you do not need this time.

@Bruce: It's true, it's probably not best to change the protocol for this, but using a 0, or the max possible value to warn that the lap time went over would be possible without changing the protocol at all.

@operator: The example I gave is obvious to detect, and can be ruled out very easily. However, there are cases where all the splits appear normal (go through SP1 just after the time goes back to 0), and can't be ruled out.

Also, it does happen mostly on the lap out of the pits, but it could happen as well on a flying lap. In any case, I don't think there is any way to detect it consistently without the server actually notifying Insim of it.

Quote from Silkswift :

(or set the lap time as 0:00:00 or 255:99:99)

255:59.99 *hides*

Anyway.. if it would not be changed serverside, we need a workaround. Either monitor the RTP reply and ignore laps that are done in a specified timespan or send a "/restart"? :scratch:

wouldn't it be better to sett all bytes to 255?

@Silkswift: mh, i think i know what you talk of...
you mean staying before sp1 for >255 minutes and then drive the rest of the lap?
mh, that would be hard to detect.
in this case you could send the player to pits if he stays out for >250 minutes

That's correct oper@tor. I didn't mention it like this though, because I didn't want to give too many details on how to "cheat" .

My "solution" for this would be to get rid of the thousandths byte and add an hours byte. I mean, thousandths is great and all for accuracy and detail, it's just I've never seen much of a use for it yet. LFS doesn't even show the thousandths part of the time to the user.

Of course, this doesn't do much good now. Will take an act of Scawen to make it happen

@stuff: then people could stay hours out on the track... who wants to cheat will find his way
@Silkswift: sorry for that, but i think there wont be too much people
and if so: its just the qualifying, so they will loose the race then

Quote from oper@tor :

@stuff: then people could stay hours out on the track... who wants to cheat will find his way

Quote from Silkswift :

set on the server for a whole week

1) ye, but 255 hours = 10 days, 15 hrs.
2) indeed, they could cut the track where it's possible. :shrugs:

Sorry for bringing this back up, but I don't see the problem. 255 minutes is 4.25 hours. Who is going to sit on a server, realistically, for FOUR HOURS in the pits?