Commit Graph

13 Commits

Author SHA1 Message Date
y.wang 833a4b60a6 fix: Lauf-Anfang als selbstbeschreibender Wert, Dialog-Hinweise lesbar
Die Frage "Lauf beginnen mit" (Modus 2) journalisiert jetzt den WERT
("mit-gf1"/"direkt"/"ohne") statt der Auswahl-Ziffer. Anlass war die
Umstellung der Optionsreihenfolge auf Regelfall zuerst: mit einer Ziffer
haette dieselbe "3" vor und nach der Umstellung Verschiedenes bedeutet,
eine bestehende Kette waere beim Doppelklick still mit einer ANDEREN
Anfangsvariante neu gebaut worden. Alte Ketten laufen ueber die Tabelle
*vfl-m2-anfang-alt* weiter; ein Wert, der weder Alt-Ziffer noch gueltiger
Wert ist, bricht den Aufbau ab und nennt Kette und Wert, statt eine
Variante zu raten.

Weiter aus der Modus-2-Arbeit:
- Laengenbudget je VF-Einheit (max. 25 m, max. 2 Vario-Kurven,
  *vfk-vf-kurven-max*), bei Ueberschreitung automatischer Schnitt
- nach einer VF-Geraden ist der Bogentyp waehlbar (GF-Bogen/Vario-Kurve)
- Segmentnummer steht im Kopf jedes Dialogs
- "Separator NACH" ist am letzten GF-Stueck vor einem ES gesperrt, der
  automatische Separator wird dort erklaert
- "Ohne Umlenkstation" ist mit AS-Element gesperrt
- Fuellerlaenge nur noch dann aus dem Rueckanker, wenn der VF-Lauf das
  Pfadende ist

Dialoge: Hinweis steht in Klammern hinter dem Ankreuzfeld statt darunter,
Lauf-Anfang-Optionen tragen die Nummern der Konsolenliste, die
Begruendungszeile ist breit genug und wird nicht mehr abgeschnitten.

14 neue Unit-Tests zur Wert-Normierung (durchlaufen die Alt-Tabelle).
Sprachdateien 1205/1205 synchron.

Offen: der Fuellerlaengen-Fix ist in BricsCAD noch nicht nachgemessen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-23 15:39:57 +02:00
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
y.wang 3116e639eb fix: Etage-Solver bilanziert Ein-/Auslauf auf der Hauptachse statt im Blocksystem
Die gebaute Etage-Kette endete 987.63 mm zu weit (X) und 3.46 mm zu hoch (Z).
Der Fehlbetrag lag vollstaendig im Ein-/Auslauf: der Solver reservierte dort
1177.87 mm, real verbraucht die Kette 2165.09 mm.

Zwei Ursachen:

(a) vf-element-masse liefert KS_EIN->KS_AUS im BLOCK-Koordinatensystem. AS
    und ES werden aber um (hz - ein-ang) gedreht eingebaut - beim
    AS_Element_30 ist ein-ang = 90 Grad, dadurch landet die Block-Y-
    Komponente auf der Hauptachse. Bilanziert wurde die Block-X-Komponente:
    AS 209.7 statt real 486.10, ES -242.6 statt real 525.29.

(b) Die Auslauf-Staustrecke wurde fix mit 400 mm budgetiert, ist seit dem
    Umbau "Auslauf RUECKWAERTS vom ES gerechnet" aber variabel (im Testfall
    334 mm). Daraus die 3.46 mm Resthoehe.

Fix: neue Funktion etage-rand-budget (seite) rechnet Einlauf (Schritte 1-4)
und Auslauf (12-15) exakt so, wie etage-foerderanlage-einfuegen sie baut,
inklusive analytisch vorab bestimmtem L-exit. Kern sind die reinen,
hz-unabhaengigen Projektionen etage-laengs/etage-quer. Die alte Naeherung
bleibt als Fallback, falls ein Block fehlt.

Damit faellt auch die bisherige Annahme, Laengentreue und seitliche
Fluchtung des ES-KS_AUS seien nicht gleichzeitig loesbar: die Bauschritte
5-11 laufen auf der Hauptachse und tragen nichts zur Quer-Bilanz bei,
L-exit ist deshalb von L_GF/L_VF unabhaengig und vor dem Solve bestimmbar.

