displayNameForCommodity

[Wildeblood]

http://wiki.alioth.net/index.php/Oolite ... rCommodity

displayNameForCommodity
function displayNameForCommodity(commodityName : String)

Returns the display name corresponding to the specified commodity. Useful in conjunction with localisation OXPs, or expansions that rename commodities depending on which station / system the player is at.

I read that to mean that feeding this function something like "gemStones" would return something like "Gem-Stones", and assumed that offering it something like 1 would produce an error.

> displayNameForCommodity(furs);
Exception: ReferenceError: furs is not defined
Active script: oolite-debug-console 1.76
oolite-debug-console.js, line 839:
}
> displayNameForCommodity("furs");
Furs
> displayNameForCommodity("gemStones");
gemStones
> displayNameForCommodity("gem-stones");
Gem-Stones
> displayNameForCommodity("Gem-Stones");
Gem-Stones
> displayNameForCommodity("1");
1
> displayNameForCommodity(2 + 2);
4

How do I make this work?

Addendum: I'm trying to use this function like this:-

Code: Select all

this.$previousGain = function(commodityName, gain)
	{
	var cargo = displayNameForCommodity(commodityName);
	player.consoleMessage("The last time we traded " + cargo + " we gained " + gain + " credits.",7)
	}

where the commodityName passed to it will be one of these:-

Code: Select all

this.cargoType = ["food", "textiles", "radioactives", "slaves", "liquorWines", "luxuries", "narcotics", "computers", "machinery", "alloys", "firearms", "furs", "minerals", "gold", "platinum", "gemStones", "alienItems"];

[cim]

If your descriptions.plist is in English then this function does very little visible indeed.

