VF & VVE compat: rewrite for 1.6

[sviyh]

Summary

• Rewrite vehicle launch/flight sync to work around MP's broken GlobalTargetInfo serializer (PlanetTile 8-byte write vs 4-byte read in RW 1.6)
• Use prefix→static sync method pattern for Launch, OrderFlyToTiles, VehicleCaravan.Launch, and StartTargetingLocalMap to avoid ThingComp serialization bugs and ensure atomic world object creation
• Fix arrival action state loss (mapParent/landingCell/rot) by syncing StartTargetingLocalMap for both spawned and caravan cases
• Add thingId fallback in SyncVehiclePawn for flight→arrival race conditions
• Code cleanup: extract TargetData helpers, cache field refs, remove stale comments

[mibac138]

Rewrite vehicle launch/flight sync to work around MP's broken GlobalTargetInfo serializer (PlanetTile 8-byte write vs 4-byte read in RW 1.6)

Opened a PR to fix this rwmt/Multiplayer#840, thank you for mentioning it

MP's ThingComp reader has a bug: if the parent Thing resolves to null, it
returns without reading the compIndex ushort, misaligning all subsequent reads.
By using a static sync method with the vehicle as a plain Thing arg, we avoid
the ThingComp serializer entirely.

I'm not sure I understand, do you want to read a ThingComp without a valid parent (i.e. parent = null)? Why then, you are passing the parent as an argument to a SyncMethod and not care about a possible null value? The only way this would make sense to me is if CompVehicleLauncher.Vehicle != CompVehicleLauncher.Parent but it is the same thing (ref).

        private static bool PreLaunch(CompVehicleLauncher __instance,
            SmashTools.Targeting.TargetData<GlobalTargetInfo> targetData, IArrivalAction arrivalAction)
        {
            if (!MP.IsInMultiplayer || MP.IsExecutingSyncCommand)
                return true;

            ExtractTargetData(targetData.targets, out var tileIds, out var layerIds, out var worldObjectIds);
            //                        vvv  pass Thing instead of ThingComp
            SyncedLaunch(__instance.Vehicle, tileIds, layerIds, worldObjectIds, (VehicleArrivalAction)arrivalAction);
            return false;
        }

        private static void SyncedLaunch(VehiclePawn vehicle, List<int> tileIds, List<int> layerIds, List<int> worldObjectIds, VehicleArrivalAction arrivalAction)
        {
            if (arrivalAction != null)
                arrivalActionVehicleField(arrivalAction) = vehicle;
            // vvv No null checks
            vehicle.CompVehicleLauncher.Launch(ReconstructTargetData(tileIds, layerIds, worldObjectIds), arrivalAction);
        }

I do agree that the MP serialization should read and write a consistent amount of data and not misalign anything. I just don't understand how does your fix for this, actually fix anything (assuming you are not serializing a null parent and it looks to me like you don't, or if you do, it'll error anyway)

[sviyh]

@mibac138
thanks for the fix for teh target planettile bug. Will simplify the code once merged.

As for the null check I think there was race condition I was protecting againts. There is an interval of time when the vehicle already left the settlement (lauched) but not yet transitioned to the world map. Will double check as well together with the planet tile thing. So let's wait for merge and release.