In-mission docking breaks the warpIn() scripting function

[naomimyselfandi]

Bit of a niche case here... If a ship is not initially docked, or is initially docked but isn't the dock leader, and becomes docked during gameplay, calling the warpIn() scripting function on that ship will do nothing until it becomes undocked. This is due to a combination of two factors: warpIn() calls shipfx_warpin_start(object*), which short-circuits if it's called on a ship that's docked but not a Dock_leader; and the Dock_leader flag is only set at parse time, not as a result of docking during gameplay. Even if Dock_leader were updated dynamically, warpIn() would still mysteriously do nothing in some cases, so I feel like the right solution is to have shipfx_warpin_start skip that check when called by warpIn().

Additionally, shipfx_warpin_start fails with an Int3() when called on a ship that's already arriving; it should just do nothing in this case.

[naomimyselfandi]

BtA has a workaround (starting the ship docked to a cloaked container that is immediately jettisoned and vanished), so this isn't a high priority for us.

[Goober5000]

The selection of dock leader is more of a heuristic than a rule; it's barely possible during parsing (since the leader is de facto the ship that does the arriving) and would not be reliable for in-mission docking.

I feel like the right solution is to have shipfx_warpin_start skip that check when called by warpIn().

I think you're almost 100% correct here. The one issue is that the handling of the warp effect is slightly different for dock leaders and dock followers. But the script function offers its own solution. The ship on which you call warpIn() is the one you want to do the arriving, right? If so, then the solution is to set the dock leader flag inside the implementation of warpIn() before calling shipfx_warpin_start(). (Unless this is what you mean by "Even if Dock_leader were updated dynamically" in which case I'm curious to know more.)

[naomimyselfandi]

The selection of dock leader is more of a heuristic than a rule; it's barely possible during parsing (since the leader is de facto the ship that does the arriving) and would not be reliable for in-mission docking.

Yup, we're saying the same thing here: trying to manage the Dock_leader flag during normal docking operations (which is what I meant by "dynamically") is way more trouble than its worth, especially for such a niche use case.

"The ship that you call warpIn() becomes the dock leader" sounds good to me.

[Goober5000]

Ok, cool. Should be quick and easy to fix.