Scripting requests

An area for discussing new ideas and additions to Oolite.

Moderators: another_commander, winston

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5803
Joined: Wed Feb 28, 2007 7:54 am

Re: Scripting requests

Post by another_commander »

Wildeblood wrote: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.

User avatar
Commander McLane
Intergalactic Spam Assassin
Intergalactic Spam Assassin
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Scripting requests

Post by 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.

User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Re: Scripting requests

Post by Kaks »

Ah yes, shipTakingDamage also firing when ships are taking damage 0! I remember that well - it's working as designed as per http://www.aegidian.org/bb/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...
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)

User avatar
Thargoid
Thargoid
Thargoid
Posts: 5510
Joined: Thu Jun 12, 2008 6:55 pm

Re: Scripting requests

Post by 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).

User avatar
CommonSenseOTB
---- E L I T E ----
---- E L I T E ----
Posts: 1397
Joined: Wed May 04, 2011 10:42 am
Location: Saskatchewan, Canada

Re: Scripting requests

Post by CommonSenseOTB »

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

http://aegidian.org/bb/viewtopic.php?f=4&t=12507
Take an idea from one person and twist or modify it in a different way as a return suggestion so another person can see a part of it that can apply to the oxp they are working on.


CommonSense 'Outside-the-Box' Design Studios Ltd.
WIKI+OXPs

Storm
Dangerous
Dangerous
Posts: 91
Joined: Mon Jan 30, 2012 10:27 pm
Location: UK

Re: Scripting requests

Post by 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
Harmless
Harmless
Posts: 1
Joined: Thu Oct 04, 2012 4:16 am

Re: Scripting requests

Post by 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);
}

User avatar
Thargoid
Thargoid
Thargoid
Posts: 5510
Joined: Thu Jun 12, 2008 6:55 pm

Re: Scripting requests

Post by 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?

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: Scripting requests

Post by cim »

Storm wrote: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.
Thargoid wrote: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.

User avatar
Thargoid
Thargoid
Thargoid
Posts: 5510
Joined: Thu Jun 12, 2008 6:55 pm

Re: Scripting requests

Post by 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.

User avatar
Thargoid
Thargoid
Thargoid
Posts: 5510
Joined: Thu Jun 12, 2008 6:55 pm

Re: Scripting requests

Post by 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).

User avatar
cim
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 4018
Joined: Fri Nov 11, 2011 6:19 pm

Re: Scripting requests

Post by cim »

Thargoid wrote: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.

User avatar
Thargoid
Thargoid
Thargoid
Posts: 5510
Joined: Thu Jun 12, 2008 6:55 pm

Re: Scripting requests

Post by 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.

User avatar
Commander McLane
Intergalactic Spam Assassin
Intergalactic Spam Assassin
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Re: Scripting requests

Post by 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.) :wink:

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 5803
Joined: Wed Feb 28, 2007 7:54 am

Re: Scripting requests

Post by another_commander »

Commander McLane wrote: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.) :wink:
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.

Post Reply