Would any backmarker XRR team have me on for 1 stint? :P

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.

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.

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.

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.

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.

I've already fashioned a solution that works pretty well, but I'll be ordering one next week just in case.

Tnx for the info.

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 :

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.

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.

Quote from dadge :

ah. have you thought about the hard mount screws?

Yes. I've already got 2 holes drilled through my desk and the wheel has been stationary for ~2 years before I took it off after last MoE race. But I need to be able to put it up and take it down quicker, so let's concentrate on the clamps and not many other suggestions.

Checked.. forum was kinda my last resort.

My left clamp broke cause I'm just so fuken powerful. Since left and right clamps are the same.. if anyone has a broken G25 and is willing to send the clamp only I'd be happy to pay for shipping etc.

Contact via forum pm.

Tnx in advance for all the hatemail

Just off the top of my head:

1. values for springs/damping etc, make it like LFS garage, right click on the arrow adds/substracts 10 in each direction, right click on the slider itself opens a window to manually input a value

2. make the whole program available in full screen

3. add numeric values to graphs on axes

Quote from Mysho :

I don't quite get what you are saying. Are you suggesting to put that feature of heating tyres on each tyre? If so, why would that be? I don't think that is necessary at the moment.

I think he's trying to say that in some specific cases (like SO4 and whatnot) left side tires are colder than right side ones, same with rear to front so he's suggesting individual tire warmers for each tire and not only front axle/rear axle. I don't think it's necessary either.

Yep, I was thinking of dog engagement sequentials, first thing that came to mind was a motorcycle. Should've chosen my words a bit more carefully But as Scawen said, doesn't change the point.

Although, Scawen, while we're on the topic of sequentials.. for one of the non-compatible patches in the future (especially one where you'll be doing GTR class rebalancing again) a good idea would be a true ignition cut sequential that kills ignition on half of the cylinders because the current ignition cut gearbox is slower in acceleration than a regular H-type with clutch of the FZR.

Last edited by scipy, Mon 6 Jun 2011, 15:18.

Quote from Scawen :

...

Scawen, one more small but useful request if possible. Being involved in an upshift debate in the hotlapping spinoff thread a problem that I noticed a long time ago has resurfaced. There is no way to export a .raf file on the dragstrip since you can only export your 2nd lap with the current system. Is there an easy way to fix the ability to export a starting lap of any race (but especially drag strip races since there you can't do really do a 2 lap race anyway)?

Pretty please.

Quote from Neilser :

bzzz

This is silly. Add me on MSN and be educated.

Then how is it unclear to you what I've said 2 posts ago? If you have an engine revving in neutral it's only going to produce enough power to cover it's inertia/friction/pumping losses. It is not making xyz hp @ 8000 rpm when you floor it in neutral - only when you try and stop it (like connect a resistance to it, then it'll be producing power - and only enough power to overcome that resistance, still not the full power).

If we're talking about a normal syncro gearbox with a manual clutch, like any older road car has, then I agree: since you have to clutch anyway, you will get an acceleration boost if you flatshift (clutching speed same in flatshift and non flatshift). But this has nearly nothing to do with engine inertia.. As you said in your post, power "rapidly" goes into increasing rpm but it's not using anywhere near "maximum" power (meaning power it has at those rpm when on the dyno or accelerating the car and overcoming air resistance, rolling friction, inertia etc).

In fact, if you payed attention when driving a real car you could notice that even when you shift normally (lift off throttle, clutch in, cluctch out, throttle back on) but trying to make it a pretty quick shift, you will still get a little boost from the engine inertia. This is because engine just isn't capable of decelerating fast enough (even when off throttle) to cover the 1500 or so rpm difference between the two gears. If you relied only on engine inertia to give you a boost (as you've said in your first post that your reasoning was that during the whole clutch period engine power was being converted into excess engine speed and this would in turn be converted back to acceleration on re-engagement), you would get only a differentially small increase in inertia that builds up from say 7000 where you shift to 7500 rpm where the hard limiter is, but > 90 % of the acceleration will come from simply engine meeting back with a resistance and trying to stay at the same rpm - starting to produce useful work.

Problem is that you took the FBM as an example.. where the limiter and the shift point are one and the same, so when you clutched on your flatshift.. where can the engine accelerate to? It will just keep bouncing off the revlimiter. The only thing that gives you the acceleration boost is when the clutch meets back with the engine, and in this case there was some positive slippage of the clutch that got converted back to acceleration but it's NOTHING compared to acceleration loss you've experienced during the period when the engine wasn't connected to the wheels.

Scawen modeled these transmissions correctly (as far as power/work/acceleration goes), there is no way you can gain acceleration by disconnecting the engine from the wheels and relying on increased rpm and subsequent slippage on re-engagement, over the dog-engagement gearbox. No matter if if the shift point was 6000 rpm or 9000. Well, it matters a bit because at 6000 rpm the sequential will eat you alive (because clutching there while holding the throttle on will mean that you have a good 4000 rpm for the engine to fight back against the clutch and slip it all to hell).

I think your main problem is not understanding how a dog-engagement gearbox really works. The shifts are very violent, in fact, more violent than a flatshift with a clutch.. but power delivery is nearly uninterrupted (in reality it is uninterrupted, the car will never go into opposite longitudinal G while accelerating), the components are very stressed but they're designed to survive.

Quote from Neilser :

Eh? When the throttle's fully open at high rpm and you disengage the clutch, the engine is still producing full power unless you cut fuel or ignition. The power just goes into (rapidly) increasing the engine speed. It's still real power. And if you can at least partially convert it back into road speed it's also useful real power.

Sry, don't wanna be dismissive but I'm not getting into energy/work/power discussion with you unless you are willing to go through thermodynamics 1 & 2, internal combustion engines intro and ICE construction first.

