OXPing and deprecated features

[cim]

One of the things I'm working on at the moment is a feature for Oolite where it will - if you're using the OXP developer build (including nightly builds) - do something if you load an OXP which uses a deprecated feature, or makes some other mistake (e.g. misnamed files).

Options for what happens are:
- nothing (useful for people who are playing the nightly builds for purposes other than OXP writing, and also what will continue to happen in release builds)
- add a log entry
- add a log entry, and where reasonably "safe" to do so block the use of a deprecated feature
- add a log entry and immediately exit to desktop
(The last sounds harsh, but if you tend to release OXPs with silly mistakes because you didn't check the logs enough, it might be useful)

So far I've got the various obsolete items at [wiki]OXP_standards[/wiki], a requirement for OXP-format releases to include a manifest.plist, and a number of existing missing/misformatted file errors which already give a log entry but will now trigger the "exit on error" route if that's enabled.

Is there anything else (that can be tested for programatically, that is) which OXPers would find useful for Oolite to warn about in this way?

[Switeck]

Thanks! This will probably save me many hours of headaches trying to spot a simple typo.

...Is there any chance of re-enabling the logging of what line in a script triggers an error?
(Or was that removed from trunk and standard Oolite because of too much accumulated cruft?)

[cim]

Oh ... another bit I missed: if you don't put "use strict"; in your JS files, it'll complain (and in the "enforce" mode, it'll put it in for you)

...Is there any chance of re-enabling the logging of what line in a script triggers an error?

The debug console does still provide this information, so I'm not sure why Latest.log doesn't. I'll have a look at it.

[Thargoid]

I'm strongly against exiting to desktop, and for me having depreciated stuff blocked is also a very poor idea as it'll make actually upgrading such OXPs very difficult.

My vote would be for a very clear and descriptive log entry which includes full details of which script (and ideally where in it) the problems are occurring. Very much along the lines that Switeck already said, which I fully support.

One other suggestion - could the oxp verifier be tweaked to also highlight depreciated stuff?

As for if there's anything else, ideally I'd like to see some kind of enforcement of licenses, but I have no idea how that could be done.

But I have to honestly say that there's been so much change made (and so much further change proposed) that what I feared about keeping OXPs up to date with them is beginning to come to pass in that it's going to be too much of a moving target and much too time consuming for what I can give them.

[cim]

I'm strongly against exiting to desktop, and for me having depreciated stuff blocked is also a very poor idea as it'll make actually upgrading such OXPs very difficult.

It's a setting, and the default in a test build is just to log it.

One other suggestion - could the oxp verifier be tweaked to also highlight depreciated stuff?

Some of it, yes. A few things are fairly difficult to find except at runtime, but all the plist-key stuff should be straightforward.

But I have to honestly say that there's been so much change made (and so much further change proposed) that what I feared about keeping OXPs up to date with them is beginning to come to pass in that it's going to be too much of a moving target and much too time consuming for what I can give them.

While logging deprecated items is a first step to removing support for them entirely, I think the logging needs to be in a stable release before any of that can happen. So the earliest any of this would stop working is 1.84 (which is certainly going to be no sooner than the end of 2016, and more likely 2017 or 2018). The obvious first target for actual removal is the legacy scripting engine which was ... well, little bits of it were still needed up to 1.77 in terms of the "conditions" key for shipdata/shipyard, but everything else was obsoleted by JS in 1.74 or earlier - and very few OXPs still actually use it, which is why it's the obvious target for removal.

[Switeck]

An important first step for many mission or station OXPs is to start using the populator script to create ships and places of interest.
The first one you do will probably be the hardest.