Weiter: Konstante *vfk-etage-stau-ein* (400 mm) ersetzt die nackte Zahl an
beiden Stellen; zwei neue lang-Keys (de+en, Paritaet 1095/1095); neuer
Regressionsblock tu-tests-etage in tests/test_unit.lsp mit dem AS/ES-Fall
(Suite 520/520 gruen).

In BricsCAD verifiziert: Soll-Endpunkt (11804.31, 3039.64, 4256.5) exakt
getroffen, Abweichung 0.00 mm in allen drei Achsen.

Offen: bei korrekter Bilanz bleiben im Testfall bei 33 Grad nur 16.13 mm
fuer beide GF-Strecken. Eine Mindest-GF-Laenge als Gueltigkeitskriterium
der Winkelwahl ist noch nicht eingebaut.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-09 18:02:25 +02:00
m.stangl d0fe890d7c Start-Ausgabe entschlacken: per-Modul-Banner auf je eine Zeile kuerzen
Der SSG_LIB-Start gab ~50 Zeilen aus (mehrzeilige >>> ...geladen <<<-Banner mit
Befehlslisten/Block-Pfaden, ===-Trenner, Core-Modul-Auflistung, VarioFoerderer-
Typenliste). Fuer einen einfachen _QNEW-Start zu viel Rauschen.

Gekuerzt (nur die dicksten Bloecke, je Modul bleibt EINE knappe Zeile;
Fehler/Warnungen ALLE unveraendert erhalten):
- Kern-Module (ssg_core/dbg/dialog/layer/id): reine "X geladen"-Zeilen entfernt.
- Feature-Module: KreiselInsert/Gefaellestrecke/VarioFoerderer je auf eine
  ">>> X geladen"-Zeile; Befehlslisten, Modus-/Typen-Aufzaehlungen, Block-Pfade
  und ===-Trenner raus. VF-Submodule (vf_konstanten/standard/etage/linienzug/
  spec) Lade-Banner ganz entfernt (der Sammel-Header deckt sie ab).
- SSG_LIB_Commands "Dummy-Befehle registriert" entfernt.
- menu/SSG_LIB.mnl: ===-Trenner + Core-Auflistung raus; die doppelte
  "Einfuege-Modus 3D"-Zeile entfernt (S:STARTUP gibt sie ohnehin einmal aus).

Behalten (informativ / diagnostisch): [CFG] Config geladen: N Sektionen,
[LANG] N Texte geladen, alle FEHLER/WARNUNG-Zeilen, die Abschlusszeilen
"Alle Module geladen. Menue aktiv." + "Einfuege-Modus: 3D".

Reine Ausgabe-Reduktion, keine Logik geaendert. 243/243 LISP-Unit-Tests gruen;
alle Module laden fehlerfrei (Klammerbalance gegen HEAD unveraendert).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 22:13:33 +02:00
m.stangl 8be256fb5a VF: gemeinsamen Wrapper-Rumpf vf-wrapper-bauen (Standard/Etage + Linienzug)
vf-block-erstellen (vf_core, Standard/Etage) und vfl-block-erstellen
(vf_linienzug) hatten denselben ~25-Zeilen-Rumpf wortgleich: ATTDEFs am
Startpunkt, Entity-Sweep seit lastEnt, Sepliste sichern, ssg-block-wrap-welt,
Layer setzen, Sepliste-XDATA, Attribute setzen, ID + Dim-XDATA. Jetzt in
vf-wrapper-bauen (vf_core) zusammengefasst; beide Aufrufer bauen nur noch ihre
FERTIGE Attributliste (Standard/Etage: feste Werte; Linienzug: *vfl-acc-*-
Komma-Listen) und uebergeben sie - der Rumpf kennt die Attribut-Semantik nicht.

ATTDEF-FORMAT VEREINHEITLICHT auf den kanonischen Stil: 3 von 4 Wrapper-Bauern
(vfl-block-erstellen, Gefaellestrecke, Vario_Kette_Merge) nutzten bereits
identisch (10/11=startpunkt, 40, 70/72/74, alle am selben Punkt). vf-block-
erstellen war der Ausreisser mit Layer-0/Model-Space-Zwang, y-Dekrementierung
je Zeile und fehlenden Ausrichtungscodes - historischer Drift OHNE Effekt bei
unsichtbaren ATTDEFs (Flag 70=1, reine Attribut-Container). Standard/Etage
bauen die ATTDEFs damit jetzt im kanonischen Format.