There is no power to speak of if something isn't using it on the other end. When you rev the engine to 8500 rpm in neutral, it makes no significant power. It's better to have 50 % being used than having none during clutch full engagement period.

FBM has a motorcycle gearbox, a so called dog-engagement. It's the fastest type of gearbox available (not that's it's easy on the transmission, but it is fastest), google some more about it and it'll be clear to you why clutching with a dog-box is a bad idea.

Short story, when you lift 50 % of the power is still being transmitted to the wheels during the shift because only a small unloading of the transmission is needed for next gear dogs to engage the gear into action. No matter how fast you clutch (and if clutching is let's say BF1 speed or even faster) there is still a complete separation of engine from the gearbox where no power is being transmitted, and on the other hand the period is so small that no significant engine acceleration can be made to give you that little "jerk" on re-engagement.

http://www.lfsforum.net/showthread.php?t=72359

Quote from Squelch :

My friend let me spell it out.

Listen flower, I understand english references well enough to know that obtuse means ur calling me thick/stupid/slow/<insert synonym>.

As far as clutching goes, it makes no ****ing difference weather gears are in neutral, in lower gear or next (higher) gear if the clutch is depressed, since rpm climbs because you're keeping the foot on the throttle. Your thinking on longitudinal G increases because engine picked up some revs and was being pulled back by the clutch on re-engagement also shows a lack of testing and knowledge on your part. While this is true to some extent, the amount of slip that was occurring even before the slip had any affect on temperature wasn't in the optimum range for acceleration. In fact, a much better result is gained when the engine bounces off the revlimiter quickly and is re-engaged with the clutch with less slip - especially since the main advantage of buttonclutch is removal of the full engagement clutch period.

As far as autoclutching goes, just because there are revlimiters in place now and shift lights have been removed from road cars it does not mean you shift at the limiter. In fact you shift at old shift points and engines in road cars still gains a few hundred rpm before being pulled back by the clutch.

Fact is, clutch heating model had little to no effect on making people stop flatshifting. I do appreciate that idiots are punished if they keep the throttle on after a spin going backwards in 3rd gear, or trying to start in said gear.

Quote from Squelch :

Ill-mannered: Your treatment of some forum members is frankly appalling. Treatment of AudiTT earlier in this thread is one such example of your insensitivity. Yes he was off the mark, but English is not his first language, and he relies on translation software to read these forums.

Flower please, at least find someone worth fighting for if you're gonna stand in defense of idiocy. His language skills were not the problem, it's the fact that every post of his was pure SPAM and no help to anyone that bothered me. I even ignored him for an amount of time that is simply unbelievable by my standards. Other people having to correct his wrong ideas/opinions/suggestions don't help your case at all.

My treatment of people have been increasingly more and more positive, but I do sometimes regress back to my old self. Don't be stupid and you won't have any problems with me. (Let me clarify, if you don't know something and you ask politely for an explanation, I'm the first one to respond with an answer in a positive way, or even recommend literature if you want to know more. BUT, if you are an ignorant arrogant twat who just writes things because they make sense to you but have no basis in reality - then I will insult you to the extent that you might think next time it's just better to not say anything).

Quote from Squelch :

Arrogant: Your ego leads you to believe I read your past posts. You're wrong. I was researching the clutch-button exploit, and came across your name in relation to cheating, that's all. You seem to believe your opinion is correct at all times, and I haven't come across a single instance where you admit to being incorrect - and no I haven't searched.

It's not my ego that leads me to believe anything, I just happen to be right more of the time. It's your lack of research skills that is impressive, for now you are basically wrong on almost all counts you tried to adress.

Quote from Squelch :

Let me stroke that ego of yours. Some of your posts are insightful, knowledgeable, and useful. If you could only respond in a similar way as this you might find you don't rub people up the wrong way.

While you might mistake this forum for a congeniality contest, I don't. Stupidity is annoying, I respond to it how I like. I might be the most hated person on LFS forum (and enjoy that status a lot), but whenever your protectees find themselves stuck, even after all the insults dealt directly to them, they come crawling to me for help.

Quote from Squelch :

Your post back then infers that the whole drive train needs refinement, and gearbox inertia is one of those refinements which could be made. I thouroghly agree with those observations.

Of course you do, because I'm right. Unlike most of the things you've written.

Quote from Squelch :

The ultra fast clutch that the exploit enables, bypasses any chance of a missed gear, and making autoclutch quicker is not the solution imo.

Wrong again.. If you had done any proper testing you would've found timing values where shifts simply stop happening.

Quote from Squelch :

Can we please agree to disagree on some matters, and not get personal?

Yep, I disagree with you on everything you are wrong about and agree on the things I've said. As far as being personal, you're the one calling people obtuse, ill-mannered and other adjectives, I on the other hand, enjoy arguing because it brings me great pleasure to point out where other people are being stupid or just wrong. However, since it's currently midterms time and I have only slightly better things to do, this is unfortunately my last post to you.

Quote from Squelch :

I'm not sure if you are being deliberately obtuse, ill-mannered, or plain arrogant.

Good trigonometry joke there! Imo, if anyone is being obtuse it's people who get things wrong post after post.. kinda like you do. Referencing things that supposedly stopped something from being an advantage when they did next to nothing about the "problem". I find that very annoying and plain ignorant.

As far as my manners go, if you really had a search through some of my previous posts, you would've noticed that the manner in which these posts were written is a drastic improvement in ways of how I've used to treat people like you.

Quote from PMD9409 :

I agree, brought a tear to my eye.

As long as the eye makeup u use is waterproof and goes with ur skirt, it's perfectly fine.