Developer cvar management scheme?

[Baker]

FitzQuake and Enhanced GLQuake have a lot of limit breaking messages. Enhanced GLQuake has a lot of warnings about models and such.

What is a good "developer" cvar scheme to manage what someone mapping or modding or engine testing with some sort of clarity?

developer 1 or 0 is too simplistic.

Anyone know a good scheme or idea for controlling the type of developer messages that print to console that someone wants?

Someone doing QuakeC-only might want X, someone mapping might want Y, if you are testing network protocols you might want Z. Etc ...

[r00k]

I know what u mean. I have a bunch of overlapping dev prints.
maybe modify Con_DPrintf(flag,*char format,...);

Con_DPrintf(DEV_QUAKEC, "Model not precached! %s",str);
then if developer is 1 normal, 2 quakeC errors, 3 mappers etc..

[metlslime]

Agreed. I have thought about splitting dprints into categories and then storing bitflags in a cvar (either overload developer or create a new cvar).

So 1 = map, 2 = quakec, 3 = models/sprites/other content 4 = engine dev and then you would set the cvar to "7" to get everything except engine dev messages, for example.

But i wasn't sure what the right categories were. And maybe some cateogories aren't obvious.

I also considered a simpler approach:

developer 1 means all mapping/modding messages.
developer 2 means developer 1 + all engine dev messages.

[Sajt]

In addition to that, I add a "message type" flag which is something like "spam, message, warning, error". They could be colour-coded when shown in the console, you could drop down the console upon printing an error-type message, etc. (Of course, errors should be handled better than simply being printed to console, but with Quake you have to work in steps...) In DarkPlaces, I think, it's an integer which conveys a grade of severity, and you can set the "developer" cvar to an integer threshold. But those numbers can become pretty arbitrary and the user will probably end up doing either "developer 0", "developer 1", or "developer 9999999"...

[frag.machine]

Many logging libraries (log4j, log4net, commons-logging, etc) use two concepts that could be applied here: severity level and origin.

Code: Select all

void Sys_WriteLog (int level, char *origin, char *msg, ...);


level tells the log severity. info, debug, warning, error, fatal (in this order) are common severity levels in the mentioned libraries. Add a cvar to the engine to control which severity level can be output to console (or log file) and you can control how much spam you get. Default value for this cvar should be "warning";

origin is a string identifying the point in the code that originated the message. In Java/.NET is quite common to use the full class name (package/namespace included) so you can have multiple log files from different subsystems in your application. In Quake, I'd suggest to use the source file prefix ("gl", "r", "sys", "snd", etc), so one could selectively turn on/off messages or redirect it for a file instead the console. Add another cvar containing a list with the subsystems allowed to write to log and you get another control level over the log. By default, all subsystems should be listed, and the user can decide which ones to exclude (if any).

Also, would be nice to add a builtin so QuakeC can directly spam to console:

Code: Select all

void (float level, string message) WriteLog = #???;


No, I didn't forgot the "string origin" ("QC" ?), this could/should be hardcoded in the builtin.

[Baker]

Many logging libraries (log4j, log4net, commons-logging, etc) use two concepts that could be applied here: severity level and origin.

Code: Select all

void Sys_WriteLog (int level, char *origin, char *msg, ...);


level tells the log severity. info, debug, warning, error, fatal (in this order) are common severity levels in the mentioned libraries. Add a cvar to the engine to control which severity level can be output to console (or log file) and you can control how much spam you get. Default value for this cvar should be "warning";

origin is a string identifying the point in the code that originated the message. In Java/.NET is quite common to use the full class name (package/namespace included) so you can have multiple log files from different subsystems in your application. In Quake, I'd suggest to use the source file prefix ("gl", "r", "sys", "snd", etc), so one could selectively turn on/off messages or redirect it for a file instead the console. Add another cvar containing a list with the subsystems allowed to write to log and you get another control level over the log. By default, all subsystems should be listed, and the user can decide which ones to exclude (if any).

Also, would be nice to add a builtin so QuakeC can directly spam to console:

Code: Select all

void (float level, string message) WriteLog = #???;


No, I didn't forgot the "string origin" ("QC" ?), this could/should be hardcoded in the builtin.

Interesting ideas ...I guess I'm largely having the messages say "Host_Whatever: some error here" anyways ...

FitzQuake's Con_Warning has made me think about this more lately but I don't want to over use things.

[revelator]

hmm could probably use pdcurses for some interresting stuff ?

dosbox uses it for an internal debugger