player ship docking and immediate re-launching

[Commander McLane]

I need to immediately launch the player ship from a certain station after he has docked, without giving him any choice. This is because he isn't supposed to be able to dock with the station in the first place, but there is no scripting way to prevent that from happening. (The station in question is a Thargoid Carrier; it must be able to launch Thargoids, therefore it has to be dockable; but no non-Thargoid—including the player—must be able to dock with it. The workaround is an immediate re-launch in case the player somehow manages to sneak in.)

If I recall correctly from previous versions of Oolite there used to be a difference between

Code: Select all

this.shipWillDockWithStation = function(station)
{
	if (station.name === "Thargoid Carrier")
	{
		player.ship.launch();
	}
}

and

Code: Select all

this.shipDockedWithStation = function(station)
{
	if (station.name === "Thargoid Carrier")
	{
		player.ship.launch();
	}
}

Namely, in one of the cases I would still see the status screen after being launched, while in the other case I would correctly see the main screen. I think that was the second case.

Now, in Oolite 1.76 I see the status screen in both cases. This is a little inconvenient, because I am floating in the middle of a Thargoid fleet and have no idea what is going on around me. Do we have a method to set the gui screen to GUI_SCREEN_MAIN by script?

[cim]

I need to immediately launch the player ship from a certain station after he has docked, without giving him any choice. This is because he isn't supposed to be able to dock with the station in the first place, but there is no scripting way to prevent that from happening.

