Scripting requests

An area for discussing new ideas and additions to Oolite.

Moderators: another_commander, winston

User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 13805
Joined: Sat Jul 04, 2009 9:31 pm
Location: Corke's Drift
Contact:

Re: Scripting requests

Post by Cody »

another_commander wrote:
Commander McLane wrote:Can the station_roll-key be exposed to JS, preferably r/w?
Done in r5475.
Amazing what a cherry can do, eh?

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 »

another_commander wrote:Done in r5475. The station roll OOJSStation property is called 'roll' (surprise!), is read/write and is clamped between -2.0 and 2.0.
Thanks! :D

Out of interest: is station_roll also clamped? The Wiki only mentions its default, not a clamp.

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

Re: Scripting requests

Post by Thargoid »

You mean I can't write station scratch-mix OXP? :twisted: :lol:

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

Re: Scripting requests

Post by another_commander »

Commander McLane wrote:Out of interest: is station_roll also clamped? The Wiki only mentions its default, not a clamp.
station_roll does not seem to be clamped. However, I thought that not clamping it to something sensible in JS would be kind of daft (especially after trying it myself unclamped and seeing what happens with crazy values - see Thargoid's comment above my post).

It would be very easy to remove the clamp if that is so desired, but I would advise against it.

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 »

Another question about the new roll key:

It's been put up on the Wiki as a read-only property of Ship. Shouldn't it be a read/write property of Station instead? (Or at least, if it is in fact readable for all ships, it should also be put on the Station page as r/w.)

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

Re: Scripting requests

Post by Storm »

cim wrote: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.
Cool, that will open up a few possibilities for special FX. Thanks cim. :)

Would a restoreSubentity(number) be feasible, restoring a single specified subentity from a ships plist data?

User avatar
Smivs
Retired Assassin
Retired Assassin
Posts: 8408
Joined: Tue Feb 09, 2010 11:31 am
Location: Disunited Kingdom
Contact:

Re: Scripting requests

Post by Smivs »

Storm wrote: Would a restoreSubentity(number) be feasible, restoring a single specified subentity from a ships plist data?
That sounds useful :)
Commander Smivs, the friendliest Gourd this side of Riedquat.

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

Re: Scripting requests

Post by Thargoid »

If it's not too late, can I request a new command addRoles to shipdata-override.plist. Functionality to tack its given roles onto the existing role list of the entity it's overriding, rather than replacing it (that functionality would remain within shipdata-override via using the role key there as now).

User avatar
Wildeblood
---- E L I T E ----
---- E L I T E ----
Posts: 2161
Joined: Sat Jun 11, 2011 6:07 am
Location: Western Australia
Contact:

Re: Scripting requests

Post by Wildeblood »

Not a request for any change at all, just to make a custom property "official" and document it as a feature, not a bug. I've been using system.info.sun_name to hold a string representing the name of the system's star.

Can we all agree that system.info.sun_name is (1a) unset by default (1b) currently ignored by Oolite but may be read by OXPs, and if set (2a) must be a text string which (2b) should represent the name of the system's star?

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 »

Wildeblood wrote:Not a request for any change at all, just to make a custom property "official" and document it as a feature, not a bug. I've been using system.info.sun_name to hold a string representing the name of the system's star.

Can we all agree that system.info.sun_name is (1a) unset by default (1b) currently ignored by Oolite but may be read by OXPs, and if set (2a) must be a text string which (2b) should represent the name of the system's star?
I'm not one of the boffins, but I think JavaScript doesn't quite work that way.

Yes, you can arbitrarily add properties to any object. These will be visible for all scripts, because they're attached to the object, not to any specific script. But you can't prevent anybody else from doing the same.

Also, according to the standard the developers chose, all properties and methods are written in "CamelCase". Thus I'd expect your custom property to be named "sunName". (I understand that you don't like to follow naming conventions, although I don't understand the reasons for this.)

As far as custom functions are concerned, the convention is to distinguish them from the standard functions by preceding their name with either "_" or "$". If you adopt this convention, you could call your property "_sunName". However, because the property is attached directly to an object, not to a script, this still isn't secure. Another script can still create the same property. (This is different from creating a custom function, because the custom function is property of its script. Thus, if you and I both create the function "this._doStuff()", they're still not the same and don't override each other, because the "this" means something different. Yours is actually called "worldScripts["yourScript"]._doStuff()" and mine is actually called "worldScripts["myScript"]._doStuff()".)

