Scripters cove

[JensAyton]

Code: Select all

if(missionVariables.CockpitBought == null)

or perhaps even ===

However, four shalt thou not count.

[Cmd. Cheyd]

Five is right out.

[Cody]

Nix the six!

[Lestradae]

Why am I suddenly thinking of the holy handgrenade?

[Mauiby de Fug]

Question: Which events are called when the player enters a system through another ship's wormhole?

I've tried the shipWillExitWitchspace and the shipExitedWitchspace and they don't appear to be called, or, at least nothing is being written to my logs...

I can get a response from shipExitedWormhole, but that appears to be from the ship whose wormhole it was, not the player...

[Eric Walch]

I've tried the shipWillExitWitchspace and the shipExitedWitchspace and they don't appear to be called, or, at least nothing is being written to my logs....

They should be called and I do get them in my log. The only time those events were missed when you were docked at a carrier and that carrier entered the system from witchspace. But that is fixed for 1.75

[Mauiby de Fug]

Huh... Okay then, back to the drawing board. I'm possibly calling them from the wrong thing or something...

[Kaks]

They're world events, so they need to be defined in Config/script.js ( or in a js file inside the Scripts directory, with a properly configured Config/worldScripts.plist ).

[Mauiby de Fug]

Yeah, I was calling them from a script assigned to a ship, and realized that that was why they weren't working! Although they are still listed under ship script event handlers, which was why I was getting confused...

There were a few other things I noticed on the reference pages which didn't seem to fit, but I can't remember what they were off the top of my head... Still, very useful pages! It did take me a while to find that player.ship.position was the way to access your position, which I got from someone's oxp; I would have thought it would be PlayerShip.position. I'm still getting my head around the various classes!

[Kaks]

Yes, it's 'a bit' tricky! Ship events relating to the player's ship are automatically world events.

Hmm, it might well be less confusing for new OXP makers if we had shipWillExitWitchspace only for NPC ship events & NPC ship scripts, & if we named the equivalent world script events playerWillExitWitchspace, etc...

It would mean yet more disruption for the existing scripts, though...

[Eric Walch]

Yes, it's 'a bit' tricky! Ship events relating to the player's ship are automatically world events.

To add to the confusion: not all events for player ships go to the world event. e.g. for combat testing purposes in trunk I wanted a ship that did survive the tests for some time. When adding

Code: Select all

this.shipBeingAttacked = function(whom)
{ 
    player.ship.forwardShield = player.ship.maxForwardShield;
    player.ship.aftShield = player.ship.maxAftShield;
}

to the worldscript nothing happened, but when adding it to the ship script of the specific ship the player was flying, it triggered

Hmm, it might well be less confusing for new OXP makers if we had shipWillExitWitchspace only for NPC ship events & NPC ship scripts, & if we named the equivalent world script events playerWillExitWitchspace, etc...

I think it would create confusion. because currently anything starting with player has no npc equivalent and anything starting with ship also goes to the player. The player does fly in a ship
There were some exceptions on this general rule though.

EDIT: and I just removed two handlers from the ship-handlers page that only fired for the player. (Both also started with player)

[Commander McLane]

EDIT: and I just removed two handlers from the ship-handlers page that only fired for the player. (Both also started with player)

Hm, I'm actually not so sure about that.

If the handlers fire in a ship script, they should be documented. Off the top of my head I don't know, though, whether alertConditionChanged and playerEnteredNewGalaxy are sent to NPCs as well (they probably aren't, although I very much wanted alertConditionChanged to work for Personalities.oxp).

[Kaks]

AlertConditionChanged applies to stations/carriers & players, if I remember correctly. We could add alert conditions to all ship entities, I suppose, even though we could end up with asteroids & splinters with alert levels too, which sounds a bit spooky...

[Mauiby de Fug]

Question about event handling:

Say I've docked at a station, otherShipDocked() has been called, and is being processed. During this event, the ship is launched with player.ship.launch().

But what if there is an eventHandler for the ship launching in the stationLaunchedShip()? Will Oolite process the rest of the code for otherShipDocked first, and then do the stuff for stationLaunchedShip, or move to the stuff for stationLaunchedShip and continue the stuff for otherShipDocked afterwards? Also, is this behaviour consistent, or could it run differently each time? And what happens if multiple events are linked together this way?

[Eric Walch]

It is certainly possible that a player gets a shipWillDockWithStation() event and during that event is decides that it does not want to dock at such a station an issues a player.ship.launch() command.
At that moment, the player will be launched, generating launching events. When those are ready, the code continues the original code of docking and probably will send the otherShipDocked(ship) event to the station. When you want to be absolutely sure that the player has not launched in between, it still makes sense to check for "ship.docked == true" in a handler that states that a ship is docking.