Commit Graph

68 Commits

Author SHA1 Message Date
y.wang cccd362bba feat: VF-Hoehe je Segment (Sivas 4433-4437) + AS-Zufuehrungsachse bei 30 Grad
Zwei Themen, die dieselben Dateien beruehren und daher zusammen gehen.

1) VF_HOEHE_m - Hoehe je VF-Segment, Sivas-Merkmale 4433-4437

   Sivas erwartet je Streckengruppe bis zu fuenf Variofoerderer-Hoehen.
   Neues Block-Attribut VF_HOEHE_m: kommagetrennte Liste in Metern mit 3
   Nachkommastellen, Eintrag fuer Eintrag parallel zu L_VF_m/VF_WINKEL.

   Je Eintrag der Mittelwert aus KS_EIN und KS_AUS DES GERADEN VF-Abschnitts.
   Zwischen Umlenk- und Motorstation koennen mehrere Abschnitte liegen
   (auf/ab/horizontal), jeder bekommt einen eigenen Wert.

   SONDERFALL Standard/Etage: dort gibt es nur einen Motor und nur einen
   geraden Abschnitt - gemessen wird die GANZE Kette (AS-KS_EIN bis
   ES-KS_AUS, vf-vfhoehe-kette). Das ersetzt den Segmentwert; der Linienzug
   laeuft nicht durch vf-dialog-berechnen-einfuegen und behaelt seine Liste.

   WICHTIG - vollstaendige Erfassung: die VF-Segmente entstehen NICHT alle in
   vfs-vf-koerper. Horizontale Zwischenstuecke, das "schon flach"-Segment und
   die Modus-2/3-Fuellstuecke bauen direkt mit insert-inclined-scaled-block,
   die Kette-Merge-Rekonstruktion liest sie aus bestehenden Bloecken. Ein
   erster Fix nur in vfs-vf-koerper lieferte darum zu wenige Werte (realer
   Befund: L_VF_m hatte drei Eintraege, VF_HOEHE_m einen). Jetzt sind alle 14
   Stellen erfasst, die vfl-acc-vf-seg aufrufen - dafuer das Paar
   vf-vfhoehe-merke/-schliesse, das ohne lokale Variable auskommt.

   REGEL (im Code dokumentiert): Jede Stelle, die vfl-acc-vf-seg aufruft,
   MUSS auch eine Hoehe erfassen - sonst verschiebt sich die Liste gegen
   L_VF_m und im Export landet eine Hoehe beim falschen Foerderer.

   Formatierung ueber vf-meter-3: (rtos x 2 3) allein kuerzt je nach DIMZIN
   nachfolgende Nullen ("2.5" statt "2.500", "-1" statt "-1.000") - im
   Testlauf real aufgetreten.

   Attribut-Schema *strecke-attr-gruppe* (ssg_core.lsp) ergaenzt, sonst
   verschluckt ssg-attrib-set-on den neuen Tag stillschweigend.
   export_sivas.py verteilt die Liste auf VF_HOEHE_MERKMALE (4433-4437);
   ueberzaehlige Abschnitte werden weggelassen statt zusammengefasst, fehlende
   lassen das Merkmal ganz weg.

2) AS-Element 30 Grad: Zufuehrungsachse statt Seitenwahl

   Der Startpunkt einer Kette mit AS-Element ist geometrisch keine Position,
   sondern eine ACHSE: das AS sitzt an einer durchlaufenden Strecke und
   schleust daraus aus, seine KS_EIN-Achse muss darauf liegen. Bisher richtete
   vfl-insert-as-element das KS_AUS entlang der Kettenrichtung aus, wodurch
   das KS_EIN um den Blockschwenk verdreht stand - beim 90-Grad-Element kaum
   sichtbar, beim 30-Grad-Element deutlich.

   Beim 30-Grad-Element wird die Seitenauswahl im AS-Gruppendialog jetzt
   ausgegraut; stattdessen gibt ein zweiter Punkt die Zufuehrungsrichtung
   (der Startpunkt bleibt der Sitz des Elements). Die Seite folgt aus der Lage
   des naechsten Kettenpunkts zur Achse (vfl-seite-aus-lage). 90 Grad bleibt
   unveraendert bei der Seitenfrage.

   Der Dialog legt bei 30 Grad bewusst KEINE Seite mehr in die Pending-Queue -
   sonst zog die nachfolgende Punktfrage sie als vermeintlichen Punkt heraus
   und erschien gar nicht (realer Fehler beim ersten Test).

   Abwaertskompatibilitaet: aeltere 30-Grad-Ketten wurden noch MIT Seitenfrage
   gebaut. vfl-replay-peek-art sieht beim Replay nach, was tatsaechlich
   ansteht ("PT" = Achse, "STR" = Seite) - die Modus-Wahl selbst wird nicht
   journalisiert, weil sie daraus eindeutig rekonstruierbar ist.

Unit-Suite 687/687 gruen. VF-Hoehe in BricsCAD bestaetigt. Die AS-Achsenfrage
ist dort noch NICHT gelaufen, seit die Seitenauswahl ausgegraut wird.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-10-21 12:55:02 +02:00
y.wang 821b81135d fix: VF-Linienzug - ES-Fussabdruck laengs korrekt reservieren + Endpunkt per Ziellinie
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>
2026-10-14 09:09:40 +02:00
m.stangl 9a7907ab00 [CHANGE] VF Standard/Etage 3D-Linie-Eingabemodus per Dialog statt Konsole (Teil A der GUI-Umstellung)
Neuer Dialog vfc_eingabemodus (dcl/variofoerderer.dcl) + vfc-dialog-eingabemodus-waehlen (Lisp/vf_core.lsp), analog zum bestehenden vfc_typ-Muster: Radio-Buttons "3D-Linie auswaehlen" / "Werte manuell eingeben" ersetzen die fruehere getstring-Konsolenabfrage in vf-dialog-ablauf. Betrifft StandardVarioFoerderer3D und EtageVarioFoerderer3D (beide rufen denselben Ablauf).

