Scripters cove

[Rocketman]

Hi, Rocketman, and first of all welcome to the Friendliest Board This Side Of Riedquat™!

Thank you! Elite is game of my childhood. And I was happy to find out that such a sweet OS project does exist! I find idea of extensions pack quite intriguing (Oh... experiment. It is so exciting! ). So I'am here ))

I have started to dig in and used AITrader as guinea-pig. Mainly because it is quite simple. Of course I immediately noticed that respective authors of this OXp are using direct numeric definitions of prices, which in general is not usually condisered as "elegant" behaviour. Idea to make it more flexible was absolutely obvious and made me to lurk through API reffrence. Absense of common entity allowing access to main game configs was confusing, so I've decided to clear it up here.

Thank you for your answers.

Most of the rest of the configuration is hidden. That's just the way it is.

Is it result of development policy or simply does not implemented yet? Why not to make global object which provides read-only access to all game configs? I think it would give OXP makers way to improove compatibility of their projects. And would be useful tool in general.

[JensAyton]

Why not to make global object which provides read-only access to all game configs?

Because correctly parsing the various plists is complicated and the rules change with each release. There is no way OXPs could consistently extract accurate information from a raw representation. In most cases, there isn’t a “normalized” representation that could be exposed directly.

There’s no policy against revealing the information, but it has to be handled differently in each case, and it requires someone to do that work instead of doing some other work.

[Commander McLane]

Most of the rest of the configuration is hidden. That's just the way it is.

Is it result of development policy or simply does not implemented yet? Why not to make global object which provides read-only access to all game configs? I think it would give OXP makers way to improove compatibility of their projects. And would be useful tool in general.

As I said already:

Indeed, most of the properties defined in the various plists are exposed to the JS-scripting engine. There are a few exceptions, mainly because something hasn't been implemented yet. Unfortunately, commodities.plist is among these exceptions.

As you see, I disagree with Wildeblood here. While he claims that most of the configuration is hidden, I say that most of it is exposed, and mostly only those parts which haven't been implemented yet are not.

This has historical reasons, as well. The JS-scripting engine is a relatively recent addition to Oolite. The previous stable version (1.65) only relied on property lists for setting up the configuration, and for a (very limited!) amount of scripting. Over the course of the last few years and the last 10 versions of the game (starting with 1.67; 1.66 was omitted as a number by accident) the JS-scripting engine was introduced and has matured. During the process of converting from plist-scripting (also referred to as legacy-scripting) to JS-scripting more and more of the underlying configuration had to be made accessible for the JS-scripting engine. However, this must be understood as an ongoing process. The game is by no means at the end of its development.

As it happens, nobody took it on yet to convert the price-setting mechanism to JS, although among those who dived into the existing price-setting mechanism there is sort of a consensus that it is indeed rather clumsy. But a fundamental change to this part of the inner workings of Oolite hasn't been high up on the priority list of the developers yet (probably it hasn't been anywhere on this list), whose resources are of course limited.

Having said that, I personally think that Oolite's general approach to configuration is quite sensible: define those things that have to be said and done at the moment the game starts, and need to be fixed after this point, in property lists, because property lists are well suited for that purpose. And expose those properties that may need to be changed—or need to be known—by a script during gameplay to the JS-engine.


EDIT: our ex-lead developer has stepped in and given a short and concise explanation just above.

[Rocketman]

Ok, I see. Thank you very much!

[Wildeblood]

Most of the rest of the configuration is hidden. That's just the way it is.

Is it result of development policy or simply does not implemented yet? Why not to make global object which provides read-only access to all game configs? I think it would give OXP makers way to improove compatibility of their projects. And would be useful tool in general.

As I said already:

Indeed, most of the properties defined in the various plists are exposed to the JS-scripting engine. There are a few exceptions, mainly because something hasn't been implemented yet. Unfortunately, commodities.plist is among these exceptions.

As you see, I disagree with Wildeblood here. While he claims that most of the configuration is hidden, I say that most of it is exposed, and mostly only those parts which haven't been implemented yet are not.

I've been verballed, m'lord! I said of Config/*.plist, that shipdata.plist and planetinfo.plist were mostly exposed, and most of the rest were hidden. That doesn't disagree at all with the proposition that "Most of the properties defined in the various plists are exposed", since most are defined in shipdata or planetinfo.

But giving scripts access to commodities and illegal goods would be nice. (Or moving illegal goods into planetinfo, so they could be defined system by system.)

[Smivs]

When an item is scooped, there is a console message

item scooped

Can this be disabled?

[Thargoid]

has_scoop_message in shipdata.plist may be what you're after?

[Smivs]

has_scoop_message in shipdata.plist may be what you're after?

It is, thank you.

[Rese249er]

Would someone be willing to help me with a bit of coding?

I need a script that will spawn a ship if an escape pod or a cargopod with slaves in it is within scanner range of any police ships, but only a limited number for each system? It'd also be great if they launched from the main station.

[Smivs]

The slaves-in-a-cargo-pod might be a problem. Technically the contents of a pod are unknown to the game until it is scooped by the player at which point the player is awarded some more or less random cargo. The point is a cargo pod spawned by the game engine has no specific cargo until it is scooped. This does not apply to some OXP pods of course.

[Rese249er]

Would it be possible without the slave pod feature then?

[cim]

The slaves-in-a-cargo-pod might be a problem. Technically the contents of a pod are unknown to the game until it is scooped by the player at which point the player is awarded some more or less random cargo. The point is a cargo pod spawned by the game engine has no specific cargo until it is scooped. This does not apply to some OXP pods of course.

In 1.77, the ship.commodity and ship.commodityAmount properties will be available. In current trunk, pod cargo is defined on creation. This may not necessarily be true in 1.76 - I haven't checked.

[Wildeblood]

Rese249er, Escape Pod Locator OXP should be doing this already: as well as offering the escape pod locator equipment item, it should be launching search-and-rescue ships to retrieve escape pods.

[Eric Walch]

In 1.77, the ship.commodity and ship.commodityAmount properties will be available. In current trunk, pod cargo is defined on creation. This may not necessarily be true in 1.76 - I haven't checked.

Cargopod content is defined on pod creation, except for the scripted pods. For the scripted pods content could be defined in the shipSpawned script, but also not sooner than on scooping. Or never, but those cases are not interesting in this situation. This is all valid for both trunk and older Oolite versions.

But it needs trunk to detect the content by scanning.

About Escape Pod Locator OXP: I am not familiar with is, but I assume it only scans for role or for cargo with pilots in it and misses cargopods with slaves in it.

[Rese249er]

I was hoping to get a script to spawn a Police Viper with some under-the-hood tweaks so that it can scoop pods.