Apparently defective Config/shipdata.plist files

[phkb]

What did you find/do

The errors I found were things like: last shipdata entry not having a ";" at the end (it's implied for Windows and Linux, but OSX doesn't like it); looking for things like "{ hue=30 };" and adding the missing ";", to make it "{ hue=30; };" (again, Windows/Linux can imply the ";", OSX doesn't). That sort of thing.

Do you want me to run my eyes over any particular file for you?

[phkb]

@smivs:
What I found:
Clippers: look for the "boaclipper-player" entry, no ";" after the "like_ship" value.
Liners: there are a few "{ hue = x };" items (ie missing the ";" after the value.
YellooCabs: in the "yellOo-cab-player" entry, in the "script_info" entry, there is no ";" after the "oolite-barred-equipment" value
in the "yellOo-cab-taxi-NPC" entry, in the "materials" section, in the "specular_map", the "extract_channel" value is missing a trailing ";"

Hope that helps a bit!

[Smivs]

That helps a lot! Thank you

[hoqllnq]

I did a funny thing:
When a .plist fails to parse on Mac, I run the data through my own (very forgiving) parser and re-serialize it and then try again with the new data.
It works. I'm not sure whether it is a good idea to actually deploy this, but if anyone is interested to look at it, this is it:
https://github.com/jobi-wan/oolite/comm ... 3a6367cce2

[Fleurghber]

The new version of Extra Thargoids seems to be working.

[Diziet Sma]

I did a funny thing:
When a .plist fails to parse on Mac, I run the data through my own (very forgiving) parser and re-serialize it and then try again with the new data.
It works. I'm not sure whether it is a good idea to actually deploy this, but if anyone is interested to look at it, this is it:
https://github.com/jobi-wan/oolite/comm ... 3a6367cce2

Interesting solution. Like you, I'm not sure if deploying it would be a good idea.. how well does it cope if the problem is something more serious than a missing semi-colon?

[hoqllnq]

how well does it cope if the problem is something more serious than a missing semi-colon?

In that case, the OXP developer would notice upon testing on a non-Mac system. (But that's not what you're asking...)

It allows the wrong kinds of brackets / parentheses, missing commas, using commas instead of semicolons and vice versa, colons instead of equals, I think it will happily treat JSON as openstep plist.
If it can't "fix" it, it will fail in the same way it does now, and report it as "Unfixable".

I guess what you're getting at is: Will it hang or crash when throwing absolute garbage at it?
Not easily but I can try and handcraft some data specifically to confuse it.
[EDIT]
That was easy! It would hang on unterminated /* comments..
Also easily fixed though: end-of-data is now also considered a valid end-of-comment.
[/EDIT]


But mainly, it doesn't fix the source of the problem. It just masks it.
What would probably be more useful is to turn it into a validator that spits out more useful messages than "unexpected { at line 1" and doesn't bail out on the first error. And then as a separate tool for OXP devs to test their work.

[Diziet Sma]

I guess what you're getting at is: Will it hang or crash when throwing absolute garbage at it?
Not easily but I can try and handcraft some data specifically to confuse it.
[EDIT]
That was easy! It would hang on unterminated /* comments..
Also easily fixed though: end-of-data is now also considered a valid end-of-comment.
[/EDIT]


But mainly, it doesn't fix the source of the problem. It just masks it.
What would probably be more useful is to turn it into a validator that spits out more useful messages than "unexpected { at line 1" and doesn't bail out on the first error. And then as a separate tool for OXP devs to test their work.

Yes, that was what I was getting at.. and I'm glad I inadvertently helped you improve it.

A good validator for for non-Mac OXP authors really would be a useful tool.. as you're probably well aware, this has been an ongoing problem for years.