RFC: script access to station markets

[cim]

One thing that I've seen requested a few times over the last couple of years is access from script to station market data (and to commodity.plist definitions). This isn't particularly tricky to do, but there has been some controversy in previous threads about whether it's a good idea.

My planned implementation is:
Read: station.market - returns an object, with keys as the internal commodity names, and values as an array representing the commodity.plist line for that station and commodity (note that this will put the current quantity and price into elements 1 and 2 of the array). So, for instance, station.market.food might be ["Food", 17, 40, "19", "-2", "-2", "6", "1", "1", "0"] at Lave.

Write: station.setMarketPrice(commodity,price) and station.setMarketQuantity(commodity,quantity), which do what you'd expect. The price must be between 0 and 1020 decicredits (should it be forced to a multiple of 4 too?), and the quantity between 0 and 127 units.

Opinions on the desirability of doing this, any limitations that should be placed on access, and the proposed API, please.

[Thargoid]

For quantity, would it make sense to align it with the players manifest function? It seems a little odd to be using a different method for the player ship and stations.

That said the price would of course have to be something different, along the lines of your suggestion.

My only concern would be a badly formed script (or multiple scripts all working on the station manifest) could end up causing an infinite supply of goods, or other odd quirks like that. So perhaps some sort of "pecking order" between world scripts and the stations own ship script may be worthwhile, with the latter going last and overriding the former.

But generally it could open up yet more fun possibilities.

[Switeck]

The current situation with Oolite v1.76.1 is possibly conflicting commodities.plist files, which all try to change the same stations. Last to load "wins"?

As for game balance issues, poor choices of prices+amounts are already possible with commodities.plist. Your Ad Here Constores come to mind.

[JensAyton]

I’d strongly recommend making the commodity types a class with named properties. The current commodities.plist representation is a wart, not a feature.

[cim]

I’d strongly recommend making the commodity types a class with named properties.

Agreed.

For quantity, would it make sense to align it with the players manifest function?

I think having different ways in which the price and quantity are edited is probably more confusing than having player manifest and station market have different methods. (Also, having a single hard-coded read-write property for each commodity type is internally messy, and would break if at any point in the future we wanted to allow OXPs to define their own commodity types)

So perhaps some sort of "pecking order" between world scripts and the stations own ship script may be worthwhile, with the latter going last and overriding the former.

Very tricky to enforce, since the order of execution of event handlers is undefined, and even if it was somehow defined, it wouldn't stop another script changing it again in a different event handler.