Die 3D-Linie-Objektauswahl selbst (vfc-3dlinie-erfassen) bleibt bewusst Zeichnung/Konsole - eine Linie laesst sich nicht durch ein Formularfeld ersetzen. Alle daraus abgeleiteten Werte (deltaL/deltaH/hz/Einfuegehoehe) gehen als Prefill in den bereits bestehenden Basis-Dialog (variofoerderer_basis), der sie ueberschreibbar anzeigt - identisch zum "Werte manuell"-Pfad.

Rueckfall auf die alte Konsolenabfrage bleibt erhalten (GUI abgeschaltet, DXFM_LANG=en_GB), wie bei vfc_typ. doc/variofoerderer.md (Abschnitt 2, 8, Entscheidungsbaum) und CLAUDE.md entsprechend aktualisiert.

Manuell in BricsCAD getestet (StandardVarioFoerderer3D + EtageVarioFoerderer3D, beide Dialogzweige inkl. Abbruch) - laeuft.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-09 11:38:15 +02:00
m.stangl a670db839e [CHANGE] VarioFoerderer Standard/Etage: 3D-Linie-Eingabemodus laeuft jetzt ueber den bestehenden Basis-Dialog statt komplett interaktiv auf der Konsole
Die Linie wird weiterhin gepickt (vfc-3dlinie-erfassen, aus vf-eingabe-abfragen herausgezogen), liefert aber deltaL/deltaH/Richtung/Einfuegehoehe/Fahrtrichtung nur noch als Prefill fuer vfs-dialog-eingabe-basis - Seite/Motorseite/Darstellung/Geruest bleiben wie bisher ueber die GUI einstellbar. c:VarioFoerderer dispatcht Standard/Etage dadurch immer in vfs-standard-dialog-ablauf/vfe-etage-dialog-ablauf; der alte rein konsolenbasierte Fallback-Pfad (Schritte 3-11, vf-eingabe-abfragen) ist als toter Code entfernt. Dead-Code-Aufraeumung: 35 nur noch vom entfernten Pfad genutzte Sprachschluessel aus lang/de_DE.json + lang/en_GB.json entfernt (Paritaet geprueft).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-08 16:01:56 +02:00
m.stangl 5b873838c1 Merge remote-tracking branch 'origin/master'
# Conflicts:
#	dcl/variofoerderer.dcl
2026-10-08 12:47:05 +02:00
m.stangl 823dc6728d [CHANGE] Streckengruppe-Menue in Werte-manuell/Zielhoehe/Stueckweise aufgeteilt, QC-Linien unter Gefaellestrecke verschoben, Linienzug-Wizard "Naechstes Element" neu sortiert (GF vor VF) mit eigenem Abschliessen-Knopf statt Kettenende-Radio
Lisp/vf_core.lsp: fuenf eigene Menue-Wrapper (LinienzugVarioFoerdererManuell/-Zielhoehe/-Stueckweise, QcLinieMitGf/-UForm) ersetzen den alten interaktiven Modus-Dialog; vfc-dialog-linienzug-modus-waehlen entfaellt.
dcl/vf_linienzug_wizard.dcl + Lisp/vf_linienzug.lsp: "Neue Linie BIS Kettenende" ist kein Radio mehr, sondern eigener Button "OK und Abschliessen" neben "Ok Weiter"; GF-Optionen stehen vor VF-Optionen.
Menue (SSG_LIB.mnu/.cui), lang/*.json, doc/kommandos.md, doc/lisp_methods.md, doc/faq.md nachgezogen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-08 12:44:36 +02:00
y.wang 16a15bb83b feat: VF-Werteingabe Radio-Dialoge + Startpunkt-Dialog (Standard+Etage)
Dropdown-Dialoge der Standard-/Etage-Werteingabe durch Radio-Buttons
ersetzt (vfs-dialog-eingabe-basis-radio/vfs-dialog-winkel-verteilung-
radio in vf_standard.lsp), da sich Radio-Labels nach new_dialog nicht
per set_tile aendern lassen - die DCL wird dafuer bei jedem Aufruf
frisch zur Laufzeit geschrieben (neue Kernel-Helfer ssg-dcl-temp-
schreiben/ssg-dcl-label-escape in ssg_core.lsp) und dadurch
sprachunabhaengig. Popup-Varianten bleiben als Fallback erhalten,
falls das Schreiben/Laden der Temp-DCL-Datei scheitert.

Startpunkt der Anlage wird jetzt ebenfalls per Dialog gepickt
(vfc-dialog-startpunkt-waehlen, neue vfc_startpunkt-Dialogdefinition
in dcl/variofoerderer.dcl) statt per reinem Konsolen-getpoint - analog
zum bestehenden Punktwahl-Muster im Linienzug-Wizard. Zusaetzlich:
Einfuegehoehe der 3D-Linien-Eingabe ist jetzt explizit abfragbar
(Vorschlag = Z des Linien-Startpunkts), ueberschreibt nur die absolute
Hoehe, deltaH/Steigung bleiben unveraendert aus der Linie abgeleitet.

Gemeinsam mit vf_standard.lsp nach Merge-Konflikt zusammengefuehrt:
der Kollege hatte an derselben Stelle unabhaengig vfs-edit-basis-lesen
ergaenzt (gemeinsame Attribut-Leseroutine fuer Standard- UND
Etage-Edit) - beide Ergaenzungen sind inhaltlich unabhaengig und
bleiben nebeneinander bestehen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-08 09:55:56 +02:00
s.hensch 4e39c64ec1 [ADD] Geruest: Teile-DWGs (data/geruest/<artnr>.dwg) als Geometrie im GR_-Block; TEILEFARBE als Liste parallel zu ARTINR (Flag farbig in geruest.json), Sivas-Merkmal 108 aus cfg [Sivas]; Menue-Befehle GERUEST_SAEULEN/_ROHRABHAENGER/_WANDBEFESTIGUNG
[FIX] Sivas-Export las nicht existierendes Attribut FARBE
2026-09-29 12:07:00 +02:00
s.ayadi 618ff3d86c sepliste: Bauteil-IDs eintragen, AS/ES ueber dauerhaften Marker sichtbar machen
Stufe 1 (LISP-Export-Pfad): export_raw.json enthaelt jetzt fuer jeden
sepliste-Eintrag (AS/SEP/ES) einer VF_n/GF_n-Kette die ID des realen
Bauteils, das ihn vertritt.

- csv:sep-proxies-erzeugen (Separatoren) und die neuen AS/ES-Marker teilen
  sich csv:nested-welt-records/csv:block-einfuegen-welt zur Platzierung.
- csv:sepliste-paare ordnet sepliste-Eintraege ihrem Bauteil exklusiv nach
  Abstand zu (kuerzester zuerst, dann verbraucht) statt "jeder Eintrag
  nimmt sich das naechste" - ein einzelner fehlerhafter Koordinatenwert
  (bekannter Bug: gespiegeltes x bei lfdnr=2) verschiebt dadurch keine
  andere Zuordnung mehr.
- Neu: ZZ_ASES_MARKER - ein kleines Rechteck an jedem AS/ES-Kettenende,
  das nach dem Export STEHEN BLEIBT (anders als die temporaeren
  Separator-Kopien). Macht das sonst unsichtbare, in der Wrapper-
  Blockdefinition verpackte Kettenende in BricsCAD sichtbar/anklickbar
  und traegt seine ID unsichtbar am Attribut ID - dadurch behaelt ein
  AS/ES seine TeileId ueber Exportlaeufe hinweg. Wird bei jedem Export
  neu aufgebaut (Lage folgt der Kette), Wiederfund ueber ZUORDNUNG+TYP+
  LFDNR, verwaiste Marker werden entfernt.

In BricsCAD verifiziert (5 HundM05-Ketten, zwei Exportlaeufe: gleiche
Marker-IDs, korrekte sepliste-"id"-Felder). Dabei einen realen Bug
gefunden und behoben: die Blockdefinition des Markers uebernahm ueber
einen ungefilterten entnext-Walk versehentlich auch die Attribute des
zuletzt eingefuegten Blocks (VF_5 verlor dadurch alle Attribute inkl.
ID) - jetzt auf LWPOLYLINE/ATTDEF gefiltert.

9 neue zeichnungsfreie Unit-Tests (csv:sepliste-paare/*, csv:asmark-
finden/*, csv:proxy-typ/*), 4 neue de/en-Textschluessel (Paritaet
geprueft). bin\run_tests.bat --lisp: 257/257 bestanden.

Noch nicht enthalten (Stufe 2, Python): map_separator_kette_items nutzt
das neue "id"-Feld noch nicht, build_strecke_schleus_items synthetisiert
AS/ES-Zeilen weiterhin selbst statt die exportierten zu lesen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-22 13:09:05 +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
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 3698c8982c Sepliste-XDATA fuer Separator/AS/ES-Reihenfolge + Unit-Tests, makunbound-Fix
Sammelt beim Bau von VF_n/GF_n-Ketten die Baureihenfolge der Separator-/
AS-/ES-Sub-Bloecke vor dem Block-Sweep und schreibt sie als XDATA auf den
fertigen Wrapper (ssg_ks_insert.lsp); export.lsp liest sie fuer das neue
"sepliste"-Feld im CSV-Export, export_neighbors.py nutzt es als Fallback
zur BBox-Kollisionspruefung. Dazu Unit-Tests fuer die reinen Serialisierungs-
funktionen (Chunking, Roundtrip) in test_unit.lsp.

Ausserdem: makunbound (existiert nicht in BricsCAD-AutoLISP) aus
test_run_all.lsp entfernt - verursachte Laufzeitfehler bei
SSG_RUN_ALL_TESTS_EXPORT/_OFFEN.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-09 20:36:42 +02:00
m.stangl 9670173d4b Menüs für Varioförderer umgebaut. Weniger interaktive Abfragen, direkter Aufruf durch Menü 2026-09-07 11:05:18 +02:00
s.ayadi 29b7bf1a10 [FIX] Weltposition verpackter Separator_SP-Symbole bei gekippten Ketten
ssg-collect-nested-inserts-rel/csv:sep-proxies-erzeugen nahmen bislang eine
reine Z-Drehung ohne OCS-/Extrusionsrichtung an. Fuer die um den Gefaelle-/
Neigungswinkel gekippte Staustrecke/Separator-Kette (Gefaellestrecke.lsp,
vf_standard.lsp) ist das falsch: die eingebettete Separator_SP-Weltposition
blieb dadurch unabhaengig von der gewaehlten Fahrtrichtung eingefroren.

Fix generalisiert die Rotationskomposition auf volle 3x3-Matrizen (Arbitrary
Axis Algorithm fuer die Extrusion, neue mat3-*-Helfer in ssg_core.lsp statt
vf_core.lsp, da ssg_core immer vor jedem Feature-Modul geladen ist). Fuer
flache Elemente (Extrusion (0 0 1)) reduziert sich das exakt auf die alte
reine Z-Drehung - kein Verhaltensunterschied dort.

Verifiziert per Python/ezdxf-Nachbau des neuen Algorithmus gegen die drei
real gebauten Testzeichnungen (data/gf.dxf, data/gf_north.dxf,
data/gf_south.dxf): liefert jetzt fuer alle drei Fahrtrichtungen exakt die
unabhaengig berechnete Grundwahrheit statt eines eingefrorenen Werts.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-04 12:42:10 +02:00
s.hensch 15ec6c0504 [ADD] Layerdefinitionen und Farben durch layer.cfg für zusammengesetzte Blöcke wie Gefällestrecke oder Varioförderer werden beim Zusammenbau der Baugruppen in den Skripten verwendet; Ebenfalls als Fallback für Blöcke möglich, die kein Attribut LAYER besitzen. 2026-09-04 09:01:12 +02:00
s.ayadi 428f1ced70 [FEAT] VF-Linienzug aus Eingabedaten bauen (Stufe 1: Spec -> Journal -> Replay)
Stufe 1 des Fahrplans in doc/TODO-plan-vf-interactive.md, fertig fuer
Modus 1. Eine SPEC beschreibt eine Kette in Domaenenwerten ("links",
"winkel", "aussen", ja/nein) statt in Menue-Codes; vsp-journal uebersetzt sie
in ein Eingabe-Journal, vsp-bau-aus-spec spielt es per
vfl-journal-replay-start durch den UNVERAENDERTEN vf-linienzug-modus. Der
fertige Block traegt damit dasselbe SSG_VF_EDIT-Journal wie eine handgebaute
Kette und bleibt per Doppelklick editier- und 2D/3D-konvertierbar - kein
Journal-Konsument muss etwas von Specs wissen.

CAD-Lauf VF_SPEC_BAU: 5 OK, 0 Fehler. Je Kette status "executed",
prompts 0 (keine Live-Eingabe erreicht), eingaben_offen 0, keine
Spec-Fehler, keine Bau-Meldungen, glieder_ist == glieder_soll,
Einfuegepunkt gleich dem Kettenstart der Spec.

Neu:
- Lisp/vf_spec.lsp: Code-Tabellen, Emitter vsp-journal, Validierung
  vsp-pruefen, flacher JSON-Loader, Headless-Rahmen vsp-headless-an/-aus,
  Ergebnis-Record, vsp-bau-aus-spec/-liste, c:VF_SPEC_BAU. Von vf_core.lsp
  NACH vf_linienzug.lsp geladen - damit sind beide Ladewege abgedeckt (Menue
  und der .scr-Loader), das MNL bleibt unveraendert.
- lib/vf_spec_export.py: derselbe Emitter in Python PLUS die Umkehrung
  (spec_aus_journal), erzeugt die Spec-Testdaten.
- tests/testdata/vf_spec_hundm05.json: die 5 echten Ketten als Spec,
  erzeugt statt handgeschrieben.
- tests/test_vf_spec.lsp (C:TEST_VF_SPEC, in alltests.json): 7 Faelle je
  Glied-Typ, 7 Validierungsfaelle, Gruppieren, und die 5 echten Ketten gegen
  ihr aufgezeichnetes Journal.
- tests/test_vf_spec.py: 36 Tests (Rundlauf, Spec-Daten, Validierung,
  Erwartungswert-Abgleich, Ergebnisse von VF_SPEC_BAU).

Drei Regeln, die der Uebersetzer besitzen muss - jede wuerde sonst die ganze
Replay-Queue verschieben:
- Der Menue-Code haengt am Frame: erste Sektion 4 Optionen (kein GF-Bogen,
  es gibt noch keine Richtung), jede spaetere 5.
- hz steht genau EINMAL im Journal, beim ersten Segment (vfl-in-abstand
  journalisiert die Richtung nur bei freier Richtungswahl).
- Nur ein HORIZONTALER Erstkoerper einer VF-Einheit stellt die Separator-/
  Endpunktfragen vorab (winkel1=0 laeuft durch vfl-baue-horizontal-koerper);
  ein gewinkelter wird ohne jede Frage gebaut.

Wie die Richtigkeit belegt ist - drei Implementierungen derselben Grammatik,
die einander pruefen:
- Rundlauf gegen echte Daten: journal_aus_spec(spec_aus_journal(tok)) == tok
  fuer alle 5 HundM-Ketten, tokenweise numerisch verglichen. Damit ist
  bewiesen, dass die Spec das Journal verlustfrei abbildet.
- Der Weg, den LISP nimmt (flaches JSON -> Spec -> Journal), ergibt separat
  geprueft dieselben Journale wie das aufgezeichnete Protokoll.
- Der unabhaengige Dekoder aus lib/vf_journal_export.py verdaut alle 7
  synthetischen Emitter-Ausgaben restlos, auch die zwei Zweige, die in den
  echten Daten fehlen (Linie-VF, gewinkelter Erstkoerper).
- Die Erwartungswerte im LISP-Test kommen aus dem geprueften Python-Emitter;
  TestLispErwartungen liest sie zurueck und vergleicht erneut. Ohne das
  koennte ein Uebertragungsfehler einen falschen Erwartungswert
  festschreiben und der CAD-Lauf waere gruen, obwohl der Emitter falsch
  liegt.

Abweichungen von der Planung (Begruendungen in doc/TODO-plan-vf-interactive.md
Abschnitt 4.6): vsp-pruefen ruft den Emitter statt eine zweite Regelmenge zu
pflegen; das vollstaendige Journal steht nicht im Record (statt dessen
glieder_soll/glieder_ist als Desync-Detektor); Zusatzfeld segment_typ am
Glied "Linie", weil dort vfl-segment-entscheidung selbst zwischen GF und VF
waehlt; vf_ende-Werte "automatisch"/"zielpunkt-ohne-es" fuer die Faelle ohne
Frage; Praefix vsp- statt vfs- (das gehoert vf_standard.lsp).

Zusaetzlich:
- tests/test_vf_headless_statisch.py prueft jetzt auch, dass
  Lisp/vf_spec.lsp UEBERHAUPT keine Eingabe-/Dialogfunktion aufruft - beim
  Daten-Pfad ist die Null die Vorgabe.
- tests/testdata/mubea.json: die drei einzeln eingefuegten S-LP-Separatoren
  entfernt (Fortsetzung von 699744e - die Separatoren stecken jetzt in den
  Staustreckenbloecken).

Noch offen: die Uebersetzer fuer Modus 2 und 3. Modus 2 braucht laut
Fahrplan erst 2-3 echte "linienzug2"-Journale als Referenz -
tests/testdata/hundm05.json enthaelt ausschliesslich Modus-1-Ketten.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-03 10:44:38 +02:00
s.ayadi ba01455d52 [FEAT] VF-Linienzug ohne GUI/Konsole baubar (Stufe 0) + hundm05-Testfall
Ziel: eine VF_n-Kette soll aus einem Stapel Eingabedaten gebaut werden
koennen - ohne Dialog, ohne Konsolenfrage. Fahrplan und Begruendungen in
doc/TODO-plan-vf-interactive.md. Alle Aenderungen sind No-Ops, solange
*ssg-gui-aus* und *vfl-headless* nil sind.

Produktion (Lisp/vf_linienzug.lsp, Lisp/vf_core.lsp):
- vfl-journal-reset im Dispatcher VOR die Modus-cond gezogen. Bisher nur im
  Modus-1-Zweig: ein frischer Modus-2-Lauf erbte das Journal des Vorlaufs und
  schrieb es in die XDATA, ein spaeterer Doppelklick spielte fremde Eingaben
  vor.
- Lokale Variable "member" in vf-linienzug-modus2 umbenannt. Sie verdeckte im
  selben Scope das Builtin member, das weiter unten gebraucht wird - jedes
  Kletterer-Segment waere in "bad function" gelaufen.
- Neu vfl-meldung: sammelt den Text nach *vfl-meldungen* + dbgmsg und zeigt
  ihn nur bei erlaubter GUI modal, sonst per princ. Die 12 Bau-Pfad-alerts
  darauf umgestellt; ein Alert blockierte sonst jeden Batch-Lauf, und sein
  Text ist die einzige Auskunft, WELCHE Sektion abgewiesen wurde. Die reinen
  Interaktiv-Alerts (fehlendes DCL, "nicht editierbar", "kein Journal")
  bleiben alert.
- Neu *vfl-headless* (+ vfl-headless-p/-abbruch/-notausgang/-ort, Diagnose
  *vfl-headless-fehler*, optionaler Antwort-Hook *vfl-headless-antwort-fn*):
  eine erschoepfte Replay-Queue ist damit ein harter Abbruch MIT Fundstelle
  (Art der Eingabe, Glied- und Eingabe-Nummer) statt eines stillen Rueckfalls
  auf Live-Eingabe. Eingebaut in vfl-in-value, vfl-in-value-p,
  vfl-in-selection und vfl-in-abstand.
- vfl-journal-reset loescht Meldungen und Diagnose mit (gehoeren zum Lauf);
  vfl-view-refresh ueberspringt headless _PLAN/_ZOOM.

Testfall HundM05 (5 echte Ketten aus data/polylines.dxf):
- tests/testdata/hundm05.json neu erzeugt aus den XDATA-Journalen der
  VF_n-Bloecke (lib/vf_journal_export.py) - flach, weil ssg-load-json
  zeilenweise liest. Die drei kopierten Ketten bekommen ihren echten
  Einfuegepunkt, nicht das veraltete HOEHE_VON-Attribut.
- tests/test_hundm05.lsp arbeitet jetzt per Journal-Replay statt mit
  Eingabe-Mocks: ein echtes Journal fuehrt die geerbte Fahrtrichtung nicht mit
  (vfl-in-abstand journalisiert hz nur beim ersten Segment), ein Mock kann sie
  also nicht kennen. Schaltet *vfl-headless* ein und schreibt prompts,
  headless_fehler und meldungen ins Ergebnis-JSON.
- Kettenschleife fangt je Kette: ein Fehler NACH dem Bau nimmt nicht mehr die
  restlichen Ketten mit.
- entprev gibt es in AutoLISP nicht (nur entnext/entlast) - die Suche nach dem
  fertigen Block laeuft vorwaerts ab dem Zeichnungsstand vor dem Bau. Dieselbe
  Falle in tests/test_mubea.lsp mitbehoben; sie schlug dort nie zu, weil
  entlast immer sofort traf.

Absicherung ohne CAD:
- tests/test_vf_headless_statisch.py: eingechecktes Inventar aller
  alert/get*/ssget/new_dialog-Fundstellen je Funktion (ein neues getreal in
  einer Bau-Funktion faellt auf, auch wenn sein Zweig im Test nie erreicht
  wird), Praesenz des Riegels in allen vier Wrappern, Diagnose-Reset und die
  Reset-Reihenfolge im Dispatcher. Dazu ein Waechter gegen erfundene
  AutoLISP-Funktionen (entprev u.a.) - diese Fehlerklasse kostet sonst jedes
  Mal einen CAD-Lauf.
