Urgent scripting requests

JensAyton · Post by **JensAyton** » Wed Dec 17, 2008 11:46 pm

Fulfilling all scripting requests before declaring a stable release is an impractical an counterproductive goal. Therefore, we need to triage.

This thread is for one thing only: legacy scripting features that are used in released OXPs and which have no JavaScript equivalent. Off-topic posts will be deleted.

Commander McLane · Post by **Commander McLane** » Thu Dec 18, 2008 8:14 am

Not exactly a legacy scripting feature, so feel free to delete or move someplace else:

The shipdata has_foo properties are not yet visible to JS (anything between has_cloaking_device and has_shield_enhancer, with the exception of has_npc_traffic of course, which is something different).

It would be worthwhile to make them read/write as well.

Commander McLane · Post by **Commander McLane** » Thu Dec 18, 2008 11:22 am

Browsing through the methods I see that everything has been ported to JS. With the possible exception of status_string (from the Querying states/Player status-section), at least I wouldn't know how to query it from JS.

I don't know how useful the implementation of all the mentioned states in JS would be, though. Some are similar to event handlers.

By the way: I know (from other JS-scripts) that gui_screen_string and galaxy_number are available to JS as guiScreen and galaxyNumber respectively. I don't know, however, whether this is documented anywhere. And methinks it is not very JS'ey, if you know what I mean. Shouldn't both be properties of something (GUI and System, respectively)?

On another note: Shouldn't all player.alertFoo-properties live in PlayerShip?

Svengali · Post by **Svengali** » Thu Dec 18, 2008 11:39 am

A equivalent to setGuiToxyzScreen would be nice.

Post by **Eric Walch** » Thu Dec 18, 2008 12:27 pm

A equivalent to setGuiToxyzScreen would be nice.

And linked to this: switching to the long_range_chart with a system to highlight as parameter. It should already be in the code in some form as the function that brings you to this screen from the F8/F8 screen. I just don't know how difficult it is to access that current internal function with parameter with a JS command.

It would be great for mission offers like in random hits.

With the new System.info property you added the last legacy thing to JS I think. All other things are in as far as I see it. Or can be handled in a lightly different way by event handlers like status_string. And we already have a foo.docked true/false

Wiki pages · Post by **Thargoid** » Tue Feb 03, 2009 11:19 am

Would it be possible to have the "spawn" shipdata.plist key exposed to and utilised by Javascript (and XML)? So that if an entity with such a key in is spawned with a JS command then the position and/or facing information in the spawn key is used?

It works well for planetinfo.plist spawns, but is completely ignored by JS spawning.

Commander McLane · Post by **Commander McLane** » Tue Feb 03, 2009 11:51 am

Thargoid wrote:
Would it be possible to have the "spawn" shipdata.plist key exposed to and utilised by Javascript (and XML)? So that if an entity with such a key in is spawned with a JS command then the position and/or facing information in the spawn key is used?

I don't know. The legacy spawnShip method and the spawn directory in shipdata are weirdly broken, and have always been. In about half the cases it doesn't use the facing information in the directory, at least not in a way that the entity would be facing in the direction indicated. Some people (Kaks?, Cmdr James?) were working on it for some time, but ultimately without a satisfactory result.

Therefore, and because JS offers an easy (and so far fool-proof) way of setting the orientation of entities, I would vote for completely dropping the spawnShip way of spawning ships, and use a JS-ship script instead. So I would recommend against using the spawn directory in new shipdata.plists. (Of course, 1.65 scripts will continue to use it, and will work inasmuch they worked in 1.65 in the first place. Which is not a given, as stated above.)

Wiki pages · Post by **Thargoid** » Tue Feb 03, 2009 11:58 am

The implementation as triggered by use in a planetinfo.plist always seems to work for me as I expect it to?

I understand what you mean though, but personally it's simpler to have the option to have the spawned entity facing a given co-ordinate position (in the spawn shipdata key) rather than have to break my brain working out an orientation quaternion. Especially for those times when I don't particularly care about its rotational direction along the axis pointing at the co-ordinates (given space has no practical up and down anyway).

I know you can do it with a little JS function, but then each entity spawned has to have a script action to run it to redo the orientation. Having it in the shipdata removes that added complication.

Commander McLane · Post by **Commander McLane** » Tue Feb 03, 2009 12:17 pm

Thargoid wrote:
it's simpler to have the option to have the spawned entity facing a given co-ordinate position (in the spawn shipdata key) rather than have to break my brain working out an orientation quaternion.

If it works, yes. The last thing I heard from it was that if you imagine the planet (or the origin of the internal coordinate system, I'm not sure) to be surrounded by four quadrants, the facing of a given co-ordinate position does not work in two of these quadrants. And that's half of the space in each system.

Unfortunately this doesn't seem to be documented in the bug tracker. I was mainly having a PM exchange with Kaks while he tried to solve the problem. At least here is my initial bug report on the board. And here is where Kaks first thought he had solved it. Later it turned out he hadn't quite caught everything, and I don't think he ever solved it completely. But unfortunaly the PMs he sent me afterwards are lost in the maelstrom of time...

Commander McLane · Post by **Commander McLane** » Wed Feb 04, 2009 12:43 pm

In addition to my first post above, it would be nice to have the values of equipment_price_factor and, while we're at it, even equivalent_tech_level (and whatever useful properties there are defined in shipdata) available in JS, I guess as properties of Station.

(If they are already, please tell me so. At least it's not mentioned in the wiki.)

Post by **Eric Walch** » Sun Jan 31, 2010 6:53 pm

Reading through old requests I noted most of them are already implemented for 1.74 some time ago.

Commander McLane wrote:
The shipdata has_foo properties are not yet visible to JS (anything between has_cloaking_device and has_shield_enhancer, with the exception of has_npc_traffic of course, which is something different).

It would be worthwhile to make them read/write as well.

ship_foo.hasEquipment(), ship_foo.awardEquipment() and ship_foo.removeEquipment() will also work for npc ships.

so

Code: Select all

If (!ship_foo.hasEquipment("EQ_SHIELD_ENHANCER") ship_foo.awardEquipment("EQ_SHIELD_ENHANCER"

will be possible

Commander McLane wrote:
In addition to my first post above, it would be nice to have the values of equipment_price_factor and, while we're at it, even equivalent_tech_level (and whatever useful properties there are defined in shipdata) available in JS, I guess as properties of Station.

They will be a property of station in 1.74

Commander McLane wrote:
I would vote for completely dropping the spawnShip way of spawning ships, and use a JS-ship script instead. So I would recommend against using the spawn directory in new shipdata.plists. (Of course, 1.65 scripts will continue to use it, and will work inasmuch they worked in 1.65 in the first place. Which is not a given, as stated above.)

I agree. 1.74 will have a new command to make this even easier:

Code: Select all

var ship = system.addShips('myShip", 1, [x,y,z]);
ship.orientation = [x,y,z,w];

Instead if putting the positon and orientation inside the spawn directory you can define both flexible in JS.