Oolite Bulletins

I have two other things that I currently miss in the legacy_add series.

1) Present the added ships in an array as now already happens with the spawn() method. i find myself in a lot of situations were I add some ships and than have to do a find to get them in an array. But with a find you need all kind of checks to prevent already existing ships become also included.

2) When I add several ships in one command I would like to give them all the same group ID. Currently only pirates groups added by the populator have the same group ID. That makes that attacking one group member can trigger the others.
Probably we need also a addGroup() and a jumpInGroup() command. Same as the ship commands but now all with the same group ID. This would make the groupAttack commands work for script added groups of ships.

Eric Walch wrote:

1) Present the added ships in an array as now already happens with the spawn() method.

Yes, definitely. The legacy_foo functions will never do that, but the replacement will.

2) When I add several ships in one command I would like to give them all the same group ID. Currently only pirates groups added by the populator have the same group ID. That makes that attacking one group member can trigger the others.
Probably we need also a addGroup() and a jumpInGroup() command. Same as the ship commands but now all with the same group ID. This would make the groupAttack commands work for script added groups of ships.

Makes sense.

One of my beyond-MNSR not-quite-plans is to rewrite the system populator in JavaScript, in a modular fashion. This basically means the new ship-adding functions need to be able to do everything.

Hi. I've read the posts about but don't understand them well. Would someone be kind enough to tell me how to convert the following into an 'addShips' command that generates witchspace rings, please? Thank you.

Although the rings are only generated if done in range of the witchpoint.

I came upon this accidentally the other day when coding the planet ring thingie. Initially I spawned them and then moved them, so when done on arrival from a witchspace jump the player ship ended up surrounded by very short-lived rings (the ring segments having already been moved to their positions by the script).

Looked quite pretty, albeit undesired.

Hi Thargoid

The method I mentioned does not seem to generate rings when used near the witchpoint. And, anyway, I wouldn't fancy having to spawn the ships near the wpoint and then instantly moving them to where I wanted them . .

EDIT: I think you have the addShips command in mind. I suppose I'll have to use addShips to put the ships near the witchpoint, and then shift them, and then add some hand-waving if anyone actually sees the transition.

Dear Thargoid

Thanks. (I managed to mistake the code you posted for a quotation of my code; or I just didn't see that code you presented at all; or. . something.)

When, in testing, one wants to create some specific ships which only have common roles like 'pirate' or 'trader', how does one go about it?

If I understand correctly, the only way to do this (without editing the [size=120]shipdata.plist[/size] to create a specific role for the ship) is to use [size=120]system.legacy_spawnShip("[i]shipDataKey[/i]")[/size] - yes?

It often results in messages in the Latest.log thus:

SandJ wrote:

If I understand correctly, the only way to do this (without editing the [size=120]shipdata.plist[/size] to create a specific role for the ship) is to use [size=120]system.legacy_spawnShip("[i]shipDataKey[/i]")[/size] - yes?

No, legacy_spawnShip is to be only used for special ships that also contain an entry for position and orientation in the shipdata itself. For new stuff, just forget the method.

shipDataKey is not usable for adding ships. Unless you use latest trunk were it became possible. Not tested myself, but I am convinced it should work there by using the shipDataKey within brackets were normally a role is expected. e.g. system.addShip("[shipDataKey]", 1)

What Eric said, which means that there's no other way than to edit shipdata.plist.

I am of the opinion that each ship should have a unique role anyway. However, for testing it's not always advisable to spawn it with its unique role. A ship spawned with "myRole" has some other behaviour than a ship spawned with "trader" or "pirate". Therefore you can't test everything with it.

Thus I'd suggest that, if you want to test it in one of the default roles, you should increase its weight in that role. If you want to see it as a trader, give it role "trader(10000)". That should make fairly sure that the next "trader" you're spawning will be your ship.

Commander McLane wrote:

What Eric said, which means that there's no other way than to edit shipdata.plist.

Thus I'd suggest that, if you want to test it in one of the default roles, you should increase its weight in that role. If you want to see it as a trader, give it role "trader(10000)". That should make fairly sure that the next "trader" you're spawning will be your ship.

That's a bit of an error-prone faff. Would it be a useful feature for developers to be able to have a command available in the Debug Console so say "create [n] ships of type [blah]"?

Eric Walch wrote:

shipDataKey is not usable for adding ships. Unless you use latest trunk were it became possible. Not tested myself, but I am convinced it should work there by using the shipDataKey within brackets were normally a role is expected. e.g. system.addShip("[shipDataKey]", 1)

I can confirm that this functionality is available and fully operational in current nightly builds. If you examine ship.roles for any ship in trunk one of the valid roles will be its dataKey in square brackets. So every ship gets a guaranteed unique role whether the original author specified one or not.

SandJ wrote:

That's a bit of an error-prone faff. Would it be a useful feature for developers to be able to have a command available in the Debug Console so say "create [n] ships of type [blah]"?

You can make your own macros in the console, if you need that. But most people just need a single example of the ship, for which :spawn does nicely (or :test if you just want to view the model in a mission screen). A multiple ship macro would just be a variation on the spawn one, with it set to multiple entities.

Thargoid wrote:

Most people just need a single example of the ship, for which :spawn does nicely. A multiple ship macro would just be a variation on the spawn one, with it set to multiple entities.

But that gives any ship from the role, and if it is a rare trader or a pirate that is required, spawning dozens of ships hoping to get the one you want is tedious (as I have found today).