View previous topic :: View next topic |
Author |
Message |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Tue Aug 10, 2010 2:21 am Post subject: Developer cvar management scheme? |
|
|
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 ... _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
r00k
Joined: 13 Nov 2004 Posts: 483
|
Posted: Tue Aug 10, 2010 4:56 am Post subject: |
|
|
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.. |
|
Back to top |
|
 |
metlslime
Joined: 05 Feb 2008 Posts: 177
|
Posted: Tue Aug 10, 2010 7:00 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
Sajt
Joined: 16 Oct 2004 Posts: 1026
|
Posted: Tue Aug 10, 2010 10:07 pm Post subject: |
|
|
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"... _________________ F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe. |
|
Back to top |
|
 |
frag.machine

Joined: 25 Nov 2006 Posts: 728
|
Posted: Wed Aug 11, 2010 1:44 am Post subject: |
|
|
Many logging libraries (log4j, log4net, commons-logging, etc) use two concepts that could be applied here: severity level and origin.
Code: |
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: |
void (float level, string message) WriteLog = #???;
|
No, I didn't forgot the "string origin" ("QC" ?), this could/should be hardcoded in the builtin. _________________ frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/ |
|
Back to top |
|
 |
Baker

Joined: 14 Mar 2006 Posts: 1538
|
Posted: Wed Aug 11, 2010 2:51 am Post subject: |
|
|
frag.machine wrote: | Many logging libraries (log4j, log4net, commons-logging, etc) use two concepts that could be applied here: severity level and origin.
Code: |
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: |
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. _________________ Tomorrow Never Dies. I feel this Tomorrow knocking on the door ... |
|
Back to top |
|
 |
reckless
Joined: 24 Jan 2008 Posts: 390 Location: inside tha debugger
|
Posted: Wed Aug 11, 2010 3:47 am Post subject: |
|
|
hmm could probably use pdcurses for some interresting stuff ?
dosbox uses it for an internal debugger  |
|
Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2004 phpBB Group
|