"We are all ignoring the massive irony in the fact that changing the actual game code to add a timer is allowed, but applying a cosmetic skin using the default features of the game is currently not allowed."

Because the timer changes nothing about the way the game is played ; while using add-on karts do change it.

"the game lets you add custom karts. custom karts are allowed because the game allows them. end of discussion?"

The game also let you edit config files, and it's obvious that altering them in any gameplay-altering way is not ok.

"Actually hold on, do santa hats change the hitbox?"

No, they don't change it.

"I still think the rule is dumb, even after all you've explained. It doesn't change enough to be worth excluding. It's a weight value with a shell. It's still the same game." Changes from vanilla who disadvantage the runner are ok, those who advantage him are not. The rule must be set in a way which enforce this. This can be by banning add-ons karts, or by having a set of rules under which they are ok which guarantees they can't be exploited to get an advantage.

You're mad because (under the current rules), your nice intermediate% run is invalid. I understand this, especially as in this specific case I don't think you really got an advantage out of it. Understand also that if we allow add-on karts in a way which can be taken advantage of, it becomes doable to gain a few dozen of seconds over a run by exploiting it (reducing caking at start, smaller hitbox for the player's kart, easier and quicker GP skips). @Kitoko and me currently hold the 0.9.3 any% and expert% two best times, and we don't want to have those obsoleted by a rule change.

"Here's my solution "All heavy and light karts must be removed from the game before play, all medium weight addon karts allowed (within reason)."" That's obviously wrong, because it would make vanilla runs invalid, which is absurd.

It's clear that it's easier to have a blanket ban on add-on karts than trying to figure out under which specific conditions it doesn't give an advantage. It's clear that those conditions do exists, but determining them AND checking them is a pain.

There are 3 classes of kart ; light, medium and heavy, with different acceleration, max speed, nitro consumption and a few other things. Each kart is assigned to one of them.

Balance : the AI opponents you get are determined at random fro the karts available. If there are 7 karts overall, 2 L, 3M and 2H, and you pick a M for running, you'll get on average 1/3rd of L, M and H as opponents. If you add-in 2 light addon-karts and pick the same M for running, then your opponents are 1/2 L, 1/4th M and H. This changes slightly how the race plays, and how difficult/easy it is to pull off a GP skip (because the positions don't change when you forfeit, and at the start of the race the lights always take the lead before the mediums and then the heavies)

Bigger should not be void if used by the player (it helps him slightly to get some powerups, but it also makes it much harder to avoid anything and is overall clearly worse), but probably should be for the AIs. They are weak anyway, but it would make them weaker.

For the balance, the issue is that the stock balance isn't an exact proportion of light/medium/heavy, there are significantly more mediums. Plus, there is the medium Sara which is unlocked along the way, so the proportion is not stable all along the run.

Maybe for each medium/light/heavy add-on kart, an equivalent unlocked-from-start stock kart should be removed ? That's the only way I can think of to keep the proportions exactly as vanilla...

I think the add-ons kart rule should be changed.

They should be fine imo, as long as they don't give an advantage compared to stock karts. I think this would make this run ok, wouldn't it ?

Mainly, that means they must not be smaller than the smallest stock kart of their weight size. If there are other things which may make a significant difference (wheels ? anything else ?) it should also be taken into account. The issue with that rule is that checking if an add-on kart is valid or not may be annoying ; so maybe we could have a whitelist approach : they'd have to be tested by at least two mods giving their greenlight, and we may have a thread where it would be possible to request the testing of another add-on kart.

Another side issue is that when running with an add-on kart, the overall balance of light/medium/heavy in the opponents change, especially if there are also add-on karts opponents. In 0.9.3, given that the AI karts are very quickly outran, this don't matter much (except slightly in the GP skips). However, this may matter in a future version so this should be considered.

I think that doing precompiled binaries for less advanced users is a great idea.

From what I see, the code in the fork is from the current master (which is bad because there are features differences from 0.9.3 which would affect a run) ; so I guess you just used it to be able to use the "releases" feature of github, but that the content of the binaries/source zip matches the 0.9.3 + timer patch as wrote in the description, correct ?

Edit : looking at the files change in the fork, I see you've applied my patch to the current master, which is incorrect, as these files have changed since then. The 0.9.3 patch has been done to match 0.9.3 release specifically by backporting the needed changes to the release code, replacing the whole files on another version is a bad idea.

Edit2 : ok, looking at the readme I see what you're trying to do. I rather suggest for you to wait. When I'll have improved the timer, I'll submit it to official master and it will be accepted for inclusion after maybe some tweaks. Then, you'll just have to do the pre-compiled binaries. And as a bonus, it will include NewGame+

My slipstreaming changes have been integrated.

Slipstreaming is going faster because of reduced air friction when going behind another moving object. In STK, it doesn't work exactly like that, it's only a simplified version where you collect credits with time and when you have enough you get a bonus if you stop following a kart.

Speaking generally, the visual effects now give a much more reliable feedback about the bonus accumulation/usage state ; while the bonus is easier to get due to several tweaks (before, if the kart followed changed its orientation slightly, that could be enough to move you out of the slipstream zone, this is not the case anymore), but not trivial in a normal race.

