Oolite 1.73.3 and 1.73.4 reliably crash, bad commodity.plist

[pmw57]

Thinking about it, letting any script override a commodity unit of measure sounds very much like A Bad Idea, besides making the ooniverse that exta bit more inconsistent. Let's remove the unit override!

To be in keeping with the object oriented nature of things, I would suggest that the units should be defined from a private section of the game, and then accept modifiable attributes only to those areas that are allowed from external sources.

Other than that, is there any reason to have different units? Perhaps a bullion store may have Gold and others in tons. What if the game itself converted the amount the ship is holding based on the units themself.

But then, that 127 limitation would get in the way if you then purchased the gold, and I suspect that integers could no longer be used to store the data.

[Commander McLane]

These are the affected OXPs (and stations/ships) which have a unit of 0 for Gold, Platinum, and/or Gem Stones.

Thargoid Carrier - Behemoth

All of these OXPs need to be "fixed".

Thanks for figuring these oxp's out. The Thargoid Carrier is even nastier. It contains the commodities of a complete other ship and not its own. When installed it changes the values for a behemoth.

Already fixed in the new WIP version of Thargoidcarrier.oxp. For this one I have removed the commodities.plist altogether, because the carrier will no longer be dockable. It never made sense that the Thargoids would allow a GalCop pilot to dock and trade and buy equipment...

[Thargoid]

We saw Independence Day too, and use Commander Goldblum's trick back at you for infecting you lot with viruses through the dodgy equipment we sell you

[pmw57]

We saw Independence Day too, and use Commander Goldblum's trick back at you for infecting you lot with viruses through the dodgy equipment we sell you

Curse you alien scum! I'm in your bay hacking into your systems as we speak

[Eric Walch]

Looking betted at the commodities.plist I think it has an other problem how people use it. The plist is linked to the primary role in which the ship is added.

When I look at the old Behemoth.oxp of aegidian, he adds the ships not in its Behemoth role, but as Behemoth-name role when added in which space. And when added in normal space they were added in a hunter role. That means it is not working for the behemoths at all. The same is valid for my improvements of the Behemoth. I didn't change anything here.

Looking at the dredgers, I see they have a commodity.plist for a superdredger but I add them as dredgers or as big-trader. So they now ignore the plist completely. Somehow it would be better to link the commodity list explicit over a key in shipdata. Now it is impossible to link such a list to a carrier that is added in a role like big-trader.

[Thargoid]

I seem to recall asking the very same thing when creating Planetfall, as I had the same issue with planet-side locations.

[Kaks]

Other than that, is there any reason to have different units? Perhaps a bullion store may have Gold and others in tons. What if the game itself converted the amount the ship is holding based on the units themself.

But then, that 127 limitation would get in the way if you then purchased the gold, and I suspect that integers could no longer be used to store the data.

The whole market override thing needs some rethinking, since the code as it is does not differentiate between ship storage and market units. If you redeclare all market units to be kgs, by overriding the default commodities definition everywhere, you suddenly get infinite cargo capacity on all ships, which is definitely an unintended side effect. Killing off the units override this side of the Mythical Next Stable Release seems to me the most sensible idea atm. After MNSR, the whole way commodities are handled internally is definitely one more item in the TODO list...


One other problem with commodites.plist overrides is with Oolite localisation.
I've already found a solution for it, but:

The overrides are defined by position: the first commodity override replaces Food completely, the second replaces Textiles, etc. If we use 'Edibles' instead of 'Food' for the first commodity in the list, Oolite 1.73.4 (and 1.71+ afaik) will unhelpfully display (nil) as the name of the first commodity. That's the case until we create a translation definition entry

Code: Select all

"commodity-name edibles"			= "Stuff To Eat";

and place it inside descriptions.plist. The fix I've got will display 'Edibles' if no commodity-name is defined, or 'Stuff To Eat' if it's been defined as the line above...
edit: Still, I'd like to wait a little while to see if we've found out all the things that need fixing with commodities.plist

[Eric Walch]

I seem to recall asking the very same thing when creating Planetfall, as I had the same issue with planet-side locations.

I now will set the primaryRole of all behemoth types to behemoth on spawning in the script. I'll do the same with dredges in case they were added in a big-ship role. That should fix this issue for these two oxp's.

[Thargoid]

Doesn't commodities.plist tie into the ship's shipdata.plist entity key (the unique one) rather than its primary role? Or am I remembering it backwards and that's what I wanted it to be (by which your primaryRole change would work).

For me it might be simpler to have an additional shipdata.plist key to allow overriding and explicitly linking a given ship entry to a given commodities.plist (like the linkage for AI, script etc)?

[Micha]

Slightly OT..

If we're going to be playing with the commodities in a big way anyway, one item I'd like to suggest for POST-MNSR is sub-categorising of commodities.

