Centerprint logging issue

[mh]

Anyone come across this one? There are a number of mods out there which use persistent centerprints for displaying menus and stats in-game. In an engine with centerprint logging, we get the console basically flooded, rendering it pretty useless.

So is there a solution? In an ideal world these mods would be rewritten to use CSQC which every engine would have support for, but I'm afraid we're going to have to accept second best. Do we remove centerprint logging, or do we accept the console spamming, or is there a third option that can detect when centerprints are used in this manner and adjust accordingly?

[ceriux]

couldnt you just make a new print type and have that not be logged? maybe rprint? (prints on the top right?) maybe one for each corner of the screen lol?

[Spike]

mods like TF have a lot of leading new lines in order to align the centerprint with the statusbar.
mods like CustomTF will tend to use [1] or 1. or something to show the user which keys bind to which option.
mods like runequake which just shove the text in the middle of the screen regardless won't change text very often (don't print if its the same as the last print that was printed), but you probably do want it logged, in this case.

Alternatively, if the string is present in the ent file, log it.

At the end of the day, there's nothing really that you can do that is fully reliable.

Either way, you'll get the console spammed with messages simply by standing in a trigger_multiple on the start map. Albeit more slowly.

ceriux: the problem is that existing mods both spam centerprints for menus and certain events like pressing buttons.

[metlslime]

Fitzquake does two things to help mitigate this:

- by default it only happens in single player, but you can enable it for multiplayer too (since multiplayer mods are the main culprits)

- if the new string is identical to the previous string, it's not logged.

The idea of checking to see if the string is in the bsp or progs is an interesting one. What are the drawbacks to this? Are there any code-generated strings that we ought to be logging that would be missed by this?

[mh]

@Spike - that's it exactly, there's no point in a solution that doesn't take existing mods into account.

Anyway, I think I have a fix, which is to only log a centerprint if the previous one has already been cleared (i.e. scr_centertime_off is less than something like 0.01) - I can see it breaking where two different centerprints in quick succession are intentional, so maybe use (scr_centertime.value - 0.1) instead would be better?

[r00k]

Could use an svc sell screen and autodownload menus?

[Entar]

One idea that would remove that nasty flooding and still be pretty useful would be to only log centerprints that are not the same as the last one. That way, if something shows up, it only gets logged once, and then the log reflects all that the centerprint ever said, and when it changed.