- tests/test_hundm05.py prueft zusaetzlich prompts == 0, keine
  Headless-Abbrueche und keine Bau-Meldungen.

tests/alltests.json: hundm05-Zeile laedt VarioFoerderer (nicht KreiselInsert)
und bleibt bis zu einem gruenen CAD-Lauf abgeschaltet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-03 10:14:31 +02:00
m.stangl ddb5dfa0f5 WINKEL_AS und WINKEL_ES hinzugefügt 2026-08-31 13:53:41 +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 1e7a4d8620 [REFACTOR] VF: L_GF/L_VF-Solve aus Winkelberechnung zentralisiert (vf-winkel-solve)
Der L_GF/L_VF-Solve-Block (aus A/B-Restbudget) war in berechne-alle-winkel
(Standard) und berechne-winkel-etage byte-identisch. Als vf-winkel-solve
(winkel richtung A B sinα cosEff sinEff sin3 cos3) -> (winkel L_GF L_VF gueltig)
nach vf_core gezogen; beide Winkelberechnungen nutzen ihn jetzt.

Bewusst NICHT vereinheitlicht: die A/B-Berechnung (Etage hat zusaetzliche
2*schraeg-/2*gef-/2*feste-Terme, Standard nutzt feste-hz) und die Ergebnis-
tabelle (unterschiedliche Message-Keys/Arg-Form) - beides birgt Geometrie-/
Ausgaberisiko fuer geringen Zeilengewinn. Der identische, geometrie-kritische
Solve ist der wertvolle Teil.

