I'm going to go into a bit of a lengthy story about motivation for this and why it should be done. For everyone wanting to skip the "personal" intro there willl be a bold caps lock text saying IDEA STARTS HERE a bit further down.

So, many of you probably don't follow Masters of Endurance nor really care but this is the story: most of racing games out there didn't have a proper support for endurance driving with takeovers (LFS being one of the first to offer the ability for a driver to take over). But even games who have the option of driver changes didn't really have the infrastructure to track overall progress when someone times out/disconnects etc. A few years ago WolleT (Tom) and Frankmd fixed this problem somewhat by inventing the MoE tracker which could deal with such issues as timeouts and it's worked well.

If it has worked well, why update it? This is my issue: my team has lost this season of MoE purely on bad luck concerning timeouts/hardware crashes etc. This wouldn't bother me so much, as it hasn't in the past when it would happen to other teams, if we hadn't taken every possible precaution to avoid such problems. In the past there were teams with unlucky drivers suffering from bad internet connections (such as F1RST racing with Chriskart - he is a great driver but they knowingly sent him into races knowing he would probably time out, imho a no-no). There's more examples of racers that suffered from bad electrical networks and computers going into BSOD days before the race that didn't do anything to avoid such problems in the race.

However, we take a different approach. When I had my first timeout that actually cost us the race (12 h race a few years ago) I would yell at my sucky ISP literally for a month, every other day to fix it. At first they said everything was normal, then they said some work was being done and the connection would remain unstable, then they didn't want to change MTU size on my locked modem, then I did it in Windows and it was better again, then all was supposedly fixed and worked ok for a few months and then it all went to hell again. During this first time it all went to hell I rewired my whole house (new UTP cat6 cable for both phone and modem leading all the way from my roof connection), changed 2 modems, changed 2 splitters and as a precaution before every stint I would restart both my modem and my PC. After it all went to hell again and they wouldn't fix it (mind you, as far as they're concerned my internet was working only I didn't have scheduled 24 h ip changes.. the connection would freeze/timeout at random intervals but it would reconnect almost right away.. so they didn't consider it a problem), I wen't so far as to pull ~20 meters of new cable from a neighbor who had another ISP and used his connection only for race days. This was the solution to the issue and I didn't have 1 timeout this season, however, my team mates weren't so lucky.

Another example of taking racing seriously: my GPU has been dying for nearly a year now, it starts having artifacts and losing picture. I've tracked this problem to microfractures in the soldering on the back of the card and I've found that people had been fixing this problem by baking the card for around 10 min @ 200°C in the oven. I did so and it fixed it, but it could die again at any moment after a month+ had passed. So, before every race I swapped my neighbor's new GPU for mine only for that day so I could be sure it wouldn't die during the race. Happily, I had no issues this season with any of the hardware or connections.

Other precautions we tried were leaving LFS online at the server for 24 h at a time several days before race day to see if there was any sort of a pattern to timeouts, regular reboots of both modem and PC before stints etc. Basically, we were not one of the teams that took timeouts for granted and said "if it happens it happens".. that's why when we still got ****ed by timeouts and other issues I decided that something has got to change.

IDEA STARTS HERE:

I contacted WolleT and we discussed possible ways of fixing these timeouts so that they don't cost people race victories or whole laps. Currently, if you time out in the last sector of the lap.. you've lost all that time, basically 1 whole lap if you're near the S/F line. We had that situation at 24 h race on Aston GP, our driver timed out literally 1.5 seconds before crossing the S/F line after a pitstop. So not only did we lose a whole lap, it was a 3+ minute pitlap. The first idea me and Tom had was to just add time that was already done in the lap by a timeouter, for example if you timed out 45 seconds into the lap - tracker would take those 45 seconds and give it back to you, so your timeout only cost you whatever time it took for your backup driver to connect and take a new car. This was ok for a first idea as timecodes would match up at the end of the race, but track positions wouldn't.

The solution was to automatically add a whole lap to the driver who timed out and when he (or backup) reconnected, they would take a new car and the pitlane would be closed for them until the time difference of [avg. lap time - amount of seconds they did in the lap when they timed out] ran out. So, just to put things into numbers: say a lap is 1:40 (100) seconds and the driver times out 25 seconds into the lap, that lap would be given to him in the tracker lapcount and after he had reconnected and taken a new car he would wait 75 seconds (100-25) in the pitlane. The tracker would have to do this automatically by checking if there is a disconnect flag (not regular disconnects, only timeouts and lost connection - but those 2 are one and the same flag in the MySql db of the tracker), taking the timestamp when it happened and subtracting the timestamp of when previous lap was finished, after that it would add a lap and make the driver wait in the pitlane for the amount of time that is [laptime - seconds done]. This method worked perfectly fine on paper and I've applied it to several timeout/disconnect situations that happened to several teams this season. Only problem comes up when someone times out on or around their pitlap as they could gain 40-50 seconds (however many seconds a pit + drive through pitlane took), so the tracker would have to have an input possibility for race admins to hold the driver an extra number of seconds.

I've told this idea to MoE admins and was met with the usual "if you make it work, we'll use it". Then I told it to boothy (who currently takes care of the tracker and updates it) and he said that he has no clue how he'd do/approach this because it would mean some features that he simply hasn't got the skills for. From my understanding, the tracker has a forehand and a backhand, first of which communicates with the web interface and updates the positions of cars etc, and the latter gathers information from LFS server. The new update would have to feature a two way communication with the LFS server (and this is where boothy is stuck), meaning something like Airio (I've already bothered EQ Worry with this, but he has no experience with PHP so he pointed me to Dygear ) it'd have to display a "red light" or HOLD message with some sort of countdown to a specific team number or S2 license and not to anyone else. Also the admin panel of the tracker would have to be updated with the possibility of manually adding a number of seconds to cover pitstops/penalties/etc.

I see this working in 2 ways, or at least being tested in 2 configurations:

1. Settings so that timeout costs you ~nothing, meaning the wait time would start from the moment someone took a new car on track (so it'd cover for the timeout and time it took for a new driver to reconnect). Only cost would be how much slower the outlap is compared to a race lap (3-5 seconds). Even this could be taken into account and HOLD time could be decreased by those few seconds.
2. Settings so that timeout costs you whatever it took for a backup to reconnect which can be anything from 10-15 seconds (plus the 3-5 sec from 1. case) up to minutes if you're a disorganized idiot.

This could be a personal preference of the league or admin, if they wanted timeouts to have nearly no effect on the race they could choose the first configuration. If they still wanted to motivate people to try and make sure they don't time out they could opt for the second configuration. Also, if we're talking about a shorter race of say 2-4 hours then even 20 seconds could mean the difference and that could be one of the situations where to use the first config, but if we are talking about a 8-12-24 h race then it's reasonable to assume that a timeout costing you 20 seconds is still better than one costing 2-3 minutes.

Even if you don't do endurance racing, you have to understand the frustration that comes with begin hands down the fastest team on the track only to be beaten by people who walk into victories after you time out. Especially since a season is nearly 6 months of one's life and it's not just a few days before the race for preparation if you're going to take it seriously. So, let's please fix this so that people stop lucking into championship titles.

First off, don't get me wrong, I feel for you. But the way I see it personally, is that a disconnection should be seen as a mechanical failure of the car, and as such it should be retired.

That said, I like the technical challenge this presents, and when I get some time I'd be willing to do this. But it would be in the forum of a PRISM plugin, and the whole solution could come from PRISM it self, down to the web interface as well.

Quote from Dygear :

First off, don't get me wrong, I feel for you. But the way I see it personally, is that a disconnection should be seen as a mechanical failure of the car, and as such it should be retired.

I agree, and as far as sprint races go.. if you time out, your race is over. But as we know, in real life good teams carefully track mileage done by each of the car's components and those are replaced well before their predicted fatigue life limit, and if you would compare that to everything we've tried to avoid timeouts.. then we should be pretty much failure free

However, this is a bit beside the point because as things currently are in LFS (which doesn't really simulate mechanical failures nor does one need to take care of the car as such, except for overreving the engine) endurance racing is done with timeouts and I'd just like to limit the consequences down to something reasonable.

Just something to throw out there for the future. If a car times out during an endurance race, it would be nice if the AI would take over the car and bring it to the pits where it can then be taking by over from by another player in that team.

Post here an example and I will try to think about it. I think it's good to rewrite boothy tracker as PRISM plugin, because in PRISM you have button system and timers that will help with many things later. Please post situation very strictly, move by move. For example:
1. driver lost connection on 1:15
2. driver connect back on the server
3. Average time for lap is 1:45, add an 1:45+10% lap to team stats and stop the driver for (avg lap time - 1:15 (time on disconnect lap) * 10%) 3s in pits.

This is an actual example that I displayed graphically from the 12 h race:

http://team-sirius.com/spdogt0timeout.png

The first bar is what actually happened and how tracker sees the actual timeout:

1. Driver got 29 seconds into the lap 119 and then timed out (time gone cause of TimeOut).
2. Conn represents the period from DISCONNECT flag until the driver connected back.
3. Pit in represents the time from when the driver connected back until PIT IN command was taken (shift p, entering garage, trying to take a new car).
4. Pit out represents the time from when the driver got onto the track until he crossed the start/finish line to start the new lap.
5. SP1/SP2/SP3 were timecodes when he passed each split on this new lap, with the final split being a LAP flag when the actual lap 119 was finished.
In this first case spdo gt0 team lost ~75 seconds compared to a no-timeout situation.

The second bar is what would've happened if there was no timeout, just a regular lap 119 and 120.

The third bar is what the new system would supposedly do in the "second" configuration (meaning time it takes for you to reconnect and take a new car is not taken away and a ~5 sec slower outlap). Only time given back would be whatever % of lap you finished before timing out.
In this case the team would've lost ~46 seconds compared to a no-timeout situation.

Ofcourse their reconnecting, taking a new car etc could've been much quicker so this could be < 30 sec ideally, but there should be an option to lose nearly 0 time cause of a timeout for sprint racing.

So, what the new system would have to do is:

1. Watch for a timeout/loss of connection flag, basically a non-planned disconnect.
2. Take the global timestamp of when this happened, substract the last global LAP timestamp - this would give the time in seconds which the driver did in this lap.
3. Add a new lap to the lap count.
4. When the specific team number (or one of 4-6 license names for that team) reconnected, they'd be displayed a HOLD message with a countdown. This countdown would be avg. laptime minus the difference from step 2.
5. Display a green flag/pitlane open to the driver so he can continue.

Quote from Dygear :

Just something to throw out there for the future. If a car times out during an endurance race, it would be nice if the AI would take over the car and bring it to the pits where it can then be taking by over from by another player in that team.

This could be useful but only if the AI would be the "ghost car" on track because as you know, they don't really look left/right or move off line for passing traffic etc, so letting them drive for let's say a full lap of Aston GP or an even longer open configuration (which again I don't know if they even can?) would be a bit dangerous to the other teams and drivers on track.

Quote from scipy :

The solution was to automatically add a whole lap to the driver who timed out and when he (or backup) reconnected

i particularly paid attention to the start of the second part, and adding the 1 lap would be great.. but would only work imo if the rules in the league stated that you had to wait at the end of the pitlane and rejoin the track in the position your car left the track.

Quote from xtraction :

i particularly paid attention to the start of the second part, and adding the 1 lap would be great.. but would only work imo if the rules in the league stated that you had to wait at the end of the pitlane and rejoin the track in the position your car left the track.

The idea is for this to be done automatically.. ofcourse all the drivers would be introduced to the idea via some youtube video explaining how the new timeout system works etc, but there'd be a huge red light saying PITLANE CLOSED and a countdown till green light etc. Just saying, it's not like someone could just take a new car and continue racing.. he'd get spectated by the software or incur some kind of penalty.

yea i understand people will pull the plug on their internet if they have engine damage or something, would be abusing the system. would take a high level of admins and a lot of them to see if they did it on purpose etc.. but i guess that happens anyway

Quote from xtraction :

yea i understand people will pull the plug on their internet if they have engine damage or something, would be abusing the system. would take a high level of admins and a lot of them to see if they did it on purpose etc.. but i guess that happens anyway

That's why admins should be able to input extra time to the "hold", just to cover people trying to skip pit laps or fixing their engine damage. But I don't think I've noticed someone with such extensive engine damage that it warrants a shift+P since the first season it was introduced. Well, spdo GT1 did have that situation in the 24 h race this season, but they took the -1 lap fairly.

So, we need extended InSim for that. Setting power of car and getting more damage datas. Setting fuel and getting it it's needed too, because we have to clone cars after TO.

Second thing is - AI can take car and go to pit. Here we need to an extended InSim to control server AIs or AIs on admin computer.

The AI thing was obviously out of the scope of this right now, it would be something that Scawen would have to work on. But as far as getting information about the engine we can get that from OutSim or OutGuage. PRISM could handle this without any problems at all if I add the OutSim packet to PRISM. This way we can monitor the engine temps of each of the car.

But then, every driver have to run PRISM on his computer. We need solutions that do not need any additional software on drivers computers.

I'm not so sure about that, I think that every driver would have to setup OutGuage, and then provide the connection details to PRISM some how, so that PRISM could listen for the OutGuage packet from their client. But there should only be the need for one instance of PRISM, and that's on the server side. But I don't know if OutGuage packet's will route outside of a local network, I've never tried it.

I think it will work only this way:

So drivers connect to main PRISM on server. This server instance will parse packets from every driver and from LFS Servers so it will have much to do.

Every solution is very hard to do and will take a lot of time. Some additions to InSim will help us, InSim programmers, and developers to make LFS more interesting.

Like I said somewhere else: if InSim will be allowed to set/get fuel, power, weight of car and maybe detailed damage (get and set, set to restore car after TO), LFS will be more interesting and this can give dev's time to develop S3 or new content for S2.

I'm pretty sure that PRISM can handle the extra load, even if the update was say, 1 time a second, times 32 players.

Quote from Dygear :

But as far as getting information about the engine we can get that from OutSim or OutGuage. PRISM could handle this without any problems at all if I add the OutSim packet to PRISM. This way we can monitor the engine temps of each of the car.

Couple of things:

1. Correct me if I'm wrong but engine temp is currently a constant (tha gauge is not connected to anything), and neither so are oil temp or oil pressure. This would be a great idea to check engine damage (well, only the oil pressure really) when it is implemented, but for now this would be a waste of time. The only way to really check for this is with the same driver in the car and just looking at corner exits and top speeds on the following straights at the same lap count in two different stints.. Basically, don't worry about engine damage. People are only going to simulate a TO to avoid receiving a 1 lap penalty if the laptime drops enough so that time lost cause of it is larger than the 1 lap penalty split across the number of laps until race finish. I don't think there's been an incident involving faking a TO in a long long time (however, with this new system there's more incentive to try).

2. As far as cloning the car conditions after TO. This would probably be useful for sprint races, but during a long endurance race this is not critical since pit schedule can be adjusted to take timeouts into consideration (as it has been done up until now). However, I guess it could be useful to fuel the car to levels so that it does its' original number of laps in a stint and tactics remain intact but there would be another problem with that - you cannot put on worn tires. This might not seem like something of great importance, but if you ever tried to drive a setup made for a specific fuel load (say nearly full tank) on a drastically lower fuel load (and new tires) it does not behave anything like it's intended to (and no amount of antiroll bar adjustment will help). The situation is different when the fuel load is decreased in increments as the tires wear, then the car feels just better and better. You can either take my word for this or go try for yourselves.

If we need setting temp. of tyres we have to contact Chudy_2001 and ask dev's for permission.

Again.. Why are u worrying about these things? Tire preheating is available in hotlapping, in order for it to be used on the server it'd have to use a modified LFS.exe and you'd have to chage memory values on the fly on other people's computers. Not only does this open up a lot of potential for crashing of LFS.exe but I doubt that even I would give you access to my LFS.exe during an endurance race.

Please, let's stop worrying about engine temps, tire temps and everything else. Just concentrate on implementing this rather simple mathematical model: TO -> add 1 lap -> hold driver for [lap - time done before TO]. Done.

There's around a month (or two at max) to make a working model of this idea, test it and implement it. No time should be wasted on things such as non-existent outgauge packets, on the fly changing of memory values etc.

I'm not trying to sound harsh or diminish the value of your ideas, they would probably be welcome additions once there's infrastructure to support their legal implementation, but for now they are both unnecessary and futile.

Yeah. Can anyone rewrite plugin of boothy tracker to PRISM? It's only saving datas. Then we can work on this problem. I can provide server for testing it (LFS server and maybe prism too).

Though I can't really see, why this would be necessary, I'd have a request to those, who will be doing this:

Please do not give any players their extra-lap by faking a split- and/or laptime, thus virtually creating an extra-lap in middle of all the others.
Instead this should be handled via a "negative penalty lap", thus simply overriding the lapcount (as is currently done by substracting a positive value per rejoin from the lapcount).

Then, instead of finding some way to hold the rejoined driver in place, one might additionally consider to do a similar thing with the total racetime, by giving the racer/team a time penalty corresponding to the part of the laptime the driver wasn't able to do. (which might be difficult as there may be cases, where you's have to get an average lap out of nowhere or the lap the disco occured in was a very bad one and additionally it occured late on that lap giving you a negative time to wait )
Or (my favorite): Give a penalty corresponding to a certain percentage (e.g. 105%) of the team's average lap. This of course can only be done AFTER the race in the results. For live timing one could come up with a note/display that a time penalty for a certain amount of rejoins is pending and will be added later on.

Apart from - in my opinion - being the by far simplest and thus easiest to implement of all ways (you'd only have to implement "negative penalties" and time penalties, no other freaky stuff like holding cars in place or keeping them from rejoining), doing it that way one would preserve a maximised compatibility with results from alternative evaluations

Quote from avetere :

Please do not give any players their extra-lap by faking a split- and/or laptime, thus virtually creating an extra-lap in middle of all the others.
Instead this should be handled via a "negative penalty lap", thus simply overriding the lapcount (as is currently done by substracting a positive value per rejoin from the lapcount).

Then, instead of finding some way to hold the rejoined driver in place, one might additionally consider to do a similar thing with the total racetime, by giving the racer/team a time penalty corresponding to the part of the laptime the driver wasn't able to do. (which might be difficult as there may be cases, where you's have to get an average lap out of nowhere or the lap the disco occured in was a very bad one and additionally it occured late on that lap giving you a negative time to wait )

So, let me get this straight. First off, no one would be faking splits and/or laptimes in the "middle" of all others. What would be done is what you describe: just add a lap same as they can currently be taken away for Shift+P penalties and such. However, in your idea the reconnecting driver would just continue driving right away and would later be given a time penalty (like DT or SG added after the race), but the track positions wouldn't match at all after the reconnect. How would one keep track of gaps if there are several hours left until race is over? If you propose serving the time penalty right after the reconnect, then what is the difference (other than your idea would still produce mismatches in track position and timing after the initial reconnect)?

Why wouldn't you just have the system automatically hold the driver as soon as they've reconnected and have everything (timing and track position) be correct as soon as he starts the lap? If you are so against tracker showing this 1 extra lap for the duration of the reconnect.. then fine, the extra lap can be added after the driver finishes the first lap after reconnect. I don't quite see the need for it, but ok.. As things currently are with the tracker, a team that has timed out doesn't know who they're racing until they finish 1 lap after timeout, at least this way they'd know their position has stayed the same.

Quote from avetere :

Or (my favorite): Give a penalty corresponding to a certain percentage (e.g. 105%) of the team's average lap. This of course can only be done AFTER the race in the results. For live timing one could come up with a note/display that a time penalty for a certain amount of rejoins is pending and will be added later on.

Why would you give the team 105 % of their avg lap? That is several seconds of pure penalty for what? Laps shoud either be taken as average of the previous 2-3 laps (excluding some huge crash or incident) or as a laptime guessed by the admins for the 45 % rule calculation (i.e. avg lap over a stint, but then teams can again lose or gain up to 1 second depending on fuel load they were on at the moment of TO).

Again, doing this after the race means the track positions and timing are out of sync until the race is over and you have no idea who you are racing.. Plus, why would you give a team a penalty for a certain amount of rejoins? It's not like their objective is to time out or have hardware problems, trust me, it's annoying enough when it happens and the rage experienced by the person who timed out is penalty enough.

Quote from avetere :

Apart from - in my opinion - being the by far simplest and thus easiest to implement of all ways (you'd only have to implement "negative penalties" and time penalties, no other freaky stuff like holding cars in place or keeping them from rejoining), doing it that way one would preserve a maximised compatibility with results from alternative evaluations

Everything you've said simply doesn't work during the race, it's a manipulation of results afterwards and the whole idea is to be able to race from and for a position you were in before timeout.. One more thing, holding a car in place (which in this case is same as keeping them from rejoining) is freaky? Why? In real life there are pitlane lights which serve specifically for this purpose.

In short, your idea not only doesn't solve the problem at hand, it makes racing for position on track impossible and I thought that everyone wanted to see that actually happen instead of results manipulation after the race?

@ avetere
How many MoE races or other endurance races under ur belt? None?
If you've never been in these sort of situations it's easy to suggest things that wouldn't work.

Quote from ivantod :

@ avetere

Be nice.