Board index mDd Board Complaints and Suggestions

Proposition Checkpoint Plus

Did you find a Bug or have an Idea? This is the place to go to.

Proposition Checkpoint Plus

Postby Jake_The_Peg » Nov 20th, '20, 3:21 pm


After a somewhat lengthy convos with both Kg and Jelvan, I've decided to put my hopefully somewhat of a gamechangin' proposition on the paper.

Checkpoints. Every map usually has some, unless we talkin' CTF.

When you pass a checkpoint, you either get a raw time, if you haven't played the map before, or you'll get a relative stat compared to your best run so far, say -0:080.
These checkpoint data are to be found in [gamefolder]/defrag/system/records/[mapname]_[gamemode]_[physics].rec

Well. And these checkpoint times are stored by the engine, only in the event that the run you've just finished was at least a frame faster, than your previous top.

But it's often the case, that the checkpoint data is all over the place, for instance Image.

And here's where the liver of my proposition lies.

My proposition is, to give the player an active choice in the manner of how the checkpoints are handled.
Because it could just as well be taken as a segmented run, similar to how the speedrunning community takes these things. Like AGDQ and similar approaches.

The engine could just as easily store the best times for the given checkpoints you have gotten so far. Regardless of whether or not you've finished your run or not, and regardless of what the time was.

Which would give you, if you so choose, the option to
1) display the regular mode of checkpoint data, vanilla quake
2) display the checpoint times in your run compared to the best segmented times so far, but with your overall time unchanged
3) display comparison to the best checkpoints AND give you an estimate of your best possible run based on the fastest checkpoints so far.
Posts: 41
Joined: Jan 16th, '15, 6:27 pm

Re: Proposition Checkpoint Plus

Postby Jake_The_Peg » Nov 20th, '20, 3:41 pm

There are several drawbacks of course.

1) To do this properly, the engine would need to store the fastest segmented data separately, otherwise the data you'd get would be only from the current session, all previous data would be lost. And coding such a funciton, that would create files on the hard drive, would perhaps be not a trivial task. Still, even the data from a current session could come in handy, seeing that many times a map is played on the server for 300 minutes plus.
2) Some maps have checkpoints laid out in such a manner, that they are at an angle to the trajectory you usually strike 'em at, so their times are not helpful in this regard. This proposition would bring best results in maps where the CPs are perpendicular to you, still, it would bring you Some idea about how fast you can get the map done... And also there are some maps, where some checkpoints can be bypassed completely.
3) Space. If the best checkpoints would be saved in separate file, that would take some more space, but ... looking at my own folder, with some 7,5k *.rec files in it, and it taking up only 1Mb, that shouldn't be much of an issue.
Posts: 41
Joined: Jan 16th, '15, 6:27 pm