Difference between revisions of "Talk:Oolite JavaScript Reference: System"

From Elite Wiki
(addShips())
Line 10: Line 10:
 
(But the flag should be set to true in the systemScript in the first place)
 
(But the flag should be set to true in the systemScript in the first place)
 
--[[User:Arexack|Arexack]] 13:17, 7 August 2007 (BST)
 
--[[User:Arexack|Arexack]] 13:17, 7 August 2007 (BST)
 +
 +
== addShips() ==
 +
 +
As per [http://aegidian.org/bb/viewtopic.php?p=63437#63437 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], [precision], [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().
 +
 +
The optional parameter '''precision''' adds the ship(s) more or less close to the given position, thereby including legacy_addShipsAtPrecisely(). It could have a range from 0..1; 0 being very precise, 1 being most sloppy.
 +
 +
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], 0, 1) or addShips(role, count, "abs", [0, 0, 0], 0, 1) respectively (whatever currently defines the center of the spawning area) and thus be included as well.
 +
 +
The only method which is currently different from all the others, and cannot easily be included in a superseding method, is legacy_addSystemShips(), because it adds ships on the line between witchpoint and ''main station'' (as opposed to the line between witchpoint and planet). If we want to retain its functionality we can make it a seperate method: addSystemShips(role, count, position, [radius], [precision], [witchspace cloud])
 +
 +
The first three parameters again as currently found in legacy_addSystemShips(), and the optional parameters as above.
 +
 +
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 (or possibly two, with addSystemShips()) instead of the six currently listed.--[[User:Commander McLane|Commander McLane]] 12:53, 11 December 2008 (UTC)

Revision as of 13:53, 11 December 2008

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], [precision], [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().

The optional parameter precision adds the ship(s) more or less close to the given position, thereby including legacy_addShipsAtPrecisely(). It could have a range from 0..1; 0 being very precise, 1 being most sloppy.

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], 0, 1) or addShips(role, count, "abs", [0, 0, 0], 0, 1) respectively (whatever currently defines the center of the spawning area) and thus be included as well.

The only method which is currently different from all the others, and cannot easily be included in a superseding method, is legacy_addSystemShips(), because it adds ships on the line between witchpoint and main station (as opposed to the line between witchpoint and planet). If we want to retain its functionality we can make it a seperate method: addSystemShips(role, count, position, [radius], [precision], [witchspace cloud])

The first three parameters again as currently found in legacy_addSystemShips(), and the optional parameters as above.

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 (or possibly two, with addSystemShips()) instead of the six currently listed.--Commander McLane 12:53, 11 December 2008 (UTC)