Offset time (+/-) Issue

[Phoenix]

Just throwing a random idea out there ...

Checkpoints are generally for the purpose of telling you how fast you did one segment of a map vs previous attempts. But there are some scenarios where you can't really rely on them to judge how well you're doing. Here's the ones I can think of ...

1) If a checkpoint is skippable via shortcuts.
2) If you take a slower route for one checkpoint but end up with a higher speed yielding a faster time in the following checkpoints.

eg. Checkpoint 1 ---> 10 seconds ---> Checkpoint 2 with 1000u
Checkpoint 1 ---> 15 seconds ---> Checkpoint 2 with 2000u

The 2nd route is obviously faster overall (depending on the map ofc) but your checkpoint time would be slower. Not sure if there's a way to account for that or not but I thought I'd throw it out there just in case. Doesn't make a dif either way to me.

[<hk>]

Checkpoints are generally for the purpose of telling you how fast you did one segment of a map vs previous attempts. But there are some scenarios where you can't really rely on them to judge how well you're doing.

You could assign IDs and slots to checkpoints. That way the checkpoint would always be at the same place of the hud.
The checkpoint could be marked as skipped(grey) if you touch a checkpoint at a higher slot.
The best way would probably be to let the mapper descide which checkpoints are equivalent to work around problems on maps with multiple/mirrored routes.

This could lead to more confusion since the gray checkpoint would be gone in the next run when you beat your time.


I wouldn't touch the display checkpoints except for the +/- thing.

The 2nd route is obviously faster overall (depending on the map ofc) but your checkpoint time would be slower.

That's only the case once. The first time you beat your old route with the new one, all checkpoints would be aligned again.

[742617000027]

No it has to be the same for everybody, otherwise there's too much confusing when people ask "what checkpoints did i have on you" etc

Indicating wether one went faster or slower might indeed be challenging for some ...

[<hk>]

I could write something, that colors parts of sentences that could be a time in the corresponding color. "\+[1234567890]+" and "-[1234567890]+".

Like this:

<hk>: I have +100 on you. :D
<hk>: Oh, I mean -100. :/

So players see the error and correct it.

[742617000027]

Make it /g008 and /r008 for 008 and 008. I guess it's useful only for german keyboard layouts anyway since we toggle the console with the ^ key and therefore can't use colorcodes in normal chat. At least I can't.

[Arcaon]

Also, a simple, obvious feature that only I seem to think about:

Code: Select all

 203 CH_INFO_CHECKPOINT_OFFSETS,            // checkpoint offsets
 204 CH_INFO_CHECKPOINT_LAST,               // last checkpoint

[742617000027]

Not only you, but I count on you stating it when ever the context is given :D

[<hk>]

Make it /g008 and /r008 for 008 and 008. I guess it's useful only for german keyboard layouts anyway since we toggle the console with the ^ key and therefore can't use colorcodes in normal chat. At least I can't.

I was talking about ingame chat. Whenever there is a "time" in the chat it gets hilighted in the right color automatically. The user doesn't have to color it himself.

If you want your "console moves up"-problem to be solved you should just rebind your console key.

[742617000027]

I tried. It's just that I can't unbind the ^ key. I was talking about ingame chat aswell, btw, I thought you were proposing some kind of color tags, it just looked like.

[Phoenix]

That's only the case once. The first time you beat your old route with the new one, all checkpoints would be aligned again.

They would be aligned again when using that same route. But if you or someone else was to do the first route again it would shows as a massive gain at the first checkpoint and then a massive loss at the second.