Okay, next step: spawning script.
First of all: Don't Panic! Writing scripts is no rocket science. For standard tasks (like spawning ships) it's actually quite straightforward. You simply tell the game engine what it has to do and when. You just have to use the right language to do so.
You need a world script (that's a script attached to the game universe as a whole, as opposed to a script attached to a specific ship and only existing while that ship is also existing; you can also think of a world script as being attached to the player, because the game universe only exists inasmuch as the player is there). The simplest way of creating one is to create a simple text file and save it in the Config-folder of your OXP (right next to your shipdata.plist) under the name of "script.js".
Here's what it has to contain:
Code: Select all
"use strict";
this.name = "dox-scavenger";
this.description = "Script for randomly spawning dox scavengers whenever the player enters a new system";
this.author = "Commander McLane";
this.copyright = "© 2013 Commander McLane";
this.license = "CC-by-nc-sa 3.0";
this.version = "1.0";
this.shipExitedWitchspace = function()
{
if(!system.isInterstellarSpace && ... && Math.random() < 0.1)
{
system.addShipsToRoute("dox_scavenger", 1, 0.3, "wp");
}
}
Let's go through it line by line:
The first line tells the JavaScript-engine that we're conforming to some standard. I don't know any details, I just know that each script should have it right at the beginning.
Then comes a group of six lines that contain meta-information about the script. For the most part they're exactly that: convenient meta-information, but not strictly necessary. However, there's one exception: the
is mandatory. Also, the name has to be unique (just like shipdata keys of your ship), because this is how the JavaScript-engine actually distinguishes all the various scripts. It doesn't use file names for that. Therefore each OXP can contain a "script.js" in its Config-folder without confusing the scripting engine, as long as they all have a unique
this.name.
The last seven lines are the actual script code.
is an event handler. It tells the scripting engine
when to perform the commands enclosed in the following curly brackets. In this case, we want the action each time when the player exited from witchspace and has entered a new system. There is a
list of all existing event handlers on the Wiki that explains when each of them "fires". For the purpose of populating a system with additional ships (or creatures) the moment when the player enters the system is of course the logical choice.
But I assume that you don't want to spawn one of your scavengers literally every time when the player pops out of witchspace. Thus the spawning code should only be executed under some conditions. Those are defined in the
if clause:
Code: Select all
if(!system.isInterstellarSpace && ... && Math.random() < 0.1)
First of all,
!system.isInterstellarSpace checks that the player is in a planetary system (the "!" means "not"). It prevents the scavengers from being spawned in case of a misjump. After all, in interstellar space there is no space lane between witchpoint and planet, and there are no asteroids.
Last of all,
Math.random() < 0.1 adds an element of random.
Math.random() creates a random number between 0 and 1. So only ten percent of the time it will be < 0.1, and the condition will be fulfilled. I just filled in this probability arbitrarily, and you can of course decrease or increase the probability by decreasing or increasing the number.
Between those two, the
... stand for any other conditions you can come up with. For instance, you can make the tech level of the system into a condition, or the political affiliation, or the economy, or any other property of the system. So the player would only ever encounter the scavengers in systems that are at least poor industrial, excluding anarchies and feudals, with a tech level not higher than 10. Or whatever combination of conditions allows the scavengers to flourish best. A
list of all system-related properties that can be used as conditions is of course also on the Wiki.
Finally, if all conditions are met, the part in the innermost curly brackets is executed:
Code: Select all
system.addShipsToRoute("dox_scavenger", 1, 0.3, "wp");
It tells the engine to add a specified amount of ships with a specified role to a specified location along one of the space lanes.
In this case, the role is "dox_scavenger", the amount is 1 of them, the location is at 30 per cent of the way in, and the route is from
witchpoint to
planet.
Of course, you can modify each of the parameters to your liking:
- Specify another role to spawn a ship/ships of that role.
- Specify another number to spawn more than one ship (the limit is 64, so you can spawn a pretty big cluster of ships with a single command).
- Specify another fraction to move the spawning point forward or back. 0 means (on the main route) exactly the witchpoint position, and 1 means on the surface of the planet. You can also use a negative number to spawn something behind the witchpoint, or a number > 1 to spawn something behind the planet (caution: because 1 means the surface of the planet, chances are that 1.05 will spawn your ship inside the planet). You can even use random here: replacing the 0.3 with
Math.random() will cause your scavenger to spawn at a random location between the witchpoint and the planet; (Math.random() * 0.8 ) + 0.1 will make sure that it's not too close to either the witchpoint or the planet. - Specify another one of the space lanes. Apart from "wp" (witchpoint to planet) there's also "pw" (planet to witchpoint), "ws" (witchpoint to sun), "sw" (sun to witchpoint), "ps" (planet to sun), and "sp" (sun to planet). If you skip the parameter altogether, the direct line between witchpoint and main station is used.
And that's it. There you are with a highly modifiable and customizable spawning script.
EDIT: added quotation marks at a vital point in the code example.
![[EliteWiki]](/images/elitewikismall.png){kind=small}
Salvager Tugger
Thank you for this Commander McLane. 