Scripting requests

[another_commander]

On an unrelated note, I have some (very, very simple, uncontroversial) code changes I'd like incorporated into trunk. Who can I send it to?

You can contact any of the dev team members by email for submitting patches and ideas (my address is another_commander at oolite point org in case you would want to send your changes this way). The receiver will forward your email for discussion internally and, if approved, the changes can go in and you get a mention in the hall of fame of contributors. We encourage external contributions and ideas, but I must note that there has to be some filtering and control before an idea makes it into the mainline.

[Commander McLane]

Just noticing that we have no energy- and shield-related world script events, like shipEnergyBecameFull, shipEnergyIsLow, shieldsDepleted, shieldsBecameFull, etc. (We'd probably need the shield-related handlers as twins for forward and aft shields.)

Do we need them? Or would it be good to have them?

Their function can mostly be emulated by using shipTakingDamage* and checking for shield and energy status right there, but perhaps it would be nice to have them anyway?


______________
* shipTakingDamage is incorrectly documented, by the way. First of all, it appears only under the ship script event handlers, although it applies to the player ship as well. And second of all, it does also fire when the player ship shields are still up.

[Kaks]

Ah yes, shipTakingDamage also firing when ships are taking damage 0! I remember that well - it's working as designed as per https://bb.oolite.space/viewtopic.php?f=4&t=11853 - though I was under the impession the documentation had been updated...

The new events you mentioned whould be useful for a js-only AI...

[Thargoid]

Yes, please don't change takingDamage firing but returning zero for hits to the shields. It is indeed exactly how it was designed, and works perfectly for what I originally wanted it for (for IronHide).

[CommonSenseOTB]

I agree with Thargoid. A good example of the shipTakingDamage function working as intended can be found here:

https://bb.oolite.space/viewtopic.php?f=4&t=12507

[Storm]

For the shiney new Visual Effects, we have the Scale(factor) function. Would it be possible to add a ScaleX(factor), ScaleY(factor), and ScaleZ(factor) as well to stretch on one particular axis please?

[nyurik]

For various trading addons, please expose stationEntity.localMarket to js. I only need readonly access to prices and qty, but I guess there could be others who might want to change market pricing as well. Something like this would be nice (from js):

Code: Select all

food = station.localMarket['food'].price;

mkt = station.localMarket;
for(cmdty in mkt)
{
   m = mkt[cmdty];
   Log("Commodity " + cmdty + " price=" + m.price + " qty=" + m.quantity);
}

[Thargoid]

Would it be possible to allow a specified gui screen to be called when leaving a mission screen, rather than always going back to the status screen? Or even more ideally to have the selection fully scriptable?

[cim]

Would it be possible to add a ScaleX(factor), ScaleY(factor), and ScaleZ(factor) as well to stretch on one particular axis please?

Flasher sub-entities would remain spherical - though they could be recentred appropriately, and I suppose should be resized to ∛factor. Otherwise, I think it's possible. I'll have a look at it, anyway.

Would it be possible to allow a specified gui screen to be called when leaving a mission screen, rather than always going back to the status screen? Or even more ideally to have the selection fully scriptable?

Specifying the exit screen (within reason, while docked) can be done. Making guiScreen writable I think would be too dangerous.

[Thargoid]

When docked would be fine. I was thinking that way we could use mission screens to "man in the middle" detour a selection of a screen to allow for additional selections, warnings or other stuff before continuing on to the original destination.

For example your recent changes to the station market screens could open up having different prices for buying and selling (to make trade a bit more realistic) but a half-way house to allow choice of whether you're buying or selling would be needed first. It can be done now, but it would be a very awkward way rather than being able to do it en-route to the marketplace screen.

[Thargoid]

And one additional request - could we have a little extension to the station market improvements already made to give us station.setMaxQuantity(commodity,limit)?

My thinking is that way we can make smaller markets more realistic by limiting the amount that can be sold to them (below the current generic limit of 127t), and also with some manipulation do things like a buyer-only market (by setting the max quantity to what it currently is, then you could buy but not sell anything, or only sell back what you've just bought in case of mistake).

Here I mean a maximum quantity that a market will accept to hold dynamically, not the maximum it offers initially for sale (which can already be done via the existing functionality).

[cim]

My thinking is that way we can make smaller markets more realistic by limiting the amount that can be sold to them (below the current generic limit of 127t), and also with some manipulation do things like a buyer-only market (by setting the max quantity to what it currently is, then you could buy but not sell anything, or only sell back what you've just bought in case of mistake).

I'll have a look, but in the meantime you've got read-write access to both the station and the player market, and world events for buy and sell. If the player tries to sell over the current market limit, give them the item and money back, and take it off the market. This all happens between screen refreshes, so the goods will never appear to hit the market.

[Thargoid]

I had thought of that - the only potential issue may be handling the "sell all" action but I've yet to play with it and see. Plus the limit function would be a bit cleaner and simpler to implement from script-side.

Anyway thanks for the efforts so far, and I'll start playing on this idea in a while.

[Commander McLane]

Can the station_roll-key be exposed to JS, preferably r/w? That would provide an alternative method to set it, and would allow for more flexibility than the current plist-approach. It would probably make sense to only allow setting the property when the station is created, thus during the spawned event, in order to avoid strange wiggling. (But if you want to allow strange wiggling, that'd be fine, too.)

[another_commander]

Can the station_roll-key be exposed to JS, preferably r/w? That would provide an alternative method to set it, and would allow for more flexibility than the current plist-approach. It would probably make sense to only allow setting the property when the station is created, thus during the spawned event, in order to avoid strange wiggling. (But if you want to allow strange wiggling, that'd be fine, too.)

Done in r5475. The station roll OOJSStation property is called 'roll' (surprise!), is read/write and is clamped between -2.0 and 2.0. You can set it at any moment you like. Use it wisely though, because it would generally look silly changing the station rotation on the fly for no good reason.