It lives!
Posted: Sun Mar 04, 2007 4:49 pm
Oolite has grabbed hold of me by the head and pulled me in. I’ll probably be throwing together a test build for OS X soon so we can work out what’s changed and what’s broken. (One thing that is in there, which was inquired about recently, is special indication for large objects on the scanner.) Also, Giles hasn’t responded to my query about another_commander’s Advanced Navigational Array. I think I’ll choose to interpret that as “not no”.
But now I’d like to talk about what I’m working on because, well, attention-whoring is half the fun. It’s… a slightly improved logging system. “Woot”, I hear you cry. (Warning: if you’re not a geek, do not read this lest your eyes glaze over.)
What it does is allow you to turn groups of related log messages on and off using the preferences file. By default, most messages will be on (so logs from newbies will contain everything), but when you’re working on scripts (or the game itself) you can turn off vast swathes of irrelevant noise and concentrate on the messages related to what you’re actually doing. This also means that the developers can ask a user to turn on certain debug messages that are usually off (for instance, sound-related ones) to work on a particular problem, without requiring special builds.
Example: every time Oolite starts, it dumps all the places it looks for files in (generally the first thing in the log). I generally don’t care about this, so I look at the first line of this dump and see:This means the “message class” of the message is “searchPaths.dumpAll”. I type in the following at the terminal:…and run Oolite again, and it’s gone.
Also, that list of OpenGL extensions, and all the stuff about adding various classes of vessels to the Lave system, are also of no interest. They’re also conceptually related. How about disabling them as a group?…and they’re all gone. How does this work? Well, the default states for message classes are set in the new configuration file logcontrol.plist, which contains lines like:Here, $troubleShootingDump is a “metaclass” of log messages, used to control groups of similar message classes. Other predefined metaclasses are $scriptError, $error and $entityState (the latter controls various AI and scripting messages). You can also create and use your own metaclasses:
The dots in the name suggest that message classes form a hierarchy, which is indeed the case. If a message class is set to “inherit”, or is not defined anywhere, the logging system will delete everything after the last . and try again; for instance, asked to log a message in the class script.addShips.success, given the definitions:
the logger will look for script.addShips.success, see it’s defined to inherit, look for script.addShips, see it’s undefined, look for script, see it’s undefined, then look for the universal fallback _default. On the other hand, if it looks for script.addShips.failed, it sees $scriptError, looks for $scriptError, finds that undefined, and again goes for _default.
Obviously this is all extremely nerdy, but if you spend any time sifting through the log you’ll probably have a use for it.
Some notes:
But now I’d like to talk about what I’m working on because, well, attention-whoring is half the fun. It’s… a slightly improved logging system. “Woot”, I hear you cry. (Warning: if you’re not a geek, do not read this lest your eyes glaze over.)
What it does is allow you to turn groups of related log messages on and off using the preferences file. By default, most messages will be on (so logs from newbies will contain everything), but when you’re working on scripts (or the game itself) you can turn off vast swathes of irrelevant noise and concentrate on the messages related to what you’re actually doing. This also means that the developers can ask a user to turn on certain debug messages that are usually off (for instance, sound-related ones) to work on a particular problem, without requiring special builds.
Example: every time Oolite starts, it dumps all the places it looks for files in (generally the first thing in the log). I generally don’t care about this, so I look at the first line of this dump and see:
Code: Select all
[searchPaths.dumpAll]: ---> searching paths:Code: Select all
% oolog searchPaths.dumpAll no
> Setting OOLogging flag searchPaths.dumpAll to noAlso, that list of OpenGL extensions, and all the stuff about adding various classes of vessels to the Lave system, are also of no interest. They’re also conceptually related. How about disabling them as a group?
Code: Select all
% oolog \$troubleShootingDump no
> Setting OOLogging flag $troubleShootingDump to noCode: Select all
$troubleShootingDump = yes;
rendering.opengl.extensions = $troubleShootingDump;
searchPaths.dumpAll = $troubleShootingDump;
universe.populate = $troubleShootingDump;Code: Select all
% oolog \$myMetaClass yes
> Setting OOLogging flag $myMetaClass to no
% oolog dataCache \$myMetaClass
> Setting OOLogging flag dataCache to $myMetaClass
% oolog script.addShips \$myMetaClass
> Setting OOLogging flag script.addShips to $myMetaClassCode: Select all
script.addShips.success = inherit;
script.addShips.failed = $scriptError;
_default = yes;Obviously this is all extremely nerdy, but if you spend any time sifting through the log you’ll probably have a use for it.
Some notes:
- The majority of log calls (there are over a thousand) have not been updated to the new system, and will therefore be of class “unclassified”. However, the ones that spew the most – at least, on my system – will be in the test release.
- Currently, the oolog tool is a trivial shell script – “oolog foo bar” is eqivalent to “defaults write org.aegidian.oolite logging-enable -dict-add foo bar”. I don’t know whether this will work with GNUstep. A slightly more sophisticated tool won’t be hard.
- I’m working on applying the new logging system to the scripting stuff. The debugOn script action will set script.debug (and thus everything that inherits from it) to yes, and debugOff… well, guess.
- The logger very deliberately doesn’t look in OXPs for settings.
- Some other thing I forgot.
well done Commander!
