Drei zusammenhaengende Korrekturen am GF-Zweig mit ES-Element (Modus 1).
1) ES-Fussabdruck wurde massiv unterschaetzt (333.65 mm zu lang)
Reserviert wurde (abs ein-dx) - die Block-X-Komponente aus
vf-element-masse. Ein Element wird aber so gedreht eingebaut, dass sein
KS_EIN auf der Fahrtrichtung liegt; beim drehenden ES_Element_30
(ein-ang=120 Grad) landet dadurch ein Teil der Block-Y-Komponente auf der
Fahrtachse. Real verbraucht es laengs 576.2 mm statt der reservierten
242.6 mm - die Kette ragte um die Differenz ueber den gepickten Endpunkt
hinaus (Nutzer-Befund 2026-10-09).
Warum das lange unentdeckt blieb: beim ES_Element_90 ist ein-ang=0, dort
ist (abs ein-dx) ZUFAELLIG richtig. Der frueher bestaetigende 90-Grad-Test
konnte den Fehler strukturell nicht finden (Nutzer-Hinweis).
Neu in vf_core.lsp: vf-element-laengs / vf-element-quer (hz-unabhaengige
Projektion auf bzw. quer zur Fahrtrichtung), vf-set-es-masse setzt
zusaetzlich ein-laengs / ein-quer. In vf_linienzug.lsp liest vfl-es-laengs
den Wert mit Rueckfallkette; ein bewusst genulltes ein-dx gewinnt dabei,
damit die rund zwei Dutzend Null-/Restore-Stellen keinen Doppelabzug
bekommen.
In BricsCAD bestaetigt: Separator+ES verbrauchen 875.83 mm gegen 875.79 mm
Soll (0.04 mm), Hoehe 151.23 gegen 151.20 mm.
2) Endpunkt per Ziellinie statt per Klick
Steht die Fahrtrichtung durch den Vorgaenger fest, ist die Laenge nicht
mehr frei: die (um den ES-Querversatz seitlich versetzte) Bahn des
ES-KS_AUS trifft eine Ziellinie in genau einem Punkt. Ein Klick kann den
nur annaehern. Neue Frage mit zwei gleichwertigen Optionen (Radio-Buttons
im Wizard-Modus): Ziellinie durch ZWEI PUNKTE zeichnen - Schnittpunkt wird
gerechnet - oder wie bisher einen Punkt waehlen.
REIN PLANAR: die Hoehe kommt weiterhin aus dem Gefaellewinkel, die
Ziellinie bestimmt nur X/Y (Nutzer-Praezisierung).
Beide Wege schreiben denselben einzelnen "DL"-Journaleintrag - Replay,
Doppelklick-Edit und 2D/3D-Konvertierung muessen von Ziellinien nichts
wissen. Die Bindung an die Linie besteht nur beim Bauen: wird die Linie
spaeter verschoben, folgt die Kette NICHT.
Abwaertskompatibilitaet: die neue Frage erzeugt einen zusaetzlichen
Journaleintrag, den aeltere Ketten nicht haben. vfl-replay-peek-art sieht
beim Replay nach, was tatsaechlich ansteht; steht dort ein "DL", ist es
ein Altbestand und die Frage entfaellt - sonst haette sie den Laengenwert
als Antwort verschluckt (Queue-Desync).
3) Bedienung: Achsenzwang und ruhige Ansicht
vfl-getpoint-achse zwingt den Cursor beim Picken auf die Anschlussachse
(SNAPANG + ORTHOMODE, kein BKS-Wechsel - getpoint liefert daher
unveraenderte Koordinaten). Nur die horizontale Richtung wird erzwungen,
die Hoehe bleibt frei.
vfl-view-refresh zoomte vor JEDER Laengeneingabe hart auf _Extents - die
Ansicht sprang bei grossen Anlagen nach jedem Klick weg. Jetzt wird nur
noch eingegriffen, wenn der Baupunkt aus dem sichtbaren Ausschnitt laeuft,
und dann per _ZOOM _Center unter Beibehaltung der Zoomstufe.
13 neue Unit-Tests (etage-laengs/-quer,
vfl-es-laengs, vfl-kreuz2, vfl-laenge-bis-ziellinie inkl. Realfall aus dem
BricsCAD-Log), Suite 533/533 gruen. lang-Paritaet geprueft.
Offen und bewusst nicht angefasst: vfl-winkel-machbar-p nutzt aus-dx/ein-dx
ebenfalls als Laengsmass und hat damit denselben Fehler (AS_30: 276 mm,
ES_30: 334 mm). Der saubere Fix fuellt ein-dx/aus-dx an der Quelle mit dem
Laengswert - das beruehrt rund 87 Fundstellen samt ihrer Null-/Restore-
Konvention und gehoert separat getestet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
y.wang
821b81135d