player ship docking and immediate re-launching

[Eric Walch]

The good news is that I now added a few additional checks so no statusScreen is shown when adding a launchPlayer() in one of the two docking handlers. Also the launching as result of the launchPlayer() has no longer any oddities. Launching the player on the shipWillDockWithStation handler only will show the launching tunnel, doing it on the shipDockedWithStation will also show a docking tunnel.

The bad thing is that I see no way to prevent also the shipDockedWithStation and the missionScreenOpportunity from firing when you already do a launchPlayer in going to dock. I have no clue how to prevent it.

In the enterDock code I now added a check that prevents further execution when it detects the status STATUS_LAUNCHING. I added a logline just before. However, before the code even reaches that logline, the shipDockedWithStation and the missionScreenOpportunity have already fired. Puzzling.....

Oolites C code

Code: Select all

- (void) enterDock:(StationEntity *)station
{
	if ([self status] == STATUS_DEAD)  return;
	
	[self setStatus:STATUS_DOCKING];
	dockedStation = station;
	[self doScriptEvent:OOJSID("shipWillDockWithStation") withArgument:station];
	
	OOLog(@"dumpState.playerEntity", @"Status on enterDock: %@", OOStringFromEntityStatus([self status]));
	if ([self status] == STATUS_LAUNCHING)  return; // a JS script has abrupt the docking.

My test oxp JS code

Code: Select all

this.shipWillDockWithStation = function (station)
{
    if (player.ship.docked && player.ship.dockedStation)  
        log(this.name, "Player will dock at: "+player.ship.dockedStation.displayName + ", with status: "+ player.ship.status);
    if (player.ship.dockedStation) player.ship.launch();
}

this.shipDockedWithStation = function (station)
{
   if (player.ship.docked && player.ship.dockedStation)  
        log(this.name, "Player has docked at: "+player.ship.dockedStation.displayName);
}

this.missionScreenOpportunity = function()
{
 log(this.name,"missionScreenOpportunity has fired")
}

The resulting log.

Code: Select all

[eric's test handlers] OOJSGlobal.m:247: Player launched from station: Coriolis Station
[eric's test handlers] OOJSGlobal.m:247: Player will dock at: Coriolis Station, with status: STATUS_DOCKING <----- A
[eric's test handlers] OOJSGlobal.m:247: Player has docked at: Coriolis Station
[eric's test handlers] OOJSGlobal.m:247: missionScreenOpportunity has fired
[eric's test handlers] OOJSGlobal.m:247: Player will launch from station: Coriolis Station < ---- B
[dumpState.playerEntity] PlayerEntity.m:4730: Status on enterDock: STATUS_LAUNCHING
[eric's test handlers] OOJSGlobal.m:247: Player launched from station: Coriolis Station

The loglines between A and B were a bit unexpected.
Anyhow, I look a bit further if is can break anything and when okay it will go in trunk and in 1.76.1

[Eric Walch]

I now figured out how I could prevent the shipDockedWithStation and the missionScreenOpportunity handler to fire when launching the player in the middle of a shipWillDockWithStation handler. Problem was the 'update' for every frame that always triggered during the 'leaveDock' function. When it noticed a STATUS_DOCKING and no docking rings, it triggered a complete docking with all the handlers. Only after that the remaining of the 'leaveDock' code was executed.

Should be fixed now with r4737 in trunk.

When launching the player by script already during the shipWillDockWithStation handler will mean that no cargo pods are unloaded and the following launch will try to load cargopods from the manifest. Seeing how the code for loading the cargo is written there should be no problem when there was still cargo on board. Also my tests indicate no problems with the cargo or other sideeffects when interrupting the normal docking.

When no other side effects are reported, I will also add the change (3 lines) to the 1.76.1 branch.