Discussion: #53

• trainsets
• couplers
• communication through couplers
• TrainSetSystem ?

Findings

• Couplers are modelled in Mover and configured in FIZ.
• Attaching and detaching logic is inside Mover.
• TMoverParameters::CouplerForce() is handling auto attaching couplers when allowed
• Attaching vehicles is implemented in TDynamicObject, like TDynamicObject::AttachNext - calls Mover's Attach()
• There is also TDynamicObject::attach_coupler_adapter(), which is used in train's command TTrain::OnCommand_nearestcarcoupleradapterattach
• attaching couplers is based on collision detection, which is implemented originally in Mover, but disabled in our copy
• TMoverParameters::Neighbours is public, directly managed by other objects like TDynamicObject (!)
• TDynamicObject is a visual representation of the vehicle and it's couplers; it handles visibility of particular coupler parts and little vehicle movements to reduce glitches

Our requirements:

• coupling logic / trainsets must be implemented outside the Mover
• coupling must work as in the original
• communication must handle our commands, not only Mover's internal

Tests, prototypes

• I've made several tests, starting from python's pure class implementation and finishing on Godot's Nodes
• Nodes feels to be natural to model trainsets top over them, but they can introduce some issues (slow scene tree operations, recalculation of global positions, unnatural inserting vehicles between others must be implemented)
• Node-based approach can't have additional logic like couplers validation, because you can add any node to anywhere
• Less expensive and very API friendly is the impl based on bi-directional list of RailVehicle objects (base classes for all vehicles); but it will not be visible in Godot Editor as ordered vehicles grouped in a trainset

Conclusions

• TDynamicObject's and command logic must be re-implemented from scratch (this is a good news)
• full coupling requires collision detection
• the problem must be splitted into three parts: trainsets logic and interface (this tasks), collision detection, couplers model and physics (mapping trainsets and couplers to Mover)
• Node-based approach will introduce more problems than benefits
• Mover's coupler physics must be calculated (called directly or reimplemented outside)
• Mover's internal communication should by bypassed / removed
• TrainSets are RailVehicle managers: they should traverse/operate on a RailVehicles set

Model

• introduce RailVehicle - a base class for all rail vehicles
• implement attach/detach and traversing logic in RailVehicle
• introduce Coupler resource class based on FIZ spec
• add front_coupler and read_coupler to RailVehicle (or coupler_head/coupler_tail)
• (re)implement communication logic outside vehicles (TrainSet/TrainSetSystem), but add shortcuts like RailVehicle.send_internal_command()