Oolite has vague plist parsing messages

[oocube]

In the forum I see posts like this one:

am on Windows 11 now. (In an earlier entry in this thread I mentioned that I was - as indeed at the time I was - on Windows 10.)

I (continue to) see this in the log:

Code: Select all

[gnustep]: 2026-06-10 01:33:20.550 oolite[14236:17748] File NSPropertyList.m: 1015. In id parsePlItem(pldata *) Missing semicolon in dictionary at line 17 char 622

I thought that I had tried to patch the Thargoid Carrier OXP, that OXP being one possible culprit. (See earlier in this thread and also
here.) I think that the Imperial Currier OXP is another expansion pack with some bad PNG(s). But can one of the programmers get Oolite to report something more informative?

Still, I'm not having a hang. (I did have a hang not so long ago - or was it a crash to desktop? At any rate, the cause of that problem seems to have been a buggy AMD driver. Many an - official - AMD Windows driver is buggy.)

With the cited message from the logfile nobody is able to tell where to find the problem and therefore it cannot be fixed. This needs to be improved.

[oocube]

The above message seems to directly stem from GnuStep:
https://github.com/AaronYi/gnustep-base/blob/master/Source/NSPropertyList.m#L1031

Seems Oolite just invoked the method, but it emits that message to the logfile without telling the calling function about it. How can we provide additional information such as the file path in case of failure?

[oocube]

I asked Google Gemini:

How can an ObjectiveC application figure out that GnuStep logged an NSWarnFLog?

The response was:

Catching or intercepting an NSWarnMLog or NSWarnFLog in a GNUstep application can be a bit tricky because, by default, these macros write directly to stderr or a system log via GNUstep's internal logging mechanisms. They don't automatically post an NSNotification or throw an exception.

However, because GNUstep is open-source and built on top of standard C and Objective-C runtime principles, you have a few clever ways to intercept or figure out when these warnings are logged.

It seems we need to redirect logging to a string value, then after the function call check whether something was logged. This sounds like an ugly workaround. For the time being I will simply add a log statement telling us which file is getting parsed. This likely needs simple changes in these two locations:

• https://github.com/OoliteProject/oolite/blob/master/src/Core/OOPListParsing.m#L51
• https://github.com/OoliteProject/oolite/blob/master/src/Core/OOPListParsing.m#L80

[oocube]

I spawned branch improvePlistParsingMessages. It's build result can be downloaded at
https://github.com/OoliteProject/oolite/releases/tag/1.93.1-improvePlistParsingMessages.1

[phkb]

Is it possible to tie the log output to something in logcontrol.plist, so the info can be suppressed from the log file when not needed?

[oocube]

Technically yes - I just would not know how to do it.

Actually I'd prefer to only emit the message in case of error. But as the parser does not communicate it hit a missing semicolon Oolite would not know when to claim which file gets parsed. That's why I added this unconditional message.

Can you give some guidance?

[phkb]

Step 1: Add the following line under line 40 in OOPlistParsing.m:
static NSString * const kOOLogPListInformation = @"plist.information";
Step 2: Change your @"OOPListParser" in line 57 to this:
OOLog(kOOLogPListInformation, @"Parsing %@ as a property list.", whereFrom);
Step 3: Finally, in logcontrol.plist, add the following at line 218
plist.information = no;

The trouble is it only half works. Plists are being parsed before logcontrol comes into play. So, on making those changes, the game will report on parsing plists until after the GL extensions are reported. It should then stop logging info.

I'm trying to work out at what point logcontrol comes into play so the messages can be suppressed until then.

[phkb]

Ok, additional changes:
On line 25 of OOPlistParsing.m, add this line:
#import "Universe.h"
Then make lines 56-60 look like this:

	if (whereFrom == nil) whereFrom = @"<data in memory>";
	if (UNIVERSE != nil) 
	{
		OOLog(kOOLogPListInformation, @"Parsing %@ as a property list.", whereFrom);
	}

Now the log entries will only be shown when the logcontrol entry is set to yes.

[phkb]

I should add, you might still get error messages appearing in the log file without the name of the plist showing, but if the logcontrol entry is set to yes you'll get a subsequent entry where the plist file is named.

[oocube]

I spent quite some time thinking about it. The whole point is to allow users fixing problems as they arise.
If a user just sees "missing semicolon in line/column" it is completely pointless without knowing the file.

My fix to unconditionally write the filename creates enough noise that you want to configure it 'off' - but will the ordinary user be able to turn it on again in case he sees "missing semicolon"? If that is not the case, the idea of this change is not met.

Thus the real question should be: Can we print the filename only in case a semicolon was missing?

[phkb]

Re "ordinary user" - hopefully an "ordinary user" will never need to worry about this because the OXP developer saw the messages first and fixed them. At the very least, this is better than what we have now. We can now point people to the logcontrol entry for how to reveal which file has the problem.

[oocube]

Ok, let's use logcontrol. How would an ordinary user configure that? Remember we have AppImage and Flatpak builds. Currently I can only suspect logging configuration to be hidden within the image - out of reach for users.

[phkb]

Creating a UI to allow players to interact and change logcontrol.plist is a bit beyond the scope of this. However, could we launch the system text editor and throw logcontrol.plist into it? Maybe from the settings menu? Not sure. That's about as much as we could hope to achieve, I feel.

[oocube]

I was thinking more of a procedure that users can follow rather than a UI. Something like creating a logcontrol configuration file in the GameData folder. We just need to make sure Oolite would use that if present.

[phkb]

You can put a logcontrol.plist file straight into your AddOns folder right now, and Oolite will pick it up. And it can be as simple as

{
    plist.information = yes;
}

Adding that to the AddOns folder of the build I've got with those changes successfully outputs all the plist filenames.

[oocube]

Sounds like a plan. We put the above onto a wiki page for easy reference.
And the code will only emit these messages when logcontrol is configured correctly. :-)

As you made the changes already, would you like to push them to this branch?