Market Script Interface

[phkb]

One of the difficulties when working with commodities is the problem of market scripts. The scripts themselves are fine - they do exactly what they need to do. The problem comes when two OXP's want to do similar things at the same point. At present, one of the OXP's will "lose", in that it will be clobbered by other, without any warning or notification. And because the failiure is silent, it makes debugging issues quite tricky.

To help combat this, and to provide a means by which some of these OXP's can be made compatible with each other, I've created a new OXP called "Market Script Interface". What this OXP does is provide a means by which OXP's can hook into a market script at their preferred level, and be confident that their script will run, no matter how many other OXP's are also doing the same thing.

Of course, this is one of those "It's either everyone, or it fails" things. So, along with this release are also new releases for Risky Business, BlOomberg Markets, Fuel Tweaks, Smugglers, and UPS Courier. If you know of another OXP that utilises market scripts in some way, please let me know and I can help with the integration process.

This won't eliminate incompatible market scripts. If two OXP's decide they will redo the price on the same commodity, only one will win. But many incompatibilities can be removed by using this system.

Rather than explain how it all works here, if you're interested please head over to the wiki page here:  Market Script Interface. There's a download link there, or you can get it from the Expansion Manager.

Comments and questions welcome, as always.

[phkb]

Just to clarify, this utility is designed for any OXP that uses "planetinfo.plist" or "trade-goods.plist" to set a "market_script" property that controls the price or quantity or other elements of a commodity.

Edit to add: For OXP's that use station market scripts (ie defined in shipdata.plist), this shouldn't impact those at all. It's certainly possible to use MSI for that purpose, but it's not required.

[hiran]

If you know of another OXP that utilises market scripts in some way, please let me know and I can help with the integration process.

I could run OoliteAddonScanner with a search or add such information to the Index of Artefacts if it helps. Just let me know what to look for.

[Stormrider]

The Distilleries use a market script to control Witchfire Whiskey prices and there is a trade-goods.plist to control other commodities in the markets of Distilleries and Saloons.It seems that only a script that might control markets for extra stations in general would conflict with it. I am going to have to look over the wiki when I haven't had quite so many beers and see if I can integrate my oxp with this.

[phkb]

Shout out if something doesn’t make sense!

[Alnivel]

Maybe it is just me failing comprehension, but from reading only the wiki page I got the impression that there are only two priorities, "highest" and "lowest", one of them is used if you don't specify a priority explicitly. Besides clarifying this on the wiki, I also think it would be clearer if there were a default and explicit "normal" ("normalest"?) priority.
And a question rather out of curiosity than as suggestion, but is there some reason/intention why a priority has three levels and not just an integer?

Another suggestion is to add try-catch inside the loop in the $process function - if one of the callbacks breaks, the others will be able to keep working.


Also, the Smugglers page still suggests setting "smugglers_illegalmarket.js" as a market script if you want to add support to a new commodity, looks to me like it needs updating.

[phkb]

I got the impression that there are only two priorities, "highest" and "lowest", one of them is used if you don't specify a priority explicitly. Besides clarifying this on the wiki, I also think it would be clearer if there were a default and explicit "normal" ("normalest"?) priority.

Good call. The "normal" priority is implied, but probably not clear enough in the documentation.

And a question rather out of curiosity than as suggestion, but is there some reason/intention why a priority has three levels and not just an integer?

Two reasons. 1: I thought it would be easier to understand. I can never guarantee one script will be run first, given the unpredictable order in which startUp scripts are run, so just having a "highest" or "lowest" seemed the best call rather than using some sort of integer. 2: I didn't want to do array sorting, and instead opted for a methodology that inserts items into the array at the most ideal spot based on the priority.

To get even more technical, when I'm running through the array to run the functions, I'm doing it from the bottom up. That is, I'm starting at the last item, and then working my way towards the top, with the last callback being at index 0. When you add a callback with the highest priority, it is added to the bottom of the array. When you add a callback with the lowest priority, it is added at the top of the array, at index 0. If you don't specify a priority (ie "normal" priority), it is added just after the last "lowest" priority, basically between any lowest and highest priority items, if there are any. If you add a "normal" priority item, and there's no lowest priority items in the list already, it will be added to the top of the array, at index 0.

Now, if two callbacks are added with the highest priority, the last one added (ie. at the bottom of the array) will be the first one that is actually run. And the last lowest priority added will be the last callback run. As mentioned, I can't determine the order of startUp scripts, which would determine which functions would be last and which would be first. Using an integer as a priority I feel would give a false sense of security: If I add my callback with a priority of "0", which for arguments sake we'll call the highest priority, and another script adds a callback at the same priority, you end up in the same position (two scripts wanting the highest priority), but both thinking they should have been first. By using the more generalised "highest"/"lowest" descriptors, I think it communicates the outcomes a little better.

Another suggestion is to add try-catch inside the loop in the $process function - if one of the callbacks breaks, the others will be able to keep working.

Good call. Next version will have this.

Also, the Smugglers page still suggests setting "smugglers_illegalmarket.js" as a market script if you want to add support to a new commodity, looks to me like it needs updating.

Nice catch. Yep, I'll add it to the list.

[phkb]

MSI version 1.1 is now available. This improves it's ability to read its save file information more reliably (and at the right time).