Scripting requests

[Cody]

Can the station_roll-key be exposed to JS, preferably r/w?

Done in r5475.

Amazing what a cherry can do, eh?

[Commander McLane]

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!

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

[Thargoid]

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

[another_commander]

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.

[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]

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?

[Smivs]

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

That sounds useful

[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).

[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?

[Commander McLane]

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.

[JensAyton]

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.

[Commander McLane]

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 ₢.

[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

[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.

[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.