I want to include a modified logcontrol.plist with a little test OXP I'm planning on asking a few members to test for me. If the logcontrol.plist is sat loose in the AddOns folder it is picked up by the game and the additional logging that is enabled is produced. If it is in the OXP's Config folder it is not picked up by the game....
I've double checked for any other logcontrol.plists in other OXPs and there aren't any.
It’s by design, but the situation has changed since the decision was made. At the time, OXPs couldn’t use custom log message classes, so an OXP logcontrol.plist could only modify default behaviour – most likely by enabling script debug logging, which would affect all OXPs.
I still don’t like the idea of an OXP changing built-in log message classes – distributing a loose file for testers would seem to cover the legitimate uses. However, with the current JS logging, an OXP could turn its own log messages off by default. Possibly we should allow OXP logcontrol.plists but ignore settings that override built-in keys (and their descendants).
Possibly we should allow OXP logcontrol.plists but ignore settings that override built-in keys (and their descendants).
I’ve been playing around with this, but there’s a problem of sorts: if an OXP disables its own log messages, they don’t show up in the log, but they do show up in the debug console. As I see it, this isn’t the Right Thing.
Proposed fix:
If an OXP explicitly specifies a message class in a log() call, and that message class is disabled, the message doesn’t appear anywhere.
If no message class is specified, the behaviour is unchanged – it’s logged if [script.debug.message] is enabled, and printed in the debug console regardless.
Since existing OXPs which specify message classes should be using ones that aren’t in the built-in logcontrol.plist, and hence will be enabled by default, this shouldn’t cause any surprises. Any objections?
![[EliteWiki]](/images/elitewikismall.png){kind=small}
Capt. Murphy's OXPs
