Oolite Bulletins

Posted: **Tue Feb 23, 2010 3:42 pm**

Errmmm, Cheyd, ... nope.

The question was about spawn, not one of the addShips methods.

Posted: **Tue Feb 23, 2010 3:53 pm**

Guess I"m not understanding, as it doesn't seem that different to me. Then again, I've been studying for a certification for work for a few weeks, am in cram week now, and my brain has turned into tapioca...

Posted: **Tue Feb 23, 2010 9:26 pm**

spawn() has a bunch of special semantics. In particular:

The generated ships have a random position inside the parent ship’s collision radius, and initially face outwards.
The generated ships inherit 85 % of the parent’s temperature.
If the parent is a missile and the spawned ship has the is_submunition property set, the spawned ship inherits the parent’s owner and target and is flagged as a missile. (Special case for smarter cluster missiles)
Unlike addShip family methods, spawn() does not set up escorts, and does not handle auto-selection of trade routes and witchspace jump effects when it happens near a wormhole.

In short, spawn() is the right thing if bits are falling off or out of a ship, and wrong for everything else.

Posted: **Wed Feb 24, 2010 10:02 am**

Hmm, after reading all this, I think Cmdr Cheyd's

Code: Select all

system.legacy_addShipsWithinRadius('pirate', Num_Pirates, 'abs', player.ship.position, 25600);

... might be fitting for my purpose, too.

I want a sort-of beacon that spawns when a player ship does a certain action. It should spawn somewhere near the player ship and be able to have a station role (yes it's a workaround for something)

So addShipsWithinRadius should work, too.

Will try that first. Thanks all.

Posted: **Wed Feb 24, 2010 8:45 pm**

You may also want to look at ship.ejectItem along similar lines perhaps (depending on what you want to do).

Posted: **Thu Feb 25, 2010 6:20 pm**

=== Power tip for mac users. ===

Working on RH I added some log() instructions to batter catch what was happening. While entering a certain mark system and doing something else I suddenly got the message that my mark was killed by someone else.

Looking in the log I found:

Code: Select all

Mark was killed by: [Station "Coriolis Station" "Coriolis Station" ID: 252 position: (105472, 60671.7, 658999) scanClass: CLASS_STATION status: STATUS_ACTIVE] Because of: scrape damage. Last recorded hit: NPC_ATTACK

Apparently my mark just flew into the main station. Other logs told me he never started a fight so I thought at the inspect() method. I never realised you can use it somewhere else than in the console but when I gave my mark the following script:

Code: Select all

this.shipSpawned = function ()
{
    this.ship.inspect();
}

the inspect window opened magically on entering a system with a mark. Without even seeing the ship I could see by the window it was heading to the station, When entering the station aegis it entered the state to go to the witchpoint. But the coordinates showed it was still heading for the station and again it killed itself by crashing into the station.

inspect() is very nice debugging command to remember for mac users.

Posted: **Thu Feb 25, 2010 8:07 pm**

Eric Walch wrote:
When entering the station aegis it entered the state to go to the witchpoint. But the coordinates showed it was still heading for the station and again it killed itself by crashing into the station.

Seems like an AI-bug, then...

Posted: **Thu Feb 25, 2010 8:38 pm**

Commander McLane wrote:
Seems like an AI-bug, then...

Yep, the old line for going to the witchpoint was:

Code: Select all

(setDestinationToWitchpoint, "setDesiredRangeTo: 1000.0", setDestinationToTarget, checkCourseToDestination)

When flying towards the station the ships target is the main station. Than, when turning around, the AI correctly stets the witchpoint position as destination. The second command sets a range, but the third command sets the target position as destination. And the target is still the station. No wonder I witnessed both flying into the station. When the ship starts heading for the witchpoint there is no target yet, so I think the third command than does nothing so the witchpoint as destination stays in.

Posted: **Thu Mar 18, 2010 10:21 pm**

A ship script question.

I assume it is the case, that when I have an "is template" ship, and the template ship gets a ship script attached (lets call it A.js), and if a ship later derived from that template via "like ship" has another ship script attached (say, B.js), then any ship derived from the template will normally have A.js, but the "like ship'ped" ship with the new one defined will have B.js because B.js will then override the template's A.js, yes?

I, as said, assume this is the case, just want to be really sure.

Edit: Second question, also, are death actions and ship scripts possible, simultanously? I seem to recall there was a problem with that in the past.

Posted: **Fri Mar 19, 2010 7:17 am**

Yes, B.js will override A.js in the example.

And if the script also has death actions (or launch/spawn actions) then iirc those will also override any set in shipdata.

Posted: **Fri Mar 19, 2010 7:26 am**

Thargoid wrote:
Yes, B.js will override A.js in the example.

And if the script also has death actions (or launch/spawn actions) then iirc those will also override any set in shipdata.

OK, thanks!

Sorry if that detail is still not absolutely clear to me, but I can have both a death action and a ship script in the same entry and both will work, these two will not override each other?

Posted: **Fri Mar 19, 2010 11:21 am**

For the sake of simplicity I would suggest you move the death_actions from the shipdata into the ship script. That's what the shipDied event-handler in the ship script is for.

Concerning the overriding: If there is a shipDied event-handler in the ship script, it will override the death_actions in the shipdata. If no shipDied exists, it can't override anything, can it? Therefore the death_actions will be executed.

Posted: **Fri Mar 19, 2010 12:07 pm**

Commander McLane wrote:
Concerning the overriding: If there is a shipDied event-handler in the ship script, it will override the death_actions in the shipdata. If no shipDied exists, it can't override anything, can it?

I assumed as much. But I believe to remember some discussion way back that ship scripts and death actions would generally collide somehow. Perhaps I misremember, perhaps this was the case in an earlier Oolite version?

Whatever the case may be, thanks for the input, it is helpful.

Posted: **Fri Mar 19, 2010 7:26 pm**

Lestradae wrote:
Sorry if that detail is still not absolutely clear to me, but I can have both a death action and a ship script in the same entry and both will work

No. If there’s a ship script, it overrides any _actions.

Commander McLane wrote:
Concerning the overriding: If there is a shipDied event-handler in the ship script, it will override the death_actions in the shipdata. If no shipDied exists, it can't override anything, can it? Therefore the death_actions will be executed.

Wrong. The death_actions (and setup_actions, launch_actions, and script_actions) are run by the default ship script, oolite-default-ship-script.js. If you have a custom ship script, it replaces the default ship script completely.

Posted: **Fri Mar 19, 2010 10:48 pm**

Ah! As you mention it now: Yes, of course!

Oolite Bulletins

Scripters cove

..

..

..