[BUG] Checkpoint timer fades too quickly, shows wrong values

Since the CTS tournament has gone on a while I've noticed some things that could be improved / are buggy; both are concerning the checkpoint timer, which, upon crossing a checkpoint, shows the difference in time to the best time at that checkpoint. The problems are:

1. If the time at the checkpoint is a new best time, the timer will show a time of "0,0" even if a time has already been logged there in a previous run of the same session. Ideally it should show the difference to the previous best, instead.

2. The time difference shown fades very quickly; this can be a problem in certain maps where the level of concentration required near checkpoints due to the layout of the map is high, which means that by the time the player can look at the time differential it will already have faded. The US player / mapper "z" has been looking at this issue as well and we have not found any cvars that could increase the time that message is displayed (we tried with "notification_item_centerprinttime", "scr_centertime" and also looked at cvars with the word "race" but nothing seems to be pertinent to the fade out time). Z also tried looking at the code (file ./qcsrc/client/hud/panel/racetimer.qc) and there replaced

Code:

drawcolorcodedstring(str_pos, s, '1 1 0' * 0.2 * mySize.y, panel_fg_alpha * a, DRAWFLAG_NORMAL);

with

Code:

drawcolorcodedstring_aspect_expanding(str_pos, s, '1 1 0' * 0.2 * mySize.y, panel_fg_alpha * a, DRAWFLAG_NORMAL, 1000);

to call that function inside the file ./qcsrc/client/miscfunctions.qc in order to modify the behavior, but to no avail.

Does anyone have any ideas how to fix this?

From a quick look at it, I think you only need to scale the "a" factor in
https://gitlab.com/xonotic/xonotic-data....er.qc#L160
and similar if-branches

Thanks for your suggestion! Unfortunately that doesn't seem to work; when changing the "2" in all the "a = ..." lines to "20" and changing the upper bounds to "20" as well, the time that the differential is displayed doesn't change.
Any further ideas?

Actually, let me correct that. -z- made this experiment with what you suggested, not me and apparently he did it wrong.
I have now scaled the variable "a" up to increase it's upper bounds to 4 (as well as scale it from 4) and it works; the timer message now stays about 3 seconds before fading out at 4 seconds, making it easier to read if the path is complicated and needs a lot of focus.
Unfortunately, this change only has an effect on my local games since the timer message is delivered server side, it seems.
Since I don't know how much, if any, CTS I'll be playing after the tournament, which ends tomorrow, might I suggest this be adapted for a new cvar of sorts, such that server admins will have an easier time modifying the fade time if they so desire, for the people more interested in that game mode?
What I changed is this:

Code:

[user@machine ~]$ diff ./racetimer(original).qc gitbuilds/xonotic/data/xonotic-data.pk3dir/qcsrc/client/hud/panel/racetimer.qc (modified by me)
160c160
< a = bound(0, 2 - (time - race_checkpointtime), 1);
---
> a = bound(0, 4 - (time - race_checkpointtime), 4);
181,182c181,182
< a = bound(0, 2 - ((race_laptime + TIME_DECODE(race_nextbesttime)) - (time + TIME_DECODE(race_penaltyaccumulator))), 1);
< float a2 = ((race_mybesttime) ? bound(0, 2 - ((race_laptime + TIME_DECODE(race_mybesttime)) - (time + TIME_DECODE(race_penaltyaccumulator))), 1) : 0);
---
> a = bound(0, 4 - ((race_laptime + TIME_DECODE(race_nextbesttime)) - (time + TIME_DECODE(race_penaltyaccumulator))), 4);
> float a2 = ((race_mybesttime) ? bound(0, 4 - ((race_laptime + TIME_DECODE(race_mybesttime)) - (time + TIME_DECODE(race_penaltyaccumulator))), 4) : 0);
197c197
< a = bound(0, 2 - (time - race_penaltyeventtime), 1);
---
> a = bound(0, 4 - (time - race_penaltyeventtime), 4);
210c210
< a = bound(0, (time - race_checkpointtime) / 0.5, 1);
---
> a = bound(0, (time - race_checkpointtime) / 0.5, 4);
215c215
< a = 1;
---
> a = 4;
230c230
< a = bound(0, 2 - (time - race_mycheckpointtime), 1);
---
> a = bound(0, 4 - (time - race_mycheckpointtime), 4);
237c237
< a = bound(0, 2 - (time - race_othercheckpointtime), 1);
---
> a = bound(0, 4 - (time - race_othercheckpointtime), 4);
246c246
< a = bound(0, (1 + t - time), 1);
---
> a = bound(0, (4 + t - time), 4);

May it be of use...

1. Register here: https://gitlab.com/xonotic
   
2. Get repository access
   
3. Push your changes to a branch
   
4. Create a Merge Request
   
5. ???
   
6. Profit
   

The upper bound should stay at 1 as this means 100% alpha/no transparency

The upper bound should stay at 1 as this means 100% alpha/no transparency

You're right. It's -z-'s fault  
As to branching and making a merge request...I'm gonna pass. I won't really play CTS much after the tournament and this little fix was just a quick hack to see if the functionality can be achieved. To do this properly would require diving into the code much more to work out multiple ways to change the functionality (it would make sense, for example, to differentiate pre-checkpoint from post-checkpoint fading times) as well as figure out where the actual bug lies (point 1 in my OP) and seeing as I'm not a programmer it would simply take me way too much time to figure it all out and implement the changes for a game mode I won't really play and for which I'd then have to convince the server admins to use this mechanism to increase fading time, since this setting works server side, not client side. So....sorry but waaaaaaaay too much effort for something that I don't really need.

Edit: Just to be clear: not trying to be ungrateful, I just hoped to have a solution develop in this thread that could work client side so that I could fix the issue for myself and anyone who implements the same on their end. But the fact that this is server side (which I didn't know going in) means that it needs to be done right (proper programming that can be merged into the official repo so that server admins will get the changes on their next update). And even then I'd still have to lobby them to increase the appropriate cvar, which would not be uncontroversial, since for maps with close-together checkpoints a short fading time is probably better. And all this for a game mode I'm not really invested in and a job I barely have the skills for...I hope you understand.