test_foerderer.py (Winkel-Set, Monotonie, L_GF/L_VF>0) validiert das direkt.
Paren-Balance geprueft.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 10:17:40 +02:00
m.stangl d00e1a600b [REFACTOR] VF: Standard/Etage-Dialog-Ablauf vereint (vf-dialog-ablauf)
vfs-standard-dialog-ablauf/-berechnen-einfuegen und vfe-etage-dialog-ablauf/
-berechnen-einfuegen waren strukturell 1:1-Kopien (~200 Zeilen), Unterschiede
nur: Berechnungs-/Einfuege-Funktion, XDATA-Marker, horizontale Zwischenstrecke.

Neu in vf_core:
- vf-registry-berechne-fn/-einfuege-fn: Registry-Accessoren (berechne-fn/
  einfuege-fn kommen ohnehin aus *vf-typ-registry* pro Typ)
- vf-dialog-berechnen-einfuegen (typ ... horizontal-p): gemeinsamer Ablauf,
  horizontal-p T=Standard (mit Zwischenstrecke), nil=Etage
- vf-dialog-ablauf (typ vf-nummer horizontal-p): gemeinsame Neuanlage

Die vfs-*/vfe-*-Namen bleiben als duenne Wrapper (Doppelklick-Edit-Dispatch +
Gefaellestrecke-Aufruf vfs-standard-dialog-berechnen-einfuegen unveraendert,
gleiche Arity/Rueckgabe). XDATA-Schreiben identisch (vfs-xdata-schreiben war
schon (vf-edit-xdata-schreiben ent "standard" hz)).

