Unloading: extract transportee choice to a function

[sprunk]

No logic change.

[lhog]

Maybe:

if (const auto* transportee = GetTransporteeFromUnloadOrder(c, transportees); transportee) {

?

[sprunk]

transportee is used a lot afterwards though (from line 1928/1927 until 1972/1971), its scope is the whole rest of the function and not limited just to this check.

[saurtron]

Tested this and seems to work fine, also, regarding your question in code: UnloadLandFlood() has just FinishCommand here, is the difference meaningful?

Right now, most of the code when faced with nothing to unload will just do StopMoveAndFinishCommand. Check for example ExecuteUnloadUnit, or ExecuteUnloadUnits. That case is a bit different (since it's for when it does have transportees but an unload order with bad id), but not sure it's going to make a big difference.

Also, at least in bar or z-k I'm not sure anyone actually uses transportUnloadMethod=2 (UNLOAD_LANDFLOOD) where FinishCommand is used instead of StopMoveAndFinishCommand. Also don't see the engine setting that itself but I could be overlooking something.

I also tried changing to FinishCommand() when having an empty queue, (since I couldn't test the case where it has an unload order with an id that's not in the queue so easily... seems to be a pretty niche case too), and for the life of me I couldn't see any difference, but could be because of something else, since a lot happens after/during StopMoveAndFinishCommand/FinishCommand. Usually, if the queue is empty, then Idle() will be called, otherwise it's going to go to the next command anyways, so the difference must be minimal, but it could affect the blending to the next command/idle in some way.

It could also be conflicting with orders to separate a bit from the unload pos. I could see in some cases the transport lands on top of the unit, while others it will go a bit further away, but couldn't correlate that to either of those two being used :P... also in any case the good one would be FinishCommand but can't really tell without a deeper investigation, and the code uses the other one most of the time so I guess there's a reason but couldn't really figure out for now.