I feel like the parts are more reflective of the underlying implementation rather than the functionality, and also perhaps a bit complex.
Absolutely… I haven’t inspected 1st hand the code myself (Or I would be just adding code to git for aproval :)). I have just used my knowledge as programmer, after seeing how vehicles work ingame, and “distilled” a suggestion that “scavenge” as many existing features as possible. That’s why parts are so tied to the potential implementation and a bit far from the real gadgets involved into vehicle docking.
Personally I'd probably prefer a single in-frame part on D(that can coexist with anything else), and a single part on G, perhaps even of the same type, with the connected vehicles being treated equally(e.g. make a new vehicle, temporarily remove the underlying vehicles from the world, recreate them based on some original vehicle field)
That would require extensive data modification because you will have to “temporarily store” the original configuration. Maybe I should ellaborate a bit more why I think each part is needed:
LBD: At its essence is just the spawn point on Deploy. Coincidently, most players on this thread instinctively think on the common scenario of the “Towing Vehicle” were D enters and exits through the same access point but in reverse, that’s why I also chose to make it the landing point. But IRL there are plenty of scenarios were vehicle storage is not done that way… The best example I can find is a Carrier’s Figther complement, that docks on one side but “deploys” through another. Notice how I deliberataly left LBD selection on spawn logic a bit fuzzy and atm just simply linked to “be in front” of G’s HS… With a more ellaborate model you can split LBDs into a landing point and a spawn point BOTH linked to the same HS to recreate complex vehicles in the future. Regarding your concerns about the realism of the docking operation, indeed, restricting angles could be added, but first I would start by restricting speeds (to just 16kph for example) not only for the sake of realism… But also to ONLY spend time checking LBDs pressence at this particular speeds (the 1st step with Cruise Control On forward or backwards) while most of the time the code sections ran when a vehicle is moving are the current ones.
LBF: Is just simply needed to designate a “capacity” so a big vehicle requires a bigger storage. Again I’m following the average perception of the users requesting this feature, that is internal docking. Coming back to RL, for example, the external hardpoints used for missiles are an example of 1 vehicle “stored” in another without the needs of “LBFs”. This could also be mimicked with my suggestion if the HS was at the outer border and also detected as a valid “collision point” to trigger the fusion, this time the Fusion Code will not check, nor replace LBFs (But notice that the resulting plan still needs to label one of the vehicle squares using DA’s to distinguish how to split them… Even more, this DA should be new as, on Deploy, shouldn’t generate LBFs back on G).
HS: It’s basically the “boundary” between vehicles. I added “directionality” because, on a Carrier Vehicle, the “deployment vector” do not have to necesarily match the movement vector of the Garage (What happens with some Racing Bikes transport trailers some teams use… The bikes enter/exit through lateral ramps). It’s still, ofc, a requirement to perform deployment/storage operations WHILE on the move IRL. I chose to use the Headlight Dialog because it’s capable of “storing” facing information into a given vehicle square. In principle a simpler “widget” were the user selects front, back, left or right orientation for the HS is enough, as arbitrary angled docking bays do not work well with the “squared” model vehicles use on DDA.
HP: After a second thought, in fact I agree with you… This component is superfluous for now… As a basic logic of “Docking Point will be the central southernmost square of D’s plan” will work most of the time (With the extra advantage of NOT having to alter any of the currently created default vehicle templates). The problem are even width vehicles, which should require an arbitrary decission on which square to select as HP. Nonetheless, and looking ahead, the original idea of an specific HP component was to allow for orthogonal docking were D plan final orientation in the resulting vehicle wasn’t only controlled by HS orientation (Think on how a motorbike sidecar is attached, in comparison with how you drive-in a car into a towing truck).
DA: Is, by far, the most imporant component. It’s critical to be able to distinguish what to split from what WITHOUT actually having to modify the current way vehicles function as single entities, which, in turn allows easy to access operations to D while docked (Like repairing it or accessing its storage). It’s also needed so the total weight of the final vehicle respects the basic premise of D + G, as we are destroying LBFs on fusion. If I just add a logical flag/state/whatever the information about the weight to pay for storage would be lost. Notice that this simple mplementation is far from perfect, for example, If you design a “shared bay” with multiple HS in them and 2 vehicles stored at different times end been adjacent, the resulting “wreckage” will be deployed at the same time by operating ANY of the HSs. It would fall in player’s hand to be carefull when mixing multiple HS on the same G. Notice that the source of most problems is precissely accessing D’s features while docked WITHOUT mixing operative stats of D with G but, again, a lot of users on this thread requested precissely this (In fact the main reassons IRL to dock one vehicle into another is usually to perform maintenance/refuel/rearm and/or that the smaller vehicle benefits from the superior armor/defenses/operative range of the Garage).
EDIT: Forgot one detail… The names I use are just functional. If it helps visualizing, for example, DA could appear ingame as “Docking Harness” which will loosely ressemble the different implementations used IRL to secure D’s hull to G’s to prevent violent motions from making it damage itself or the hangar interior by collision. The same could be applied to HS… That could translate to “winch”, “clamp”, “hardpoint”, etc.
