Files

T

y.wang e1e5fbf0c1 feat: Modus 3 mit optionalem AS/ES, ES-Frage vor dem Bau; Helfer rollenbasiert benannt

WARUM MODUS 3 BLEIBT
Modus 2 und 3 arbeiten beide auf einem gezeichneten Pfad (LINE/ARC), aber sie
loesen verschiedene Aufgaben:
  Modus 2 = Randwertproblem - Start UND Ziel (je X/Y/Z) sind bekannt, die
            Zwischenhoehen werden gerechnet, die Zielhoehe wird exakt
            getroffen.
  Modus 3 = Anfangswertproblem - die Kette wird mit vorgegebenen Winkeln
            vorwaerts durchgebaut, die Endhoehe ist das ERGEBNIS.
Modus 3 kann damit etwas, was Modus 2 grundsaetzlich nicht kann: ohne
vorgegebene Zielhoehe arbeiten ("folge dieser Linie mit 3 Grad und lass uns
sehen, wo wir landen") - und er hat keinen Solver, der scheitern kann.
Dazu kommt ein harter Bestandsgrund: Modus 3 schreibt ein eigenes Journal
(Marker "linienzug3") und ist per Doppelklick editierbar. Faellt der Code
weg, verlieren alle bereits damit gebauten Ketten ihren Editier-Pfad.
Der Stempel "Legacy / wird umgebaut" war ueberholt und ist raus.

MODUS 3 - DREI AENDERUNGEN (Nutzer-Vorgabe 2026-10-22)
1. "AS bauen?" und 2. "ES bauen?" sind jetzt abfragbar (vorher wurden beide
   immer gebaut), zusammen mit Winkel und Seite in je EINEM Dialog - dasselbe
   Muster, das Modus 2 schon nutzt (vflw-gruppe-as-impl), kein neuer Code.
   Ohne AS beginnt die Kette direkt am Startpunkt (flacher Rahmen statt
   Block); die Fussabdruck-Trimmung der ersten Geraden rechnet dann von
   selbst 0, weil Rahmen und Startpunkt zusammenfallen.
3. Die ES-Frage steht jetzt VOR dem Bau. Das behebt einen echten Fehler: die
   letzte Gerade wird um "Separator + ein-dx" gekuerzt, ein-dx wurde aber
   gelesen, BEVOR es gesetzt war - beim ersten Lauf griff der Schaetzwert
   *vfk-as-es-fallback-dx*, bei jedem weiteren stand dort der Wert der
   VORHERIGEN Kette (falscher Winkel, falsche Seite). Jetzt traegt die
   Trimmung den echten Fussabdruck der gewaehlten ES-Variante; ohne ES
   entfaellt sie ganz.

ABWAERTSKOMPATIBILITAET
Das Verschieben der ES-Frage aendert die Journal-Reihenfolge. Bestehende
"linienzug3"-Ketten bleiben per Doppelklick nachbaubar: alt-journal erkennt
sie am WERT des ersten Antwort-Eintrags ("30"/"90" = alt, "1"/"2" = neu, die
Mengen sind disjunkt) und spielt sie in der alten Reihenfolge ab. Dafuer der
neue Helfer vfl-replay-peek-wert neben vfl-replay-peek-art.

DIALOG vflw_as
Die Seitenauswahl wurde bei 30 Grad ausgegraut und NICHT in die Pending-Queue
gelegt - eine reine Modus-1-Regel (dort ersetzte die Zufuehrungsachse die
Seitenfrage). Modus 1 hat seit 2026-10-21 seinen eigenen Dialog; uebrig
blieben ES-Element sowie Modus 2/3, wo die Seite IMMER gebraucht wird - dort
ging bei 30 Grad ein zweites Fenster nur fuer die Seite auf. Entfernt.

NAMENSSCHEMA (faellt in denselben Commit, weil dieselbe Datei)
Die Helfer-Praefixe vfl2-/vfl3- stammten aus einer Planungsphase vor der
endgueltigen Menue-Zuordnung und waren dazu VERTAUSCHT: alle vfl3-* gehoeren
zu Modus 2, die vfl2-* zu Modus 3 - und drei davon zu BEIDEN. Eine
Modus-Nummer war fuer diese drei also gar nicht richtig vergebbar. Sie heissen
jetzt nach ihrer Rolle: vfl-zsolve-* (rechnet die Hoehen durch, nur Modus 2)
und vfl-pfad-* (arbeitet am gezeichneten Pfad, Modus 2 UND 3). 18 Funktionen,
jede Aufrufstelle maschinell gegen die Definitionen geprueft. Die falsche
Block-Ueberschrift "MODUS 3: Pfad + Ziel-Hoehe" (gemeint war Modus 2) ist
korrigiert, beide Gruppen haben jetzt einen erklaerenden Kopf.
vfl-zsolve-bruecke (frueher vfl3-solve-bruecke) wird von niemandem aufgerufen
- bewusst stehen gelassen und markiert, Loeschen gehoert in ein
Tote-Code-Review.

MENUE
Die Modi heissen jetzt nach ihrem Unterschied statt nach der Bedienung:
"aus 3D Linie mit Zielhoehe" / "aus 3D Linie ohne Zielhoehe" (vorher
"3D Objekte stueckweise (in Arbeit)").

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-10-22 12:01:16 +02:00

6.2 KiB

Raw Blame History

VarioFoerderer-Cluster — Analyse Parameter-Buendelung (Struct-Potential)

Bestandsaufnahme der globalen Variablen und Funktionssignaturen in Lisp/vf_core.lsp, vf_konstanten.lsp, vf_standard.lsp, vf_etage.lsp und vf_linienzug.lsp — als Grundlage fuer die Frage, ob sich haeufig gemeinsam durchgereichte Parameter zu einem Struct (in AutoLISP: eine benannte Alist) buendeln lassen, um Funktionssignaturen mit 5+ Parametern zu verkuerzen. Stand: 2026-09-01, rein analytisch, keine Codeaenderung.

Ausgangsbefund: globale Variablen

Die globalen Variablen der drei Module sind kein Parameter-Problem:

vf_konstanten.lsp enthaelt ausschliesslich feste *vfk-*-Konstanten (Winkel, Laengen, Toleranzen), die einmalig per ssg-cfg-or/Guard gesetzt und direkt gelesen werden, nicht als Parameter durchgereicht.
vf_core.lsp/vf_standard.lsp/vf_etage.lsp haben Init-Flags/Caches (*lib-initialized*, *ks-cache*, bogen-auf/bogen-ab), die Typ-Registry *vf-typ-registry* und wenige AS/ES-Massen-Offsets (aus-dx usw.).
vf_linienzug.lsp haelt zusaetzlich Journal-/Replay-State (*vfl-journal*, *vfl-replay-queue*), Wizard-Dialog-State (*vflw-pending*, *vflw-menu-*) und neun parallele *vfl-acc-*-Globals als "Ketten-Akkumulator" (siehe Abschnitt 4).

Das eigentliche Problem liegt woanders: dieselben 4-8 thematisch zusammengehoerigen Werte werden wortwoertlich durch dutzende Funktionssignaturen durchgereicht, weil es dafuer noch keinen gebuendelten Wert gibt.

Bereits vorhandene Struct-Vorbilder im Code

Diese Muster existieren schon und sind das natuerliche Vorbild fuer eine Erweiterung (AutoLISP-Konvention: Alist statt echtem Struct):

KS-Frame (P xu yu zu) — Punkt + 3 Achsvektoren als ein Wert (vf_core.lsp, frame in vf_linienzug.lsp)
prefill-Alists (string-keyed, (cdr (assoc "key" prefill))) zur Dialogvorbelegung in vfs-dialog-eingabe-basis/vfs-dialog-winkel-verteilung
*vf-basis-eingabe-felder* + vf-basis-eingabe-entpacken — eine benannte, geordnete Feldliste, generisch per foreach/nth entpackt
ergebnis-liste-Eintraege (winkel L_GF L_VF gueltig) aus vf-winkel-solve/berechne-alle-winkel
kette-rec in vf_linienzug.lsp — Positions-Accessor-Funktionen (vfl-kette-rec-ename usw.) ueber eine flache Liste
*vfl-glied-schema* — Schema-Tabelle (Label -> Felddefinitionen) als struct-aehnliche Serialisierung pro Ketten-Glied

Funktionen mit den meisten Parametern

Funktion	Datei	Anzahl Parameter
`vf-block-erstellen`	vf_core.lsp	18
`vf-make-label`	vf_core.lsp	13
`vf-dialog-berechnen-einfuegen`	vf_core.lsp	12
`variofoerderer-einfuegen`	vf_standard.lsp	10
`etage-foerderanlage-einfuegen`	vf_etage.lsp	10
`vfs-standard-dialog-berechnen-einfuegen`	vf_standard.lsp	10
`vfe-etage-dialog-berechnen-einfuegen`	vf_etage.lsp	10
`vfl-block-erstellen`	vf_linienzug.lsp	10
`vfl-modus-abbruch-sichern`	vf_linienzug.lsp	9
`vf-winkel-solve`	vf_core.lsp	8
`vfs-mitte-teil`, `vfl-vf-einheit`, `vfl-vf-einheit-abschluss`	standard/linienzug	je 7
`vfs-vf-koerper`, `vfl-insert-es-element`, `vfl-zsolve-es-fueller`	standard/linienzug	je 5-6
die vier `insert-hz-*`-Funktionen	vf_etage.lsp	je 4-6

Struct-Kandidaten

geometrie-basis (deltaL deltaH richtung startpunkt hz seite [dim geruest-einzelmodul geruest-typ motorseite]) — identisch in vf_core, vf_standard, vf_etage UND vf_linienzug. Erweitert direkt das bestehende *vf-basis-eingabe-felder*-Muster. Groesster Hebel, da er in fast jeder Top-Funktion mit vorkommt.
ergebnis-geometrie (best-winkel L_GF1 L_GF2 L_VF richtung) — entspricht der Form der ergebnis-liste-Eintraege aus vf-winkel-solve; steckt in vf-make-label, vf-block-erstellen, vfs-mitte-teil, vfs-vf-koerper, variofoerderer-einfuegen, etage-foerderanlage-einfuegen.
hoehen (hoehe-von hoehe-bis deltaH) — klein, wiederholt sich in vf-make-label/vf-block-erstellen; evtl. eher in Kandidat 2 integrieren als eigenstaendig fuehren.
geruest-optionen (geruest-einzelmodul geruest-typ motorseite) — reist durch Dialog-/Edit-/Erstellen-Funktionen; Alternative: direkt in geometrie-basis aufnehmen statt separat zu fuehren.
ketten-meta (vfl-nummer anzahl-gf anzahl-vf hoehe-von hoehe-bis delta-l-total as-seite es-seite) — nur vf_linienzug, betrifft vfl-block-erstellen (10) und vfl-modus-abbruch-sichern (9).
Rotation-Paar (hz-winkel vert-winkel) (optional mit vorgerechneten sin/cos) — die vier insert-hz-*-Funktionen in vf_etage.lsp teilen dieses Paar plus dupliziertes Grad->Bogenmass/sin/cos; ein gemeinsamer Wert wuerde auch die Code-Duplikation beseitigen, nicht nur die Parameterzahl.
*vfl-acc-*-Akkumulator — kein Parameter-, sondern ein State-Problem: neun parallele globale Listen (*vfl-acc-lvf*, *vfl-acc-lgf*, *vfl-acc-gfwinkel*, *vfl-acc-richtung*, *vfl-acc-winkel*, *vfl-acc-motorseite*, *vfl-acc-gfbogen*, *vfl-acc-variokurve*, *vfl-acc-separator*), die konsequent zusammen gesetzt/gelesen werden. Ein Record statt neun losen Globals waere robuster gegen Vertipper/vergessenes Zuruecksetzen.

Mit Kandidat 1+2 allein liesse sich vf-block-erstellen von 18 auf ~6-7 Parameter bringen, vf-make-label von 13 auf ~5-6, und die gesamte 10-Parameter-Familie auf ~4-5.

Einschaetzung

Es besteht spuerbares Potential, aber mit Vorsicht: vf-dialog-berechnen-einfuegen haengt an der Typ-Registry (*vf-typ-registry*, berechne-fn/einfuege-fn) und wird von Standard-, Etage- und indirekt Linienzug-Pfaden aufgerufen. Eine Signaturaenderung dort zieht Aenderungen an allen drei registrierten Funktionen sowie den Edit-/Rebuild-Pfaden (vfe-edit-ent, vfl-edit-ent, Journal-Replay) nach sich. Empfohlene Reihenfolge bei einer Umsetzung:

Risikoarme Blattfunktionen zuerst (Rotation-Paar in vf_etage, vf-make-label).
geometrie-basis/ergebnis-geometrie als groessere, aber isolierbare Cluster.
Die Registry-Signatur (vf-dialog-berechnen-einfuegen) und die Edit-/Replay-Pfade erst zuletzt anfassen.

Stand jetzt: reine Analyse, keine Umsetzung angestossen.

6.2 KiB Raw Blame History