-45 Zeilen netto, eine gemeinsame Implementierung. Paren-Balance geprueft.
Beruehrt Bau -> BricsCAD-Test Standard+Etage (Neuanlage + Doppelklick-Edit).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 10:14:21 +02:00
m.stangl 3d5ae9a879 [FIX] vf-frage-element-winkel: GUI-Aus-Schalter respektieren
vf-frage-element-winkel (AS/ES-Winkel 30/90) pruefte *vfl-wizard-mode* direkt
und oeffnete den vflw-wahl-Dialog auch bei abgeschalteter GUI - dadurch kam im
automatischen TEST_LINIENZUG trotz (ssg-gui-aus) die AS-Element-Winkel-Abfrage
als Dialog hoch. Jetzt zusaetzlich (ssg-gui-p)-Guard wie in vfl-wizard-mode-p:
bei GUI-aus faellt die Abfrage auf getstring (Mock-Queue im Test).

War die letzte ungeguardete Wizard-Dialog-Eintrittsstelle.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 09:51:19 +02:00
m.stangl 80804a321a [REFACTOR] KS-Extraktion + Einfuegeprimitiven zentral in ssg_ks_insert.lsp
Neun Funktionen waren doppelt gepflegt in vf_core.lsp (unbedingt) UND
Gefaellestrecke.lsp (geguardet 'Fallback wenn vf_core nicht geladen'). Da
vf_core im MNL immer nach Gefaellestrecke laedt, gewann bisher stillschweigend
die vf_core-Version - die Gefaellestrecke-Kopien waren de facto tot und wichen
leicht ab. Jetzt EINE Quelle:

  ssg_ks_insert.lsp: vec-length, ks-line-axis, ks-normalize-name, ks-relativize,
  ks-absolutize, ensure-block-loaded, extract-ks-from-block[-raw],
  insert-block-by-ks, insert-inclined-scaled-block, insert-rotated-block-with-ks