You can see the detailed changelogs here (there are some technical points but it's mostly understandable for someone who knows STK) : https://github.com/supertuxkart/stk-code/pull/3186 https://github.com/supertuxkart/stk-code/pull/3202

A video showing the (nearly final) effects (in a normal race on a normal track, there is much less slipstreaming, this is an extreme case) :

Just do as precise as you can for each loading sequence The error will be around one video frame, so over the course of the run this will be one or two seconds, probably.

You don't have to count the number of frames, you just note the time at the first loading frame, go frame-by-frame until you reach the last (VLC might not be good for this because it can't go backwards). Then you note the time at the last frame of loading and calculate the difference to get the loading time. That's what I meant by "rounding down" : if you take the time at the first frame of non-loading rather than the last of loading, you might calculate a loading time higher than it really was. By the way, the in-built timer will also count one loading frame, so this is better for consistency between the two.

The timer patch doesn't work for 0.8.1% anyway. I was speaking about a 0.9.3 any%.

For framecounting, see for example : https://www.vlchelp.com/frame-stepping/ Or : https://www.mltframework.org/docs/melt/

Yes, you do the sum of the loading times (rounded down as explained above) across the whole video. This gives you a total time spent in loading, which you note and remove from your RTA total time.

Good idea, sounds indeed more fun to rerun rather than to frame-count.

I may try to obsolete my own expert% run, would reduce the work to do.

@UbuntuJackson : The loading times are somewhere betwen 30-90s in the runs, I think that if your overall error isn't over 1-2s that's fine. I don't know what editor to recommend to you, I know I have already used a frame-precise editor at least once but I couldn't tell you.

You aren't absolutely forced to use the overlaid timer, you can also just substract the time of the first loading frame in the video editor to the one of the last loading frame to get the loading time. I suggested looking at the overlaid timer because it might be more convenient, that's not an obligation.

But maybe wait before doing a conversion, if we beat our times well enough with the timer patch so that it's better than the old times without loading time, then the conversion is unnecessary. You maybe could try to beat your own any%.

Overlaid = put on a layer over something. Basically the timers who aren't part of the game but who are put over it in the video by the runner, like the one from LiveSplit. From what I can tell, all the runs use one of those.

Frame-counting the loading screens for the published runs seems the way to go, yeah. Use the overlaid timer in the video, and count the time at the last loading frame - the time at the first loading frame as the loading time for that loading screen (that rounds it down somewhat, but that's better than rounding it up) ; and do this for all loading screens. Any frame-precise video-editor easy to use should do the work, though I can't tell you what exactly should be used.

Hopefully converting a single run shouldn't take more than one hour. There are 7 runs in total to convert in 0.9.3.

Btw, @Alistair_Findlay any% run should be replaced. After all, his expert% run is also an any%, and it has a much better time.

Also rules should mention that the time is counted in RTA-without-loading-time and point out the patch. That's ok to convert a few older runs I think, but that wouldn't be ok to have to convert new ones, so submitting a run not timed with the in-game patch timer = losing the loading time for future 0.9.3 runs.

Old full run times (only PB) for 0.9.3 should be converted to RTA-without-loading times. That's not a very pleasant task, but that would be the best thing, I think, there aren't that much runs.

Updated the patch to have the aforementionned fixes.

Should be good enough for future speedrunning of the 0.9.3

I'd probably try to do things even better for the timer for 0.9.4 ; but as the patch here will be only used by speedrunners who know what they're doing, there's no point in backporting those future changes.

There is a new which will make all those who have speedrunned STK very, very happy.

https://github.com/supertuxkart/stk-code/commit/40372319f62e522ae8d6aaaca40f81029d66ef58

"At general request, remove follow-the-lreader from story mode"

The patch submitted in resources still has some issues : 1)The loading times after the run end are deduced. Fixed locally. 2)If starting two valid runs in the same session, the second one won't start at zero - the loading times from the previous run are deduced. Fixed locally. 3)Rarely, the timer don't start : it switches to numbers on story mode start, but its value remains at exactly zero. I don't know why it happens.

None of these issues is fatal (for 1, there is a moment where the correct time is displayed ; for 2 it is obvious on video and can't be hidden, for 3 you just need to retry) but it may be better to wait still before trying a full-game run.

The new patch for an in-built timer solves the question. It provides an IGT equivalent to RTA without loading times.

There may yet still be some small bugs if doing weird things (testing would be appreciated), but it should mostly work.

I did a full-game run using the new built-in timer which discards loading time.

A terrible frustration.

Final IGT counter : 59m39s433 Total loading time (discarded in the IGT total) : 1m15s482

I was at 30m47s IGT (31m21s RTA) at the end of the second GP (record run : 31m20s RTA) I failed a bit in mansion and gran paradiso and a lot in green valley. Combined, probably more than a minute lost due to stupid needless errors. Still I managed a very nice double-skip in the 4-race GP and was at 47m24 IGT after it (48m21s RTA) (record run : 47m40s RTA, but the loading time aren't always the same even for a given player) Then, I completely failed green valley again. I hate the "wrong direction message" which hinders view. I lost over a minute minute over the two laps with accident triggering recue for the first and having to do the full way back from the checkline to the lapline next. I wasn't far from failing to win the race. I lost nearly two minutes over the whole GP...

Done : reset the timer if changing the player ; display a different message if the current player can't do a valid run

EDIT : Video demonstration :

(The issue of the message not saying that you can do a run with the new profile has been fixed since then)

Ever lost in the FTL race in STK enterprise ? Ever tried to continue as fast as possible by mashing buttons, only to be sent in the single player race selection screen ?

That bug is now fixed in the current developpement version.

The nitro bug mentioned in my guide about how to use nitro in 0.9.3 (if you press the key less than minimum time, the nitro is spent for minimum time but you get the bonus only for the time the key was really pressed) is also fixed.