Toter Code entfernt: *vfk-attdef-zeilenabstand* (einzige Nutzung war die
entfernte y-Dekrementierung). *vfk-attdef-texthoehe* jetzt in vf-wrapper-bauen
zentral genutzt.

Die ATTRIBUTWERTE sind unveraendert (Diff-Review: Bezeichnung wertgleich,
Etage-Bogen-Extra nur von zweitem ssg-attrib-set-on in die Hauptliste gezogen).
Verhaltensneutral fuer den Linienzug (hatte schon das kanonische Format);
fuer Standard/Etage aendert sich nur das (unsichtbare) ATTDEF-Format.

243/243 LISP-Unit-Tests gruen; Python-Suite unveraendert (11 Baseline);
Klammerbalance geprueft. Der Attribut-/Geometrie-Gleichstand von Standard/Etage
ist interaktiv in BricsCAD bzw. per SSG_RUN_ALL_TESTS gegenzupruefen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 21:08:54 +02:00
m.stangl 7dbf1248c9 VF-Linienzug Modus 2/3: Geister-Mini-Objekte aus Pfad-Auswahl filtern
Eine Rechteck-Auswahl kann winzige Geister-/Artefakt-Objekte miterfassen (real:
ein 14-mm-Mini-Bogen). gf-sortiere-objekte haengte sie per Nearest-Neighbor
stumm in die Kette -> ein Geister-Bauteil (im test_modus2.dxf: eine 90-Grad-
Kurve vor dem Motor, die der Nutzer nie gezeichnet hat; im SEGS-Journal als
7. Segment mit Sehne 14 mm sichtbar).

vfl-in-segmente wirft jetzt VOR der Sortierung alle Objekte unter
*vfk-pfad-min-segmentlaenge* (100 mm) aus und meldet Anzahl + Grund
(vfl-m3-mini-objekte-verworfen, de/en). Schwelle konservativ deutlich unter
jedem realen Bauteil (kleinstes: Separator 300 mm; kleinster echter Eck-Bogen
R500/30 Grad hat Sehne ~259 mm) und knapp ueber dem Restlaengen-Clamp (100 mm),
damit kein legitimes Segment faelschlich verworfen wird.

Neue Helfer: vfl-obj-2d-laenge (LINE-Laenge / ARC-Sehne), vfl-filter-mini-objekte
(-> (behalten . verworfen-anzahl)). Neue Konstante *vfk-pfad-min-segmentlaenge*.
Der Bug lag NICHT im SEGS-Umbau (gf-sortiere-objekte/-analysiere-kette
unveraendert) - der SEGS-Journal machte ihn nur erstmals sichtbar.

