0001 — `RbCable/Collision` is registered only in a commented-out line

ID	0001
Class	BUG
Severity	2
Status	blocked
Models	RbCable/Collision (class Collision; it has no documentation page because its @group line is commented out too)
Found	2026-09-15 audit (e3f3107)
Decision needed	"enable" the registration (then the initial conditions must also be made reproducible) or "delete" the class and its example.

Evidence

src/fhsim_marine_elements.cpp:21

//ADD_SIMOBJECT_REF3(RbCable,Collision,      RbCable/Collision);

The class is otherwise fully present: src/RMCable/Collision.cpp and Collision.h are in RMCable_SRC/RMCable_HDR (src/RMCable/CMakeLists.txt:9, :20), and the header is included unconditionally at src/fhsim_marine_elements.h:9. The example file names the type string anyway — examples/input/CableCollision.xml:6:

SimObject = "RbCable/Collision"

getSimObject therefore falls through to return nullptr (src/fhsim_marine_elements.cpp:51) for that name.

Effect

examples/input/CableCollision.xml cannot be loaded by any build of this release. The class is compiled into the library and shipped, but unreachable from XML. The failure surfaces as a null SimObject at model assembly, not as a message about a misspelled type.

A second, related dead reference sits at src/fhsim_marine_elements.cpp:45 (//ADD_SIMOBJECT_REF(CNetStructureScreen, Net/NetStructureScreen);) with its include commented out at src/fhsim_marine_elements.h:36; there is no CNetStructureScreen class in the tree at all, so that one has nothing to re-enable.

Possible fix

• (a) Uncomment line 21 and add a smoke test that loads CableCollision.xml.
• (b) Leave the registration out and delete examples/input/CableCollision.xml, the Collision sources and their CMakeLists.txt entries.

Owner question, open

was Collision disabled deliberately? It seeds its own initial conditions from rand() (src/RMCable/Collision.cpp:40-41), which makes it non-reproducible run to run, and that is a plausible reason for someone to have switched it off rather than an oversight. The answer decides between (a) and (b), and (a) is only safe if that rand() is acceptable or replaced.

Test that would prove it

A test that builds a TestSpec over examples/input/CableCollision.xml and asserts the model assembles. It fails today at model assembly and passes under option (a).

Risk

Option (a) adds a SimObject to the public surface of the library and, with the rand() seeding in place, a test over it cannot compare against a stored reference. Option (b) removes a type string that may be referenced by input files outside this repository.

---

Why not solved (fix pass 2026-09-15)

Re-confirmed at HEAD: the ADD_SIMOBJECT_REF3(RbCable,Collision,...) line is still commented out, Collision.cpp:31-41 seeds its states from rand(), and Collision.h:2 even has its @group line commented out. Whether to re-enable the class or delete it together with CableCollision.xml is a product decision. Re-enabling would add a public type string whose behaviour is non-deterministic because of the rand() initial conditions, which is worse than leaving it unregistered. Deleting it removes source the owner may want to revive. Smallest owner decision: "enable" (then the initial conditions must also be made reproducible) or "delete".

---