Talk:Oolite JavaScript Reference: System - Revision history

Commander McLane: /* addShips() */ integrating legacy_addSystemShips()

2008-12-12T09:48:26Z

‎addShips(): integrating legacy_addSystemShips()

Commander McLane: /* addShips() */ deleted optional precision parameter

2008-12-11T13:05:39Z

‎addShips(): deleted optional precision parameter

Commander McLane: addShips()

2008-12-11T12:53:33Z

addShips()

Ahruman: Talk:Oolite/Development/Scripting/Class/System moved to Talk:Oolite JavaScript Reference: System

2007-12-06T11:38:08Z

Talk:Oolite/Development/Scripting/Class/System moved to Talk:Oolite JavaScript Reference: System

Arexack: custom systems

2007-08-07T12:17:24Z

custom systems

New page

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)
--[[User:Arexack|Arexack]] 13:17, 7 August 2007 (BST)

@@ Line 25: / Line 25: @@
 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, 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], [witchspace cloud])
+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 (or possibly two, with addSystemShips()) instead of the six currently listed.--[[User:Commander McLane|Commander McLane]] 12:53, 11 December 2008 (UTC)
+So we would have only one method instead of the six currently listed.--[[User:Commander McLane|Commander McLane]] 09:48, 12 December 2008 (UTC)

@@ Line 15: / Line 15: @@
 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])
+ 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().
+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], 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 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, 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 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], [witchspace cloud])
 The first three parameters again as currently found in legacy_addSystemShips(), and the optional parameters as above.

← Older revision		Revision as of 12:53, 11 December 2008
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)

← Older revision	Revision as of 11:38, 6 December 2007
(No difference)