- Kanonische vf_core-Variante uebernommen (inkl. Null-Check, ssg-ils-block-auf-ebene,
  hz-Guard, Statusmeldungen). Gefaellestrecke erhaelt dadurch dieselbe Behandlung
  wie im MNL-Fluss ohnehin schon aktiv.
- Cache vereinheitlicht auf *ks-cache* (guarded init im Shared-File);
  *gf-ks-cache* entfaellt.
- MNL laedt ssg_ks_insert als Core-Modul VOR Gefaellestrecke/VarioFoerderer.
- vf_core + Gefaellestrecke: guarded Nachlade-Load fuer isoliertes Test/Dev-Laden.

Paren-Balance geprueft; jede der 9 Funktionen jetzt genau 1x definiert.
Beruehrt Block-Platzierung -> BricsCAD-Test Standard/Etage/Linienzug/Gefaelle
(2D+3D) noetig.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 08:37:35 +02:00
m.stangl aa71d463cb [REFACTOR] Rz(hz)*Ry(vert)-Rotationsmatrix zentralisiert (ssg-rot-matrix-zy)
Die 4x4-Matrix Rz(hz)*Ry(vert) stand woertlich 11x: vf_core (2x), vf_etage (4x),
Gefaellestrecke (4x), TEFInsert (1x). Neuer dependency-freier Helper
ssg-rot-matrix-zy in ssg_core.lsp (immer zuerst geladen), damit alle drei
Cluster ihn ohne Cross-Modul-Kopplung teilen.