Thus, the other convention to keep in mind is to make things unique by using your name. Call your custom property "wildebloodSunName", and you'll be reasonably sure that nobody else will create the same property. Also, it leaves other scripters the freedom to create "McLaneSunName" etc. (I have no intention of creating a sun name property myself, it's just an example.)

All of that is said from my rather lay perspective. I'm sure one of the boffins will be able to further clear things up.

User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Re: Scripting requests

Post by JensAyton »

Commander McLane wrote:Thus, the other convention to keep in mind is to make things unique by using your name. Call your custom property "wildebloodSunName", and you'll be reasonably sure that nobody else will create the same property. Also, it leaves other scripters the freedom to create "McLaneSunName" etc. (I have no intention of creating a sun name property myself, it's just an example.)
I think the point here is that a single, shared sun name property would be more useful than different OXPs using different names.

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 »

JensAyton wrote:
Commander McLane wrote:Thus, the other convention to keep in mind is to make things unique by using your name. Call your custom property "wildebloodSunName", and you'll be reasonably sure that nobody else will create the same property. Also, it leaves other scripters the freedom to create "McLaneSunName" etc. (I have no intention of creating a sun name property myself, it's just an example.)
I think the point here is that a single, shared sun name property would be more useful than different OXPs using different names.
… if we agree that suns need names in the first place.

Also, we've had debates about freedom of OXP'ers to do what they want without restriction before, and if I recall correctly, Wildeblood was on the side of those who wanted to be restricted as little as possible. Therefore, a request that all other OXP'ers be restricted by making an idea of his a quasi-standard for everybody strikes me as inconsistent.

My 0.2 ₢.

User avatar
Wildeblood
---- E L I T E ----
---- E L I T E ----
Posts: 2161
Joined: Sat Jun 11, 2011 6:07 am
Location: Western Australia
Contact:

Re: Scripting requests

Post by Wildeblood »

Dear developers, here is my scripting request:=

Please implement a method by which either a player or an OXP author can specify names for the system suns, and make those names generally available to javascript. Please make it readable and writeable from javascript. Please also make it settable from a .plist file for the benefit of players who have better things to do than learn javascript. There is no need to implement any related function in game-play, as I envision this is would be most suitable as an "ambience" feature exposed by OXPs only to players who want it; it would be of little interest to players who see Oolite strictly as a shoot-em-up game.

Important considerations:
- Do not implement this proposal by using the existing behaviour of Oolite in loading key-value pairs from planetinfo.plist into the system.info javascript object. That would be cheating. I expect you to do this by writing new code, that will create a new javascript object, and require a new .plist file to configure.
- Under no circumstances find something compatible with 1.76; I want a new feature that will only work in trunk.
- Ignore the demonstration OXP I have already created.

OK bye THNX

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

Re: Scripting requests

Post by Thargoid »

Might one suggest as an alternative that .name and .displayName (or .display_name) could be assigned to all system objects (planets, moons and sun) in the same way as it is for more mundane entities? That way they can be read/written/manipulated as with anything else.

I know they can't be seen in the normal way of a target lock, but as noted they could be visible via things like the ASC or just via scripting. At the moment those keys aren't defined (although I am using them in Planetary Compass for the moons and planets, but only as general properties and there only set if they don't already exist) but could easily be done. And if they could also be set via planetinfo.plist if that way is used to create the body then it would indeed be simpler for non-scripters too.

Just a thought to add to the discussion.

User avatar
Wildeblood
---- E L I T E ----
---- E L I T E ----
Posts: 2161
Joined: Sat Jun 11, 2011 6:07 am
Location: Western Australia
Contact:

Re: Scripting requests

Post by Wildeblood »

So, if no-one has any rational objections, I'll add sun_name to the planetinfo page on the wiki, right after sun_color, sun_distance_modifier and sun_gone_nova and before sun_radius.
Last edited by Wildeblood on Wed Nov 14, 2012 8:30 pm, edited 1 time in total.

Post Reply