This is already sortof implemented in an OXP where you scoop specially named items, for example "Laveian Tree Grubs", but of course they turn into the standard commodity of 'Food'.

It would be kinda cool if they were stored as "Food : Laveian Tree Grubs".
They can, of course, continue to be sold anywhere as plain Food, for the standard Food price, but there might be a couple of markets which would pay extra since they consider Laveian Tree Grubs as a delicacy.

This would open up possibilities a little especially if this is exposed to scripts which can then create special delivery runs. it could also prevent people from accepting a Bulk Cargo contract, but selling and buying the supposedly special cargo on the way until they get to their destination.

It would need an extension to the interface (but this is planned anyway as far as I'm aware) to allow opening up of the sub-categories in the trading and manifest screens.

We now switch back to bug-hunting..

[Eric Walch]

Doesn't commodities.plist tie into the ship's shipdata.plist entity key (the unique one) rather than its primary role? Or am I remembering it backwards and that's what I wanted it to be (by which your primaryRole change would work).

The wiki said role and I assumed it would mean primaryRole than. (When that part of the wiki was written we had no primaryRole name but just role when I recall correct)

I looked it up in the code:

Code: Select all

- (NSArray *) commodityDataForEconomy:(OOEconomyID) economy andStation:(StationEntity *)some_station andRandomFactor:(int) random_factor
{
	NSString		*stationRole = nil;
	NSMutableArray	*ourEconomy = nil;
	unsigned		i;
	
	stationRole = [[self currentSystemData] oo_stringForKey:@"market"];
	if (stationRole == nil) stationRole = [some_station primaryRole];
	if ([commodityLists oo_arrayForKey:stationRole] == nil)  stationRole = @"default";
	
	ourEconomy = [NSMutableArray arrayWithArray:[commodityLists oo_arrayForKey:stationRole]];

So it means it first tries to get the role from the marked data. When not available it uses primaryRole and if that fails it uses default.
It also means if the market comes up with a name it will not try primaryRole and could end up in default anyway. I better double check it by doing a real test.

EDIT: just looked at Oolites own rockhermit. Here Oolite uses the primaryRole and not the shipkey.

[Lestradae]

Doesn't commodities.plist tie into the ship's shipdata.plist entity key (the unique one) rather than its primary role? Or am I remembering it backwards and that's what I wanted it to be (by which your primaryRole change would work).

You remember that backwards and - /&%/$&§ - I just noticed that I exchanged freely the two "options" for my oxp. Well, something to fix again

Being able to define a commodities entry inside the shipdata of a dockable entity would be more intuitively pleasing imo too, btw.

[Commander McLane]

Yes, any entry in commodities.plist will be used for all entities which have the same primary role as the entry in commodities.plist is named.

The Wiki was always clear about that (and also about what all numbers in commodity.plist mean), so quite frankly it is a little beyond me why so many OXPs are so buggy in that respect.

At least I would expect every OXPer to playtest the station he has just given a commodities.plist entry of its own, and find out whether the prices found on that station can come from his commodities.plist, or not.

I made the same mistake with primary roles in Anarchies 1.0, and corrected it for version 1.1, when I had docked with a couple of Hacker Outposts and Salvage Gangs, and it was quite obvious that they didn't use my carefully composed commodities.plist-entries.

[DaddyHoggy]

Yes, any entry in commodities.plist will be used for all entities which have the same primary role as the entry in commodities.plist is named.

The Wiki was always clear about that (and also about what all numbers in commodity.plist mean), so quite frankly it is a little beyond me why so many OXPs are so buggy in that respect.

At least I would expect every OXPer to playtest the station he has just given a commodities.plist entry of its own, and find out whether the prices found on that station can come from his commodities.plist, or not.

I made the same mistake with primary roles in Anarchies 1.0, and corrected it for version 1.1, when I had docked with a couple of Hacker Outposts and Salvage Gangs, and it was quite obvious that they didn't use my carefully composed commodities.plist-entries.

The commodities plist in the YAH Constore leads to some potential in-system profiteering - sometimes, even wrong, its is serendipitous. (wrong as opposed to buggy)

[Kaks]

Update: v2633-5 implement a modification to the way Oolite interprets commodities.plist.

In trunk - and in 1.74+ - no oxp will be able to override commodities units of measure: food will be always weighed in tons, gem-stones in grams, etc... Apart from anything else, this avoids cargo randomly changing mass depending on which station the ship is docked at.

Combined to the previous fix (the one that stops Oolite from crashing), this will enable people to still use 'broken' oxps, and experience no breakage whatsoever.

While the crash fix is already in maintenance, due to the fairly extensive code rewriting needed to implement it, it's unlikely we'll be able to port this last feature change/fix to maintenance.