y.wang
e1e5fbf0c1
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>
120 lines
6.2 KiB
Markdown
120 lines
6.2 KiB
Markdown
# 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
|
|
|
|
1. **`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.
|
|
2. **`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`.
|
|
3. **`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.
|
|
4. **`geruest-optionen`** `(geruest-einzelmodul geruest-typ motorseite)` —
|
|
reist durch Dialog-/Edit-/Erstellen-Funktionen; Alternative: direkt in
|
|
`geometrie-basis` aufnehmen statt separat zu fuehren.
|
|
5. **`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).
|
|
6. **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.
|
|
7. **`*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:
|
|
|
|
1. Risikoarme Blattfunktionen zuerst (Rotation-Paar in vf_etage,
|
|
`vf-make-label`).
|
|
2. `geometrie-basis`/`ergebnis-geometrie` als groessere, aber isolierbare
|
|
Cluster.
|
|
3. Die Registry-Signatur (`vf-dialog-berechnen-einfuegen`) und die
|
|
Edit-/Replay-Pfade erst zuletzt anfassen.
|
|
|
|
Stand jetzt: reine Analyse, keine Umsetzung angestossen.
|