Correct 3 more wrong names, cascading across 3 already-published pages Re-checking mv_convert_slot_nr's own already-published call targets (not a fresh lookup) found IsValid__10EHTreeNodel, writeProtocolHeader__ 19CfcNetMemoryChannel, and close__21CfcIoFileOutputStream are all wrong -- same address, same unreliable resolution method. The correction cascades to SetRouteObject (same 2 names, same address) and 0x78834c (whose CfcNetMemoryChannel claim leaned on the now-retracted one, and an independent spot-check of its own address confirms it's also not a simple destructor). The silver lining: the real content at the IsValid/writeProtocolHeader address is genuinely valuable -- a complete cluster of ~20 tiny getter/setter functions plus a comparison function, confirming a real struct layout (see Firmware-Fn-EHTreeNode-struct-layout, committed separately). Lesson: a wrong name doesn't mean discard the call target -- read what's actually there first.
Trace 3 more ADAS-family functions, deepening the new subsystem TransformHeadingAngleRelative and ReverseTransformAngle confirmed as a real heading-angle transform pair (likely camera<->head-unit frame conversion). UpdateSettingsDueToDVDChange confirms the ADAS subsystem deregisters a model subscription on disc change. SetRouteObject ties AdasRouteObject directly into the existing route-search machinery (master_rec/possible_paths) and introduces a new real global, getCurrentCarPosition (DyCoCCPData -> vehicle_location). Also: the 'no locally-visible blr' anomaly now confirmed on 7 distinct functions (up from 4), spanning both the original route-path functions and the new ADAS family equally -- consolidated the central note rather than re-deriving it per page.