The missionScreenOpportunity handler is called if there are no mission / report screens active, and the player is docked to a station. It gets fired at game startup, upon docking, and after a docking report or previous mission screen has ended.
I'm trying to decide whether OxpConfig needs to use the missionScreenOpportunity handler.
OxpConfig does use missionRunScreen , but only calls it if the following are true :
- Player accesses F2 Game Options while docked
- when F7 is pressed while GUI_SCREEN_GAMEOPTIONS is true, OxpConfig fires it's owns screens.
These checks could be done in a missionScreenOpportunity handler, but is it needed to avoid clashes ?
These checks could be done in a missionScreenOpportunity handler, but is it needed to avoid clashes ?
No. You don't need it if your script shows the next screen in your choice handling.
If you really want to keep the F2->F7 activation you could use the following pseudocode for guiScreenChanged.
But then you should also handle the Timer on shipDied and shipWillLaunchFromStation (even though Oolite should stop Timers in worldScripts).
if(!player.ship || !player.ship.isValid || !player.ship.docked) return;
switch(guiScreen){
case "GUI_SCREEN_OPTIONS":
set activation
if !Timer
new Timer calling this.guiScreenChanged
break;
case "GUI_SCREEN_SYSTEM_DATA":
if activation
start handling
- no break here!!!
default:
delete activation
if Timer
stop Timer
delete Timer
}
How late in the witchspace countdown can you set a scripted mis-jump. When playerShipEnteringWitchspaceRealSoonNow shipWillEnterWitchspace fires, and you know it's too late for the player to cancel the countdown, is it too late to do some calculatin' and set the mis-jump? Or does one have to do the calculations when the countdown starts and reverse them if the jump fails or is cancelled?
Edit:Y'see, Norby knew what I meant.
Last edited by Wildeblood on Wed Jan 07, 2015 10:45 am, edited 1 time in total.
this.shipWillEnterWitchspace = function (cause) {
if (cause !== "standard jump") {return}
var range = System.infoForSystem(galaxyNumber, system.ID).distanceToSystem(System.infoForSystem(galaxyNumber, player.ship.targetSystem))
if (range > 5.0) {player.ship.scriptedMisjump = true}
}
Now the trickier bit... a related function when you arrive in the new system to check how far you just jumped, that must discount jumps arriving from interstellar space. One that can display a message like "Congratulations, you just jumped 4.9 ly without a mis-jump." How would you do that?
this.shipWillExitWitchspace = function()
{
if (system.isInterstellarSpace) {this.wasANormalJump = false}
if (this.wasANormalJump) {player.consoleMessage("Congratulations, you just jumped without a mis-jump.", 5)}
}
Okay, so I've arrived in a new system and confirmed neither the arrival nor departure systems were interstellar space. But how to record how far I've just jumped?
Save range into a this.$range variable if not in interstellar space. You should use $ or _ prefix in global script variables to prevent collision with existing or future core properties.
If you need to stay over save and load game then use missionVariables but this is more complex and slow so you should store these in global script variables during run and save in playerWillSaveGame only.
How can I get my script to see all ships currently defined by the game? That's ship type, like "[ferdelance]", not spawned instance, so I can have a menu of things from which to select for creative spawning.
What's the cleanest way of maintaining "global" state? Specifically, I want to record a running score for a couple of ship groups, and I'd like any ship to be able to signal back to the world script when something's happened that should cause the score to update. I can define callbacks in the world script, but not global state (it seems), because "this._score" resolves to the caller's "_score" variable, not the world script's. I don't need to save "_score" between games, so where should it go? In the Player entity?
How can I get my script to see all ships currently defined by the game? That's ship type, like "[ferdelance]", not spawned instance, so I can have a menu of things from which to select for creative spawning.
The static methods of the ship class. In this case, Ship.keys() - note the capital S on 'Ship' - will do what you've asked for, though Ship.keysForRole() might be more useful.
A useful trick to avoid having to mess around with 'this':
{{EDIT: deleted this since it's not quite right - see a few posts down for the correct one.}}
Last edited by cim on Mon Feb 09, 2015 7:38 pm, edited 1 time in total.
Does adding ships with addGroup rather than addShips affect their AI behaviour?
Yes - grouped ships will receive messages from ship.requestHelpFromGroup() and ship.notifyGroupOfWormhole(), and be counted as allied for determining combat odds and ignoring friendly fire. There are other effects in a lot of AIs where ships will coordinate actions through their group leader.
Though you can add them with addShips and group them up separately for the same effect - it's being in the same group, not how they got into it, which makes the difference.
this.name = "My world script";
(function() { // this line starts an anonymous function scope to get things out of global space
var self = this;
this.startUp = function() {
this._score = 0;
}
this._myCallbackFunction = function() {
// ...
self._score += 1;
}
}.call(this)); // and this line closes that scope and executes the function to define the variables
Does adding ships with addGroup rather than addShips affect their AI behaviour?
Yes - grouped ships will receive messages from ship.requestHelpFromGroup() and ship.notifyGroupOfWormhole(), and be counted as allied for determining combat odds and ignoring friendly fire. There are other effects in a lot of AIs where ships will coordinate actions through their group leader.
Though you can add them with addShips and group them up separately for the same effect - it's being in the same group, not how they got into it, which makes the difference.
Nice. This is useful with some of the vintage oxps that add pirates with addShips. With the old pirate ship pool and AIs those could be quite deadly and very agressive, but with the new basic pirate pool and AI they seem to be weak loners that very easily wimp out. When adding them as a group, it at least looks like they are more eager to attack. An easy way to keep some some old stuff alive it seams.
I could of course use some of the old AIs that are still there, but I'd rather use the new ones. They are much more elegant.