243/243 LISP-Unit-Tests gruen; JSON valide + de/en-Paritaet geprueft. Der
Geometrie-Effekt (Geister-Segment weg) ist interaktiv zu bestaetigen.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-09-18 17:17:15 +02:00
y.wang 1b49bd3c3b feat: Option 5 "QC Linie mit GF und U-Form" implementiert (Fa/S dynamisch, Kolinearitaet exakt)
Linienzug-Modus 5: AS(90 Grad) -> Richtung+E1 in einem Klick -> 90-Grad-
GF-U-Turn (Gegenseite von AS) -> Fa(fallend, unbekannt)+Sep -> Bogen-auf-6
-> S(steigend, dynamisch 3/6/9/...Grad, flachster passender Winkel wird
automatisch gewaehlt) -> Bogen-ab-6 -> ES, mit exakter Kolinearitaets-
Rueckkehr zur AS-Eintrittsachse (2x2-Gleichungssystem Hoehe+Lage, analog
zu Option 4's E2-Loesung). E1 nutzt AS's real gemessene KS_AUS-Neigung
(neue vf-element-plan-neigung) statt der angenommenen 3 Grad - das macht
Fa/S ueberhaupt erst ueber E1 steuerbar. Bei "nicht baubar" wird eine
exakte Mindest-E1-Laenge vorgeschlagen (wie Option 4's Mindest-
Gesamtlaenge). Zusaetzlich: Bogen-Seite = Gegenseite der AS-Seite (Option 4
und 5), Fehler in vf-element-plan-neigung-Vorzeichen behoben, fehlender
Separator-Fussabdruck in der Hoehen-/Lage-Bilanz ergaenzt.

Neue GF-eigene Vertikalbogen-Bloecke (Vario_Bogen_auf/ab_3/6_rechts, 2D+3D)
fuer die Uebergaenge.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-14 08:36:17 +02:00
y.wang 0a1d21d8c5 fix: VF-Linienzug 100%-Wiederherstellung aus e76e24e abgeschlossen
Restauriert alles aus e76e24e, das nach dem Reset auf master fehlte oder nur
teilweise wiederhergestellt war, und mit dem Kollegen-Umbau abgeglichen:

- vf_core.lsp: Radio-Button-Dialoge fuer Anlagen-Typ/Linienzug-Modus
  (vfc-dialog-typ-waehlen/-linienzug-modus-waehlen) + Zurueck-Schleife im
  c:VarioFoerderer-Dispatcher
- Vario-Kurve/GF-Bogen-Erkennung am Kettenanfang: vfl-eingang-modus-bestimmen
  threaded durch vfl-vf-eingang-bauen/vfl-vf-einheit/vfl-vf-einheit-abschluss,
  inkl. Punkt-7-Winkel/Hoehen-Tabelle fuer reduzierten Eingang
- Modus 2: Lauf-Anfang/Lauf-Abschluss (offener Anfang/Ende, GF-Verteilung
  "alles Auslauf", Kletter-zu-kurz-Fallback) + Separator VOR/NACH bei
  GF-Geraden
- Systemischer Bug behoben: mehrere Wizard-Dialogfunktionen nutzten noch
  start_list/add_list (Dropdown) gegen laengst auf boxed_radio_column
  umgestellte DCL-Dialoge (vflw-gruppe-as/-gefaelle/-variokurve/
  -winkel-seite-impl, vflw-seg-linie-m2/-m3/-bogen-impl,
  vfl-glied-gf-bogen/-vario/-as-es-dialog)
- Zentraler Abbruch-Trigger in vfl-in-value/-value-p wiederhergestellt (ohne
  ihn wirkte der Zurueck/Abbrechen-Button in keinem Wizard-Dialog)
- vfl-frage-ist-endpunkt/-ist-kettenende als eigene Funktionen mit
  Wizard-Dialog extrahiert (vorher Konsolen-Duplikate ohne Dialog-Hookup)
- 3 vfs-vf-entry-Aufrufe mit falscher Argumentzahl gefixt (akute
  Absturz-Bugs in Modus 2/3)
- Tote Funktion vflw-gruppe-horizontal-impl entfernt (Tiles nicht mehr im
  DCL vorhanden)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-11 18:26:48 +02:00
m.stangl 41eea7fc01 [REFACTOR] VF-Cluster: Magic-Numbers auf *vfk-*-Konstanten umgestellt
vf_core/vf_standard/vf_etage/vf_linienzug referenzieren jetzt durchgaengig
die zentralen *vfk-*-Konstanten aus vf_konstanten.lsp statt rohe Winkel-/
Laengen-/Toleranz-Literale (3.0 Grad, 500/300mm Stationen/Separatoren,
1000/800mm Mindestlaengen, AS/ES-Fallback-Versaetze, Text-/Label-Masse).
Bereits ueber ssg-cfg-or config-gefuehrte Werte bleiben unangetastet
(Config bleibt dort die aktive Quelle). vf_etage-Bogenwinkel-Inkonsistenz
(fest verdrahtete Liste ohne Bezug zu *vfk-bogen-winkel*) behoben.
vf_konstanten.lsp-Kommentare auf den neuen, aktiven Status aktualisiert.
2026-08-29 17:10:05 +02:00
m.stangl bf0237666b [REFACTOR] VF-Linienzug: AS/ES-Winkel-Wertemenge zentral aus *vfk-as-es-winkel*
Die gueltige AS/ES-Winkel-Menge ("30"/"90") stand als Literal doppelt im
Glied-Schema. Jetzt einmalig als *vfk-as-es-winkel* in vf_konstanten.lsp,
Schema referenziert sie (mit Fallback in vf_linienzug).

BEWUSST bei STRING geblieben (nicht INT): AS/ES ist echt 2-wertig (keine
60-Grad-Bloecke), das Journal fuehrt AS/ES-Winkel als STR - eine Umstellung auf
INT haette Journal-Format + Alt-Block-Editier-Kompatibilitaet beruehrt (2
Cluster) fuer reine Konsistenz. Zentrale Konstante beseitigt die Streuung ohne
dieses Risiko (Entscheidung mit Nutzer abgestimmt).

Die index-basierten Dialog-Mappings (if gwinkel "1" -> "30"/"90") bleiben,
da sie an feste 2-Options-DCL-Layouts gebunden sind (keine Listen-Lookups).

Paren-Balance geprueft.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 12:51:09 +02:00
m.stangl 3a0caadbb5 [REFACTOR] VF-Linienzug: GF-Bogen/Vario-Kurve-Winkel zentral aus *vfk-gf-bogen-winkel*
Statt das '(30 60 90)-Literal an ~12 Stellen in vf_linienzug zu wiederholen
(Schema, schema-feld-pruefen, Live-Menue GF-Bogen + Vario-Kurve, Slice-Reader,
beide Edit-Dialoge), verweisen jetzt alle auf die EINMALIGE zentrale Definition
*vfk-gf-bogen-winkel* in vf_konstanten.lsp (war dort schon vorhanden, wurde aber
nirgends genutzt).

Kein Config-Eintrag (bewusst nicht in component_defaults.json): die Winkel sind
an die vorhandenen DWG-Bloecke gebunden, eine Config waere nur halb verdrahtet.
vf_konstanten ist zentrale Quelle; vf_linienzug hat einen Fallback, falls die
Datei nicht geladen wurde. Werte unveraendert (30/60/90), Journal/Blocknamen
kompatibel.

Paren-Balance geprueft.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 10:32:42 +02:00
m.stangl 9f5b30709a [REFACTOR] VF: Core-Pfad-Ermittlung zentralisiert (ssg-lisp-verzeichnis/-datei-pfad)
Der 3-stufige Lisp-Pfad-cond (DXFM_LISP -> *ssg-lisp-pfad* -> nil) war 6-fach
dupliziert. Neuer Helper ssg-lisp-verzeichnis/ssg-lisp-datei-pfad in ssg_core.lsp.

- vf_core.lsp (Submodul-Loader): nutzt Helper direkt (ssg_core hier geladen)
- vf_standard/vf_etage/vf_konstanten/VarioFoerderer: Helper mit Inline-Fallback
  (atoms-family-Guard), falls ssg_core beim isolierten Einzel-Laden fehlt
- vf_core.lsp ssg_core-Bootstrap (Z.40): bleibt inline (laedt ssg_core erst)

Reines Refactoring, identisches Verhalten. Paren-Balance geprueft.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 07:33:20 +02:00
m.stangl 308d49fc96 VF-Linienzug: baubare Hoehen-Vorschlaege (Ab/Auf) statt unveraenderter Ist-Hoehe, negative Restlaenge nach AS-Element abgefangen
- Hoehe-Prompt/Wizard-Dialog schlagen jetzt zwei tatsaechlich baubare
  Zielhoehen vor (Ab/Auf) statt der unveraenderten Kettenhoehe, die bei
  direkter Uebernahme immer als deltaH=0 abgelehnt wurde (Linie-GF,
  Linie-VF, automatische Linie, VF-Kette fortsetzen, Kettenende-Abschluss)
- Nach dem AS-Element-Einfuegen kann die real gemessene Restlaenge negativ
  werden (Klickpunkt zu nah); Linie-GF und automatische Linie pruefen das
  jetzt und brechen sauber ab statt eine entartete GF-Strecke zu bauen
- Debug-Log (Modus 1) protokolliert jetzt Erfolg/Misserfolg der
  Geometrieerzeugung inkl. der verwendeten Werte
- Neue Lisp/vf_konstanten.lsp: zentrale, dokumentierte Sammlung aller
  Laengen-/Winkel-Magic-Numbers aus dem VarioFoerderer-Cluster als
  Nachschlagewerk (Module selbst noch unveraendert)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-27 13:27:25 +02:00