- vf-rot-matrix bleibt als duenner Alias in vf_core (VF-Aufrufstellen unveraendert)
- Reine 2D-Rz-Matrizen (insert-block-by-ks, nur horizontal) bleiben unangetastet
  (andere Form, kein Vertikalanteil)

Werte identisch - reine Extraktion. Paren-Balance geprueft.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 07:55:00 +02:00
m.stangl 012c5da7f9 [REFACTOR] VF: 10-Feld-Eingabe-Entpackblock zentralisiert
Der identische (setq deltaL (nth 0 eingabe) ...)-Block mit 10 Feldern stand 4x
(vf_standard: vfs-standard-dialog-ablauf + c:VARIOFOERDERER_EDIT, vf_etage:
vfe-etage-dialog-ablauf + vfe-edit-ent).

Neu in vf_core.lsp: *vf-basis-eingabe-felder* (zentrale Feldreihenfolge) +
vf-basis-eingabe-entpacken (set 'sym wert auf die dyn.-skopten Aufrufer-Locals).
Alle 4 Aufrufer deklarieren die 10 Namen weiterhin in ihrer /-Liste.

Reines Refactoring, identisches Verhalten. Paren-Balance geprueft.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-29 07:39:39 +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
m.stangl e3dbaceb24 Wizard mit Oberflächenstückwerk für den Mode 3 für den VF gebaut 2026-08-26 11:33:19 +02:00
m.stangl d7cb17f53f vf_*.lsp: verbleibende deutsche Meldungen auf ssg-text/ssg-textf umgestellt
Betrifft VarioFoerderer-Kern, Standard-/Etage-Aufbau und Linienzug (inkl.
altem Vorwaerts-Nachbau-Modus und Vario_Kette_Merge-Diagnose). Neue Keys in
lang/de_DE.json und lang/en_GB.json ergaenzt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-25 23:34:32 +02:00
m.stangl 82ce795b53 Linienzug: Abbruch wickelt Teil-Geometrie statt sie zu loeschen; Editieren per DCL-Dialog
Abbruch (ESC) im Linienzug-Baumodus loescht die bereits eingefuegte
Geometrie nicht mehr, sondern wickelt sie wie ein fertiger Bau zu einem
VF_n-Block und schreibt das volle Eingabe-Journal als XDATA drauf
(vfl-modus-abbruch-sichern, ersetzt das bisherige Loesch-Rollback). Die
Teil-Kette bleibt damit stehen und ist sofort per Doppelklick weiter
editierbar/fortsetzbar - unabhaengig davon, ob der Abbruch beim frischen
Bauen oder mitten in einem Editier-Neuaufbau passiert. Der bisherige
Menuepunkt "Letzten Abbruch fortsetzen" (Session-Variable) entfaellt
dadurch ersatzlos.

vfl-edit-ent (Doppelklick-Editieren) fragt die Sektion, auf die
zurueckgesetzt werden soll, jetzt per neuem DCL-Dialog ab
(dcl/vfl_edit.dcl, vfl-dlg-position: Combobox 1..N + OK/Abbrechen) statt
per Text-Prompt. Vorbelegung auf die letzte Sektion, damit Doppelklick +
sofort OK einen abgebrochenen Bau nahtlos fortsetzt.

Die *error*-Handler-Installation wandert vor den allerersten Prompt
(vorher: nach Startpunkt/AS-Frage), damit ein ESC in diesem Fenster nicht
mehr auf den ungeschuetzten vorherigen Handler faellt. Das Wickeln im
Abbruch-Pfad ist per vl-catch-all-apply abgesichert, da vfl-block-erstellen
intern einen BKS-Wechsel per (command "_.UCS" ...) macht.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-25 22:06:17 +02:00
m.stangl 236808f4dc Varioförderer Aufbau enthält jetzt einen Historien Stack. Beim Abbruch können alle Elemente wiederhergestellt werden und dann einfach weiter gebaut. 2026-08-25 16:09:22 +02:00
m.stangl 7f42ac2701 Etagenförderer auch editierbar gemacht. 2026-08-03 16:25:44 +02:00
s.hensch 2d6fab2aa9 [FIX] Koordinatensysteme Blocknamen vereinheitlicht bzw korrigiert: KSYS_EIN->KS_EIN, KSYS_AUS->KS_AUS 2026-07-28 12:05:09 +02:00
y.wang cdc33230e3 Merge remote-tracking branch 'origin/master'
# Conflicts:
#	Lisp/Gefaellestrecke.lsp
#	Lisp/ssg_core.lsp
#	Lisp/vf_core.lsp
2026-07-24 13:38:01 +02:00
y.wang d21f0acb4e feat: ILS-Bloecke ueber eindeutige 2D/3D-Namen laden + Auto-Layer
Zentrale Namensaufloesung (ssg-ils-datei-und-name, dual-schema: neu data/ils/<name>_<dim>.dwg mit eindeutigem In-Zeichnungs-Namen, alt Unterordner als Fallback). ensure-block-loaded liefert den aufgeloesten Namen; die insert-Helfer weisen blockname neu zu und setzen die INSERT-Referenz automatisch auf die eigene Ebene des Blocks (ssg-ils-block-auf-ebene, legt sie bei Bedarf an).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-24 13:31:03 +02:00
s.hensch b16c2e0fa1 [CHANGE] Verzeichnisse ILS 2d und 3d zusammengeführt und Funktionen entsprechend angepasst; TODO: Vario auf/ab Bögen schalten noch nicht korrekt zwischen 2d und 3d hin und her; TODO: Omniflo Verzeichnisse 2d/3d entsprechend genau so zusammenführen 2026-07-24 13:00:33 +02:00
y.wang 60c20519a0 Merge: Konflikt im VF/GF-Edit-Prefill aufgeloest
Eingehender Branch setzt geruest-einzelmodul-Default auf "1"; lokal kamen dim- und motorseite-Vorbelegung hinzu. Aufloesung: beide lokalen Zusaetze behalten und den neuen Default "1" uebernommen (Gefaellestrecke.lsp, vf_standard.lsp).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-24 08:23:04 +02:00
y.wang 8e5f197be0 Motorseite (links/rechts) fuer Motor-/Umlenkstation im VF-Dialog waehlbar (Override vf-motorseite, MOTORSEITE-Attribut, Edit/Batch erhalten die Seite) 2026-07-24 08:17:03 +02:00
m.stangl 258608b77f Export: Gefällestrecke-Höhe, Gerüst-Defaults, Omniflo-Komponenten-Split
- Entfernt "Hoehe oben"/"Hoehe unten" aus Gefällestrecke JSON-Export
- "Hoehe in m" kommt jetzt konsistent aus MONTAGEHOEHE_m bei Kreisel/Variofoerderer/Gefällestrecke
- Setzt "Geruest fuer Einzelmodul" auf Default True (statt False) bei Kreisel, Eckrad, Variofoerderer, Gefällestrecke
  - Eckrad-Abfrage: Default = Yes, Logik korrigiert (war invertiert)
- JSON-Key-Reihenfolge optimiert:
  - Variofoerderer/ILS 2.0 Strecke: "Hoehe in m" zuerst
  - Gefällestrecke/ILS 2.0 Gefällestrecke: "Hoehe in m" und "Typ" zuerst
  - Kreisel: "Hoehe in m" zuerst
- Omniflo-Komponenten-Split: Teile mit "0_B"-Präfix werden als separate CSV-Zeilen ausgegeben
  - Multi-Komponenten-Sivasnr (z.B. "834372002+0_BG090090") splitten
  - IDs werden mit .t1, .t2, etc. ergänzt
  - 0_B-Komponenten als "TEF Bogen"/"TEF Weiche" klassifiziert

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-07-23 15:26:51 +02:00
y.wang 9d9b9a9172 Merge Geruest-Feature mit 2D/3D-Umschaltung zusammengefuehrt
Konflikte in Gefaellestrecke.lsp und vf_standard.lsp aufgeloest - beide Features behalten. Dialog-Rueckgaben: dim vor den Geruest-Werten. Modus-1 (c:GEFAELLESTRECKE) und die Batch-Konverter (gf-/vf-konvertiere-ent) an die um Geruest-Parameter erweiterten Signaturen (gf-rebuild, gefaellestrecke-einfuegen, vf-block-erstellen) angepasst.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 14:28:29 +02:00
y.wang 39a4656f38 2D/3D-Umschaltung pro GF/VF-Block (Dialog-Auswahl + Auto-Erkennung via XDATA) und Batch Alle auf 2D/3D 2026-07-23 14:01:52 +02:00
m.stangl 6396111777 Geruest fuer Einzelmodul + Geruestoption bei Foerderer, Gefaellestrecke und Eckrad ergaenzt
Kreisel hatte GERUEST_EINZELMODUL bereits; ergaenzt um die neue Combobox
GERUEST_TYP (IPE-Geruest abgestuft / Obergeruest oben / Schoenenberger
Geruest / nur Doppelrohrtraeger, Default Schoenenberger Geruest) im
KreiselEdit-Dialog. VarioFoerderer (Standard-Dialog) und Gefaellestrecke
(Modus 1) erhalten beide Attribute neu in ihren DCL-Dialogen inkl.
Edit-Vorbelegung. ILS_Eckrad (kein Dialog vorhanden) fragt beide Werte
per Kommandozeilen-Menue ab. Konsolen-only-Pfade ohne Dialog (VF
Etage/Linienzug, GF Linienzug/3D-Objekte) bleiben auf Schema-Default,
analog zum bisherigen Kreisel-Verhalten.

Gemeinsame Optionsliste/Helper (*ssg-geruest-optionen*,
ssg-geruest-typ-to-idx/idx-to-typ, ssg-ask-geruest-typ) in ssg_core.lsp
war bereits durch einen parallelen Commit (120e26a) mit eingeflossen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-23 10:37:22 +02:00
y.wang fe2ad9cb32 vf-next-number ueberspringt bestehende Block-Definitionen (verhindert sporadischen VF-Bau-Fehlschlag)
Parallel-VF selbstkorrigierend auf GF-AS-KS_EIN ausrichten + vf-next-number gegen Namenskollision haertenm, Debug-Ausgaben entfernt.
2026-07-23 09:07:27 +02:00
m.stangl bb92b8ef69 Artinr. mit Punkt ist keine gute Idee für eine Attributbezeichnung. Geändert 2026-07-22 11:44:33 +02:00
s.ayadi 042d3b72e8 Merge branch 'master' of https://gitea.schoenenberger.de/Schoenenberger_Systeme_GmbH/dxfmakros 2026-07-21 14:51:00 +02:00
s.ayadi e63694a4af fix for changing 2026-07-21 14:42:51 +02:00
y.wang 5bb6bb8241 fix: Z-Versatz bei GF/VF behoben (OSMODE=0 im Wrap ssg-block-wrap-welt); gepickte Hoehe als Einfuegehoehe im GF-Dialog 2026-07-21 14:05:13 +02:00
y.wang 21daab974d Merge branch 'master' of https://gitea.schoenenberger.de/Schoenenberger_Systeme_GmbH/dxfmakros 2026-07-20 16:50:14 +02:00