Talk:Oolite JavaScript Reference: System

I'd like to suggest a new system feature.

I see that interstellarspace cannot be altered. This prevents several proposed hacks to create customsystems outside of the documented range (0-254) per galaxy.

I propose a isCustomSystem to supplement the isInterstellarSpace flag. If both flags are true, interstellar_space (eg uncharted space) can be altered by script. If customSystem is not scripted, revert flag to false. (But the flag should be set to true in the systemScript in the first place) --Arexack 13:17, 7 August 2007 (BST)

addShips()

As per this post I'd like to propose the following parameters for a new addShips() method which will supersede all the legacy_foo() methods:

addShips(role, count, coordScheme, where, [radius], [witchspace cloud])

The first four parameters should be self-explanatory, they are the existing parameters of legacy_addShipsAt().

The optional parameter radius adds the ship(s) within the given radius around the given position, thereby including legacy_addShipsWithinRadius(). This also includes legacy_addShipsAtPrecisely(), if the radius is set to 0.

The optional parameter witchspace cloud determines whether or not the ship(s) appear(s) out of a blue sphere, as if exiting witchspace, or not. Currently the blue sphere is only drawn for legacy_addShips(). Default should be true.

The current legacy_addShips() would therefore become equivalent to addShips(role, count, "wpm", [0, 0, 0], 25600) or addShips(role, count, "abs", [0, 0, 0], 25600) respectively (or whatever currently defines the center and size of the spawning area), and thus be included as well.

The only method which is currently different from all the others is legacy_addSystemShips(), because it adds ships on the line between witchpoint and main station (as opposed to the line between witchpoint and planet). But it should be integrateable as well with a little script-part, if we translate it into addShips(role, count, "abs", where), because the current position in legacy_addShips(role, count, position) actually signifies a fraction of the distance between '"abs", [0, 0, 0]' and '"abs", system.mainStation.position'. So all a script would have to do is to split system.mainStation.position into its x, y, and z-component, and return these. Then addShips(role, count, "abs", [m * x-component, m * y-component, m * z-component]) would be equivalent to legacy_addShips(role, count, m), with m in the usual range between 0 and 1. (Bigger or smaller values would still be possible, of course, as they are with the current method, I think.)

The legacy_spawnShip() method has become obsolete anyway, because its only purpose was to control the orientation of the spawned object, which under JavaScript can be much better achieved through a ship-script (never worked correctly anyway).

So we would have only one method instead of the six currently listed.--Commander McLane 09:48, 12 December 2008 (UTC)