If the carrier doesn't need to dock Thargoids again once it's launched them, a potential hack is to make the docking bay visible on the outside a fake, and then have a long fake docking tube running the inside of the carrier (the coding is easier if this tube and the fake docking bay are both aligned to the carrier's z-axis, but this isn't entirely necessary if you're willing to mess with quaternions a little)

Then you can use this.stationLaunchedShip() in the carrier script to immediately reposition any launching ships so that they look like they've just launched from the fake docking bay.

If the carrier does need to dock Thargoids, while the player might be watching, it gets harder, but it's doable if you write your own dockingAI for the Thargoids - navigate them to a stop within the fake docking bay, and then reposition them to the real one. I suggest you have two fake docking bays in this case - one for launch, and one for landing - or you may notice a few traffic control problems.

(The much easier option is instead of player.ship.launch() to call player.ship.explode() on the principle of "serves you right for trying something so phenomenally stupid", of course; if you could prevent docking then running into something carrier-sized would generally do that anyway)

[Eric Walch]

Now, in Oolite 1.76 I see the status screen in both cases. This is a little inconvenient, because I am floating in the middle of a Thargoid fleet and have no idea what is going on around me. Do we have a method to set the gui screen to GUI_SCREEN_MAIN by script?

As one alternative option, you could explore is launching the player on a missionscreenOpportunity. This fires immediately after docking. It could only go wrong if an other oxp for some reason would add a missionscreen of its own there.

Any reportScreeen you can suppress by setting this.ship.suppressArrivalReports = false in the station script.
(I think this was an omission that its only a JS station property and not also a shipKey)

[Commander McLane]

(The much easier option is instead of player.ship.launch() to call player.ship.explode() on the principle of "serves you right for trying something so phenomenally stupid", of course; if you could prevent docking then running into something carrier-sized would generally do that anyway)

That's an interesting proposal, but I don't want to be that harsh.

As one alternative option, you could explore is launching the player on a missionscreenOpportunity. This fires immediately after docking. It could only go wrong if an other oxp for some reason would add a missionscreen of its own there.

Same result, unfortunately. After I'm launched I still see the status screen.

I'm beginning to wonder whether I just fantasized that it was ever as I described above...

[cim]

As one alternative option, you could explore is launching the player on a missionscreenOpportunity. This fires immediately after docking. It could only go wrong if an other oxp for some reason would add a missionscreen of its own there.

Same result, unfortunately. After I'm launched I still see the status screen.

What about having an actual mission screen displayed at the missionscreenOpportunity saying something simple like "The Thargoids do not seem happy with your attempt to dock. You quickly flip your ship over and accelerate out", and then having player.ship.launch() in the "choice" function for runScreen.

That definitely works for me (I should change my own "undockable" station to work that way, thinking about it, since I do have the same status screen problem at the moment)

[Eric Walch]

As one alternative option, you could explore is launching the player on a missionscreenOpportunity. This fires immediately after docking. It could only go wrong if an other oxp for some reason would add a missionscreen of its own there.

Same result, unfortunately. After I'm launched I still see the status screen.

That is a bit puzzling as the source defines:

Code: Select all

	[self doScriptEvent:OOJSID("shipDockedWithStation") withArgument:dockedStation];

	// if we've not switched to the mission screen yet then proceed normally..
	if (gui_screen != GUI_SCREEN_MISSION)
	{
		[self setGuiToStatusScreen];
	}
	
	// When a mission screen is started, any on-screen message is removed immediately.
	[self doWorldEventUntilMissionScreen:OOJSID("missionScreenOpportunity")];	// also displays docking reports first.

That clearly shows that when you launched during the shipDockedWithStation handler, the code will do a setGuiToStatusScreen after that. But the missionScreenOpportunities start AFTER the StatusScreen is set.

[UK_Eliter]

I too am interested in a (hopefully fairly simple!) way of re-launching a player ship once it has launched.

I'd be interested, too, in help with repositioning a ship when it has launched, or correcting docking bay setup, such that (either way) a ship actually begins its journey out of a ship from near the start of the ship. (I am trying to do something at the moment which involves launching ships from a ship designed by someone else - and sometimes those ships take ages to appear, and sometimes they get stuck, in a sticky kind of fashion, halfway within a solid part of the ship. .).

[Thargoid]

Repositioning and re-orienting is not too difficult - look in the script of Planetfall for an example. There the player ship is turned around and boosted away from the temporary station by a way to get them out of the planetary atmosphere danger zone.

It's just playing about with player.ship.position and player.ship.orientation relative to the objects around it. Both are read/write.

[Micha]

Looking at the code, if you launch the ship in the 'shipWillDock' event handler, it -should- work.

In fact, if you do it by the time the 'shipDocked' event handler fires, a lot of the docking logic has already been performed, such as repacking the manifest.

[Commander McLane]

Looking at the code, if you launch the ship in the 'shipWillDock' event handler, it -should- work.

What does "it" refer to? If you mean immediate relaunch into the main screen it doesn't. As per my first post there is no discernible difference between 'WillDock' and 'DockedWith'. In both cases the status screen remains displayed while and after launching, which means that when playing with sound off the player gets no hint that they have already been launched again. This is my main concern as I used to play with sound off very regularly.

[Eric Walch]

Looking at the code, if you launch the ship in the 'shipWillDock' event handler, it -should- work.

What does "it" refer to? If you mean immediate relaunch into the main screen it doesn't. As per my first post there is no discernible difference between 'WillDock' and 'DockedWith'. In both cases the status screen remains displayed while and after launching, which means that when playing with sound off the player gets no hint that they have already been launched again. This is my main concern as I used to play with sound off very regularly.

I don't know why you got a different result, but when I add the 'launchPlayer()' in the 'shipWillDock' handler, I don't see the status screen but the main screen after being launched. Still, there is something funny going on as my log shows:

Code: Select all

Player will dock at: Coriolis Station
Player has docked at: Coriolis Station
Player will launch from station: Coriolis Station
Player launched from station: Coriolis Station

The second line shouldn't be there. It seems that there is no check for still being docked and the second handler does fire. Therefor it is always good for an oxp to check if you are indeed still docked at that moment.

On my second and third try I got the expected results:

Code: Select all

Player will dock at: Coriolis Station
Player will launch from station: Coriolis Station
Player launched from station: Coriolis Station

On further tests I see that the line

Code: Select all

Player has docked at: Coriolis Station

is always present on the my first try of docking after loading a game and no longer on the next tries. However, there should be no difference and in all occasions I am not heading to the buoy but clearly launched in a consistant wrong direction.

Placing the launchPlayer() command in the 'shipDockedWithStation' handler does leave me on the statusScreen while actually in flight.

[Eric Walch]

Looking at the internal code, it is also not a trivial fix of just adding a check after the 'shipWillDockWithStation' and cancel the code when the player is in flight again. Stuff like the escape pod also relies on this code. You now already may get funny stuff when using your escape-pod near such a station.

---

Just tested it with an escape pod. It works in the way that I get in the escapepod, (energy levels are adjusted to that of the pod) and than suddenly I am in my boa again . This ship has much larger energy banks, so the are recharging now from the level of the pod. That feels wrong, getting the old ship without having actually docked. And in the case of a thargoid carrier were the code was mend for its even weirder that you got a new ship there...

[Commander McLane]

Preventing the player from docking altogether would clearly be a better approach.

[Kaks]

In the meantime it looks like we can improve on the situation by fixing Oolite's code so that launching from the shipwilldock event won't cause weird behaviours, at least for 1.76.1!

[UK_Eliter]

In the meantime it looks like we can improve on the situation by fixing Oolite's code so that launching from the shipwilldock event won't cause weird behaviours, at least for 1.76.1!

I'll second that, if I may!