Given a parameter X it looks for "commodity-name X" in descriptions.plist. If it finds it, it returns the contents of that description, otherwise it returns X (converted to a string, if it wasn't already).

displayNameForCommodity("gem_stones"); is possibly slightly more obvious that it's doing something.

[Wildeblood]

...this function does very little visible indeed.

Given a parameter X it looks for "commodity-name X" in descriptions.plist. If it finds it, it returns the contents of that description, otherwise it returns X (converted to a string, if it wasn't already)...

Hey, that's what I was just about to add - I've just checked in descriptions.plist to confirm my suspicion.

So, is displayNameForCommodity(x) any different from expandDescription("commodity-name " + x) ?

How do I get from the property names used in the manifest object to the commodity name descriptions in a reasonable number of steps?

[cim]

So, is displayNameForCommodity(x) any different from expandDescription("commodity-name " + x) ?

Yes, if X isn't in descriptions. It also lower-cases X. So if X is "Liquor/wines" then displayNameForCommodity will return "Liquor/Wines" but expandDescription will return "commodity-name Liquor/wines".

How do I get from the property names used in the manifest object to the commodity name descriptions in a reasonable number of steps?

Easiest is possibly to add some extra commodity-name rows ("liquorwines", "alienitems", "gemstones") to descriptions.plist, then use displayNameForCommodity.

For New Cargoes I made this function and used it instead.

Code: Select all

function(type) {
	if (type == "liquorWines") {
		return expandDescription("[commodity-name liquor/wines]");
	} else if (type == "alienItems") {
		return expandDescription("[commodity-name alien items]");
	} else if (type == "gemStones") {
		return expandDescription("[commodity-name gem-stones]");
	} else {
		return expandDescription("[commodity-name "+type+"]");
	}
}

[JensAyton]

The JS Manifest object supports manifest.gemStones and manifest.gem_stones as alternatives to the canonical name, which is manifest["gem-stones"]. Similarly, the canonical names for alien items and liquor/wines are "liquor/wines" and "alien items" respectively. The canonical names also work with displayNameForCommodity(). (The canonical names for all items are the same as in commodities.plist, but all-lowercase.)

In retrospect, the alternative names were ill-concieved; in addition to causing problems like this, the JS manifest object is the only place where commodity properties are hard-coded in the game. I recommend always using the canonical names, and I’m leaning towards suggesting the alternative names should be deprecated.

[Commander McLane]

In retrospect, the alternative names were ill-concieved; in addition to causing problems like this, the JS manifest object is the only place where commodity properties are hard-coded in the game. I recommend always using the canonical names, and I’m leaning towards suggesting the alternative names should be deprecated.

Seems sensible. I think all scripters (and they are the only ones concerned) can be bothered to learn and use the correct canonical names. That's not asking too much.

[Eric Walch]

Code: Select all

this.$previousGain = function(commodityName, gain)
	{
	var cargo = displayNameForCommodity(commodityName);
	player.consoleMessage("The last time we traded " + cargo + " we gained " + gain + " credits.",7)
	}

As the wiki writes, it is useful to get the localised names. e.g. when running a German version, you get the German words for the commodities. But than trying to use the localised names in hard coded English text seems weird.

[Wildeblood]

As the wiki writes, it is useful to get the localised names. e.g. when running a German version, you get the German words for the commodities. But then trying to use the localised names in hard coded English text seems weird.

Well, I first have to figure out how a function actually works, before I can decide whether or not it could be useful. But do not assume that only people wanting a completely different language from English ever edit descriptions.plist: if someone has e.g. altered radioactives (which is not a real word) to radio-isotopes it would be nice if my script reflected that change.

[Kaks]

The JS Manifest object supports manifest.gemStones and manifest.gem_stones as alternatives to the canonical name, which is manifest["gem-stones"]. Similarly, the canonical names for alien items and liquor/wines are "liquor/wines" and "alien items" respectively. The canonical names also work with displayNameForCommodity(). (The canonical names for all items are the same as in commodities.plist, but all-lowercase.)

In retrospect, the alternative names were ill-concieved; in addition to causing problems like this, the JS manifest object is the only place where commodity properties are hard-coded in the game. I recommend always using the canonical names, and I’m leaning towards suggesting the alternative names should be deprecated.

Agree on canonical names, and very much about dropping the alternative ones: IIRC, I did write a few comments about how wrong it felt to sopport not one, not two, but 3 different names for the same property!


However misguided it was, the extra camelCase version was following to the letter ancient & revered javascript rites ( if you look at the various DOM documentations, you'll see that basically all hyphenated css properties that can be applied to a piece of html are available via JS, but only via their camelCase javascriptified version....)


One point I'd like to make though, is that at the time the manifest object was created - a couple of years back - I seem to also remember that the idea was to eventually change the canonical names from 'alien items', 'liquor/wines','gem-stones' to the more standardised 'alien_items', 'liquor_wines' & 'gem_stones', along the same lines as what happened to the 'isCarrier' & 'scanClass' keys inside shipdata, now 'reborn' as 'is_carrier' and 'scan_class'.


I'd still very much go for finishing the job of converting the canonical names everywhere to the underscored versions: if nothing else, they - err - underscore the fact they're supposed to be 'programmery' canonical names, rather than just the english plain text they started out as, well before the time we even had a difference between display names and internal strings.


I'll take my coat now!

[JensAyton]

One point I'd like to make though, is that at the time the manifest object was created - a couple of years back - I seem to also remember that the idea was to eventually change the canonical names from 'alien items', 'liquor/wines','gem-stones' to the more standardised 'alien_items', 'liquor_wines' & 'gem_stones', along the same lines as what happened to the 'isCarrier' & 'scanClass' keys inside shipdata, now 'reborn' as 'is_carrier' and 'scan_class'.

I don’t know if that was the thought at the time, but it seems dangerous given that – as this thread underscores – the Manifest keys need to match what’s in the actual commodity definitions, including the manifests serialized in saved games.

[Kaks]

Hmm, both commodity definition and savegame stuff can be sorted out relatively painlessly, retaining the old canonical names recognition for old save games - as when we switched to a proper equipment list in savegames...


Anyway, definitely dangerous, expecially the incomplete / broken way it's in trunk now!