Neues Modul KettenFoerderer.lsp: baut aus KF_UM_<winkel>, KF_LAENGE und
KF_AN_<winkel> (je KS_AUS auf KS_EIN) plus der Draufsicht KF_2D einen Block
KF_<n>. Die Bausteine werden aufgerichtet eingebaut (Rz*Rx(90)*Rz), die Hoehe
laeuft in Z; KF_2D liegt deckungsgleich mit der Kette. Der Einbauwinkel jedes
Folgebausteins wird aus der Richtung des KS_AUS seines Vorgaengers gemessen,
KF_LAENGE ueber die Einbauhoehe skaliert.
- Dialog (DCL-Vorlage, Typ als Radiobuttons), Hoehe per Zahl oder aus zwei
Punkten, Doppelklick auf KF_n oeffnet KF_EDIT mit Neuaufbau
- eigenstaendiges Attribut-Schema, Auswahllisten mit Sivas-Optionstexten in
data/json/kettenfoerderer.json
- Sivas-Export: Merkmale 350, 353-357, 359-361, 391, baugleiche Foerderer
werden zu einer Zeile zusammengefasst (Artikelnummer 6120)
- ssg_ks_insert.lsp: neue Primitiven ks-xy-winkel, ks-block-messen,
insert-block-ks-skaliert und insert-block-ks-matrix (freie 3x3-Rotation);
ensure-block-loaded nimmt Bloecke ohne Dimensionssuffix unveraendert
- Menueeintrag KettenFoerderer aktiviert, toter Dummy OMNI_KettenFoerderer
entfernt; KF_* im Export-Pattern, in der ID-Vergabe und im Dispatcher
SSG_BLOCKEDIT (vor dem Omniflo-Zweig)
- Unit-Tests tu-tests-kf fuer die reinen Rechenkerne; Modul wird in der MNL
vorgeladen, dbg-Schalter kf-zeit zur Laufzeitmessung
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Bisher war der geklickte Punkt immer der KettenANFANG. Oft steht aber das
andere Ende fest - typisch der Anschluss an einen Kreisel. Modus 1 fragt
deshalb jetzt ganz am Anfang nach der Bau-Richtung:
vorwaerts = geklickter Punkt ist der Kettenanfang (alles wie bisher)
rueckwaerts= er ist das Kettenende, genauer das KS_AUS des ES-Elements
ABLAUF RUECKWAERTS
ES setzen? + Winkel + Seite + Fahrtrichtung (2. Punkt) in EINEM Dialog, dann
"Neue Linie: GF" und die Laengenfrage mit drei Optionen:
1 Kettenanfang klicken -> + Neigungswinkel, Anfangshoehe wird gerechnet
2 Anfangshoehe vorgeben -> + Neigungswinkel, Laenge wird gerechnet
3 Parallel zum Kreisel -> nur Abstand (nur mit ES waehlbar)
Danach ist die Kette fertig. Die Spiegelfrage "Ist das der Kettenanfang?"
mit optionalem AS und Weiterbauen ist bewusst NICHT enthalten (Nutzer-
Entscheidung: vorerst kleiner Umfang).
ANKER
Das ES wird mit insert-block-mixed-to-ks und xy-ref/z-ref="KS_AUS" EXAKT auf
den geklickten Punkt gesetzt; alles Weitere wird daraus zurueckgerechnet
(vfl-rueck-punkt) und dann normal vorwaerts platziert. Gleiches Ergebnis,
aber mit den erprobten Einfuege-Primitiven. Eine Rest-Ungenauigkeit landet
am Kettenanfang statt am Kreisel-Anschluss.
Option 3 spiegelt die Vorwaerts-Variante: Bogenseite = Gegenseite der
ES-Seite, Bogenwinkel hebt den gemessenen ES-Schwenk auf. Dafuer werden die
bereits getesteten Kerne vfl-par-bogen-waehlen/vfl-par-gf-laenge
wiederverwendet - die Zuordnung (ES 30 links -> 30-Grad-Bogen rechts usw.)
faellt daraus heraus, statt gepflegt zu werden.
ZWEI FEHLER, DIE DER ERSTE BRICSCAD-TEST GEFUNDEN HAT
1. vflw-gruppe-as-impl legt VIER Werte in die Pending-Queue (ja/nein,
Winkel, Seite, Punkt). Die Ja/Nein-Antwort wurde nicht konsumiert, alles
rutschte eine Position weiter - der Winkel bekam die "1" der Ja/Nein-
Frage, Blockname "ES_Element_1_links". Die Frage wird jetzt gestellt und
ausgewertet; "Nein" ist dabei sinnvoll belegt (Kette endet direkt am
geklickten Punkt, Richtung ueber vfl-frage-fahrtrichtung-p2).
2. insert-block-ks-to-ks richtet immer den EINGANG eines Blocks aus.
Rueckwaerts sitzt der Bogen VOR dem GF-Stueck, sein AUSGANG muss also auf
der GF-Achse liegen - der Eingang ist um den Bogenschwenk vorzudrehen
(hz-bogen = hz-ein - bogen-turn). Ohne das zeigte der Ausgang um genau den
Bogenwinkel daneben, KS_AUS und KS_EIN trafen sich nicht. Gilt fuer den
Probe-Bau UND das echte Einfuegen - waere nur eins gedreht, saesse der
Bogen richtig orientiert an der falschen Stelle.
BEDIENUNG
- Kurze Entscheidungen im Rueckwaerts-Ablauf als Radio-Buttons statt
Auswahlliste (vfl-menu-radio).
- Beim Klick auf den Kettenanfang haengt der Cursor auf der Kettenachse
(neuer Wrapper vfl-in-point-achse ueber das vorhandene
vfl-getpoint-achse): ab dort kann nur noch entlang dieser Achse gebaut
werden, ein frei schwenkendes Gummiband gaukelte eine Freiheit vor.
- Zahlen-Dialoge belegen ihr Feld jetzt mit der Vorgabe vor. Die Prompts
tragen sie ohnehin in Klammern ("[3]", "<2154.0>"), der Dialog hat sie nur
ignoriert - bewusst generisch geloest (vflw-vorgabe-aus-prompt), die
Luecke hatten alle Zahlen-Dialoge des Assistenten.
- vflw_as beschriftet Seite und Achse neutral, weil derselbe Dialog jetzt
AS (vorwaerts) und ES (rueckwaerts) bedient; die Punkt-Anzeige heisst beim
ES "Endpunkt".
ABWAERTSKOMPATIBILITAET
Die Richtungsfrage steht VOR der AS-Frage und journalisiert ihren WERT
("vor"/"rueck") statt eines Index - ein Index "1"/"2" waere von der
nachfolgenden AS-Ja/Nein-Antwort nicht zu unterscheiden. Fehlt der Eintrag,
ist es ein Alt-Journal und es wird vorwaerts gebaut. Dafuer der neue Wrapper
vfl-menu-strwert.
TESTS
12 neue file- und zeichnungsfreie Unit-Tests: vfl-rueck-punkt (Rundlauf
vorwaerts/rueckwaerts) und vflw-vorgabe-aus-prompt (gegen die echten
Prompt-Texte, inkl. der Stolperstellen "0 < Winkel <= 3" ohne schliessendes
">" und dem Nachsatz in runden Klammern). TEST_UNIT konnte noch nicht
laufen - BricsCAD war die ganze Sitzung geoeffnet. Der Rueckwaerts-Bau
selbst ist vom Nutzer in BricsCAD geprueft und bestaetigt.
SSG_LIB.cui ist das von BricsCAD neu erzeugte Kompilat zur Menue-Aenderung
des vorigen Commits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Die AS-Praeambel in Modus 1 fragt jetzt Winkel, Seite UND eine optionale
Zufuehrungsachse (2. Punkt) - im Assistenten alles in einem Fenster
(vflw_as_achse). Beide Angaben zusammen legen das AS vollstaendig fest: der
2. Punkt gibt die KS_EIN-Achse (Zufuehrung/Fahrtrichtung), links/rechts die
AS-Variante und damit die KS_AUS-Richtung der Kette. Bisher galt die Achse
nur beim 30-Grad-Element und ERSETZTE dort die Seitenfrage.
Darauf setzt die neue 5. Option der gf-laenge-modus-Frage auf, intern
"parallel" (vfl-gf-parallel-kreisel): AS -> GF-Stueck -> GF-Bogen aus EINEM
Abstandswert, gemessen senkrecht zur Zufuehrungsachse von AS-KS_EIN bis
Bogen-KS_AUS. Kein Separator dazwischen, damit der Abstand exakt getroffen
wird; die Kettenende-Frage stellt der Zweig selbst NACH dem Bau. Waehlbar
nur am Kettenanfang mit AS UND Achse.
Der Bogen ist nicht verdrahtet: gewaehlt wird der, der den gemessenen
Grundriss-Schwenk des AS-Blocks aufhebt (vf-element-plan-turn) - mit den
vorhandenen Bausteinen AS 30 -> 30-Grad-Bogen, AS 90 -> 90-Grad-Bogen,
immer zur Gegenseite. Querversatz von AS und Bogen wird gemessen statt
gerechnet; die Bogen-Probe laeuft dabei auf dem IDEALISIERTEN 3-Grad-Rahmen,
auf dem der echte Bogen spaeter sitzt (auf dem AS-Rahmen gemessen lag der
Abstand im BricsCAD-Test um 0.5 mm daneben).
Journal: [STR winkel][STR seite][PT p2 | NIL]. Welche Fragen gestellt wurden,
wird nicht journalisiert, sondern beim Replay an der Eintragsart erkannt -
alte Ketten bleiben ohne Sonderbehandlung editierbar. Die Journal-Werkzeuge
(vf_linienzug_grammatik.py, vf_spec_export.py, vf_journal_export.py,
vf_spec.lsp, test_hm_recformat.lsp) kennen das optionale Achsen-Token.
Tests: 11 neue Unit-Tests fuer die reinen Kerne vfl-par-bogen-waehlen und
vfl-par-gf-laenge (tu-tests-vfl-parallel), TEST_UNIT 701/701 gruen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
- Rad/Rad an beiden Flanken gilt nur bei gleich ausgerichteten Raedern als
"Seite an Seite"; in Gegenrichtung (Kreisel seitlich versetzt Ende an Ende)
ist es eine Weiche
- toleranz_beruehrung von 1 auf 10 mm (Zeichenungenauigkeiten, Spalt und
Ueberlappung)
- Unit-Tests fuer Ende-an-Ende, Seite-an-Seite und den Fall aus test.dxf (E3/C7)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
- Eckrad: eigener DCL-Dialog (eckrad_edit.dcl) beim Einfuegen und per
Doppelklick (EckradEdit); Sivas-Merkmale am Kreisel ausgerichtet
(2950, 3381, 3992 Ja/Nein); bei Sep./Scanner-Zaehlung ausgenommen
- Kreisel: eigener Name bleibt in Bezeichnung + Beschriftung erhalten
- Sivas: Kreisel/Eckrad unterschiedlicher Hoehe nicht mehr zusammengefasst
- Export: Hoehen-Attribute in Z verschobener Kreisel/Eckrad/VF/GF neu
berechnet
- GF-Edit: Einfuegehoehe aus aktueller Z-Koordinate
Fahrstrecke:
- Neuer Befehl OMNI_FAHRSTRECKE (+ _BESCHRIFTEN) im Omniflo-Menue,
Daten aus data/json/omniflo_fahrstrecke.json, Vorlage dcl/fahrstrecke.dcl
- Nutzt die Linien-Logik des Geruest-Traegers (geruest-linien-starten,
Dialog/Einfuegen/Beschriftung je Baugruppe parametriert)
- Muffen-Dummy wie beim Traeger, farbig nur wo in der JSON gesetzt
- Stueckliste: eigene Klasse "Omniflo Fahrstrecke" (GR_Fahrstrecke_*)
Geruest-Dialoge:
- DCL als statische Vorlagen mit //@NAME@-Platzhaltern
(ssg-dcl-vorlage-fuellen in ssg_core), dcl/geruest.dcl neu
- Ein Dialog je Bereich (keine Bereichsumschaltung mehr)
- Varianten als Radiobuttons mit Artikelnummern im Label,
"disabled": true graut Varianten aus
- Eine Befestigungsspalte (Gesamtanzahl) + Zeile "Sonstiges",
Art.-Nr. unter jedem Anbauteil
- Winkel Platte (0/90): Anbauteile gedreht eingefuegt
- Kennzeichnung geaenderter Konfiguration, Ueberspeichern per Enter
- Traeger: Querstreben nur bei "mit_querstrebe": true
Konfigurationen im alten Format (oben/unten) werden beim Laden
uebernommen. Unit-Tests ergaenzt (599 gruen).
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>
Die sl-*-Keys (Tabellenkoepfe, Prompts, Elementklassen) fehlten komplett in
lang/de_DE.json und lang/en_GB.json: sie standen beim vorangegangenen
Merge-Konflikt-Fix noch unstaged im Working Tree (nicht committed) und wurden
dabei versehentlich durch die reparierte, aber auf dem alten HEAD basierende
Version ueberschrieben. ssg-text lieferte dadurch den rohen Key statt des
uebersetzten Textes zurueck ("sl-stkl-kopf-menge" statt "MENGE" usw.).
Zusaetzlich: ssg-sl-tabelle-zeichnen zeichnete nur den Aussenrahmen und
horizontale Zeilentrenner, keine vertikalen Spaltenlinien - ergaenzt an den
vier Spaltengrenzen (400/1000/1900/3000 relativ zum linken Rahmen), von der
Kopfzeilen-Oberkante bis zur letzten Zeilenlinie.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ssg-sl-tabelle-zeichnen/ssg-sl-faehnchen riefen TEXT ueber command auf. Bei
einem aktiven Textstil mit fester/variabler Ausrichtung (Mitte/Fit/Aligned
statt Links) fragt TEXT dann einen zweiten Punkt zusaetzlich ab - jeder
nachfolgende command-Aufruf landete am falschen Prompt, wodurch Kopf- und
Datenzeilen der Stuecklistentabelle sich alle an derselben Stelle stapelten
statt an ihrer vorgesehenen Position (Header nicht mehr lesbar).
Neue Hilfsfunktion ssg-sl-text-machen erzeugt TEXT-Entities per entmake statt
ueber den interaktiven command-Pfad - unabhaengig von Textstil/Ausrichtung
und der command-Promptkette. Gleiche Fehlerklasse wie der _.-INSERT-Fix bei
DIN_FORMATE (vorheriger Commit).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ersatz fuer das alte ACADSST-Makro DINFORM.LSP/.DCL (SSG2 "DIN-FORMATE..."):
neues Werkzeuge-Menue "Din Formate" fuegt einen DIN-Rahmen (A0-A3, A4 quer/
hoch) und optional einen Schriftkopf (Kopf11, DE/EN/FR/IT) per Dialog ein.
Block-DWGs liegen flach in cfg/rahmen/ (kopiert aus
\infor-ln\SSG_Tools\ACADSST\KOEPFE - nur die von DINFORM.LSP tatsaechlich
referenzierten Dateien). Das Laden der Blockdefinitionen laeuft ueber
vla-InsertBlock+vla-Delete (COM-Weg wie ssg-ils-block-laden-dim), da ein
command-basiertes "_.-INSERT ... _X" in der interaktiven Befehlskette haengen
bleibt und nachfolgende getpoint-Aufrufe blockiert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Der vorige Fix (80e5e62) nutzte insert-block-mixed-to-ks mit z-ref="KS_AUS" (sep-endpunkt als Ziel-Z) - das zwingt aber den BLOCKAUSGANG des ES-Elements auf diese Hoehe, nicht den Blockeingang, an dem die Kette tatsaechlich anschliesst. Der ganze Block wurde dadurch zusaetzlich um seine eigene KS_EIN<->KS_AUS-Innenhoehe nach oben verschoben.
Modus 1/2 (gefaellestrecke-einfuegen) macht das bereits richtig: dort haengt das EIN-Element ueber reines insert-block-ks-to-ks (keine erzwungene Ziel-Z) an den Ketten-Pfad, die Endhoehe ergibt sich danach von selbst aus KS_AUS. GEFAELLESTRECKE_LINIENZUG (Modus 3) auf dasselbe Muster umgestellt - sowohl im normalen Bau (gf-linienzug-modus) als auch im Doppelklick-Rebuild (gf-linienzug-rebuild).
Manuell in BricsCAD verifiziert: Hoehenversatz jetzt korrekt, kein Rest-Sprung mehr.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Das ES-Element wurde ueber insert-block-mixed-to-ks so platziert, dass sein KS_EIN exakt auf (caddr endpunkt-ref) landet - die Z-Koordinate des zweiten Mausklicks (Kettenende waehlen). Geraden und Boegen davor waren korrekt geneigt (grade wird separat berechnet/bestaetigt und fliesst in gf-linienzug-einfuegen ein), aber die anschliessende ES-Platzierung zog die Hoehe wieder auf den Klick-Wert zurueck - bei einem Klick in einer 2D-Draufsicht ohne 3D-Objektfang liegt der meist auf derselben Z wie der Startpunkt, das ES-Element landete dann faelschlich wieder auf Starthoehe trotz korrekt gefallener Kette.
Fix: Ziel-Z fuer das ES-Element ist jetzt (caddr sep-endpunkt) - die tatsaechlich durch die Kette (Geraden/Boegen mit grade) aufgebaute Hoehe am Ende, nicht der Klick-Wert. endpunkt-ref dient weiterhin nur zur groben deltaH-Schaetzung fuer den Winkel-Vorschlag im Dialog (den der Nutzer ohnehin bestaetigt/ueberschreibt). Das Attribut HOEHE_BIS_mm wird aus demselben Grund jetzt ebenfalls aus der real gebauten Endhoehe (es-aus-frame) statt aus endpunkt-ref gelesen, damit es nicht von der sichtbaren Geometrie abweicht. Identischer Fix im neuen Rebuild-Pfad (gf-linienzug-rebuild) angewendet, der denselben Mechanismus nutzt.
Manuell in BricsCAD verifiziert: ES-Element hat jetzt korrekten Hoehenversatz.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bisher brach GEFAELLESTRECKE_EDIT bei jeder Streckengruppe (TYP "Streckengruppe", d.h. mit mindestens einem Bogen) mit "Nur einfache Gefaellestrecken..." ab - Grund war nicht fehlende Technik, sondern dass gf-linienzug-modus schlicht keine Edit-XDATA schrieb (anders als Modus 1/2 ueber SSG_GF_EDIT).
Neue XDATA-App SSG_GF_LZ (gf-lz-xdata-schreiben/-lesen in Lisp/Gefaellestrecke.lsp) sichert die Segmentliste (Typ/hz/Laenge/Winkel/Seite je Segment, bereits laengenfertig) + den Baustartpunkt - Serialisierung per gf-segmente->string/gf-string->segmente, Chunking ueber die bestehenden ssg-sepliste-chunk-string/-split-feld/-explode-chars-Helfer aus ssg_ks_insert.lsp (wiederverwendet statt dupliziert).
Neue Funktion gf-linienzug-rebuild: baut die Kette am selben Startpunkt neu, AS-/EIN-Element und Gefaellewinkel bleiben ueber dieselben zwei Dialoge wie beim Bauen editierbar (gf-dialog-linienzug-aus-ein/-winkel, jetzt mit prefill-Parameter fuer den Edit-Fall statt Defaults) - die Segmentlaengen/-form selbst nicht (dafuer bleibt GEFAELLESTRECKE_LINIENZUG als Neubau). c:GEFAELLESTRECKE_EDIT dispatcht vor der bisherigen TYP-Sperre: Streckengruppe MIT SSG_GF_LZ-XDATA -> neuer Rebuild-Pfad, Streckengruppe OHNE (Altbestand/VF-Kombi) -> bleibt wie bisher abgewiesen. Alter Block wird erst NACH erfolgreichem Neuaufbau geloescht.
doc/variofoerderer.md um den Edit-Ablauf ergaenzt.
Manuell in BricsCAD getestet (Doppelklick auf Linienzug-Streckengruppe, beide Dialoge vorbelegt, Neuaufbau, erneuter Doppelklick auf das Ergebnis) - laeuft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Zwei neue Dialoge (dcl/gefaellestrecke.dcl, Lisp/Gefaellestrecke.lsp):
- gf-dialog-linienzug-aus-ein: AUS-/EIN-Element Winkel+Seite in EINEM Dialog, ersetzt die vier fruehen Konsolenfragen. Muss vor der Segmentlaengen-/Winkelberechnung laufen (haengt von AS-/ES-Masse ab), darum eigener, fruehzeitiger Dialog.
- gf-dialog-linienzug-winkel: zeigt den automatisch aus der Segmentkette berechneten Gefaellewinkel-Vorschlag ueberschreibbar, mit kurzer Segment-Zusammenfassung und dem bereits gewaehlten AS/ES-Paar nur noch zur Kontrolle (disabled). Ersetzt zugleich die SPAETERE finale Einfuegen-Bestaetigung - nach der rein automatischen AS/ES-Korrekturschleife waere eine zweite Rueckfrage redundant.
Objektauswahl (ssget LINE/ARC) und Start-/Endpunktwahl bleiben bewusst Zeichnung/Konsole. Rueckfall auf die alten Konsolenfragen bleibt erhalten, wenn ein Dialog nicht gezeigt werden kann/darf (GUI aus); ein bewusster Dialog-Abbruch bricht dagegen den ganzen Befehl ab statt auf Konsole zurueckzufallen - neu im Vergleich zum alten Verhalten, aber konsistent mit vfc_eingabemodus/vfs_nachruesten_hz aus Teil A/C.
doc/variofoerderer.md (Abschnitt 4) aktualisiert und um einen bebilderten Beispiel-Walkthrough ergaenzt (gf-linienzug1-3.png: Ausgangslinie, Dialog mit Vorschlagswinkel, fertige Strecke neben der Original-Linie).
Manuell in BricsCAD getestet (vollstaendiger Lauf inkl. Abbruch in beiden Dialogen) - laeuft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer Dialog vfs_nachruesten_hz (dcl/variofoerderer.dcl) + vfs-dialog-nachruesten-hz (Lisp/vf_standard.lsp) ersetzt den fruehren getreal-Prompt. Zeigt pro unmarkiertem VF_n-Fund Blockname/erkannten Typ und ein hz-Feld, vorbelegt mit dem zuletzt eingegebenen Wert (identisches Default-Fortpflanzungs-Verhalten wie vorher).
"Abbrechen" im Dialog uebernimmt bewusst nur den Vorgabewert fuer DIESEN Fund (Rueckgabe 'ABBRUCH), statt die ganze Nachruesten-Schleife abzubrechen oder auf die Konsole zurueckzufallen - echter Konsolen-Rueckfall bleibt ausschliesslich fuer den Fall, dass der Dialog gar nicht gezeigt werden kann (GUI abgeschaltet). Die Objektauswahl (ssget) selbst bleibt unveraendert Zeichnung/Konsole.
doc/variofoerderer.md um den Befehl ergaenzt (war dort bisher gar nicht erwaehnt).
Manuell in BricsCAD getestet (unmarkierter VF_4-Block, Dialog erscheint, hz=0 markiert) - laeuft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Kern-Ladereihenfolge ergaenzt (ssg_id, ssg_ks_insert, ssg_input), Dummy-Status-Tabelle korrigiert (OMNI_TEF_* ist implementiert, nur OMNI_KettenFoerderer/OMNI_TV_*/OMNI_APBW_* und ein paar ILS-Kurven-Platzhalter sind noch Dummy). Fehlende Module ergaenzt: ssg_id.lsp, ssg_ks_insert.lsp, TEFInsert.lsp, GeruestInsert.lsp, Tro_Edit.lsp, Connection_Edit.lsp, DrawPlanquadrate.lsp. VarioFoerderer-Abschnitt an die Submodul-Aufsplittung (vf_core/vf_standard/vf_etage/vf_linienzug/vf_konstanten/vf_spec) und den Wizard/Journal/Headless-Mechanismus angepasst. SSG_BLOCKEDIT-Dispatchtabelle um GF_*/VF_*/GR_*/TRO_* ergaenzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
[CHANGE] VF-Linienzug-Wizard: horizontale Kurve (GF-Bogen/Vario-Kurve) direkt nach explizit eingefuegtem AS-Element ausgegraut, da dort zuerst ein gerades Segment folgen muss
[ADD] doc/faq.md: Antworten zu VF/GF-Kombinationsfragen ergaenzt (Puffer-Umschleusung, Zielhoehe, Etagenfoerderer, Streckenueberbrueckung) + Screenshot gf-vf-kombination.png
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
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>
Neue Linie: GF (Zweig A+B) zog bei Kettenende mit ES-Element nur den
ES-eigenen Fussabdruck von deltaL/deltaH ab, nicht den zusaetzlichen
automatischen 300mm-Separator, den vfl-insert-es-element immer selbst
vor dem ES-Block einfuegt - die Kette baute dadurch zu lang/zu tief.
Zusaetzlich: "Separator NACH" im Wizard-Dialog (vflw-gruppe-sep-gf-impl)
wird jetzt ausgegraut statt gefragt+nachtraeglich verworfen, wenn das
GF-Segment ohnehin mit einem ES-Element endet (der automatische
Separator deckt das bereits ab). Pending-Queue-Anzahl bleibt dabei
unveraendert (Dialog pusht weiterhin 2 Werte), um keinen Versatz mit
den nachfolgenden Konsolen-Abfragen zu erzeugen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neue Module ssg_blocktools.lsp (SSG_BLOCK_COUNT, SSG_BLOCK_DELETE,
SSG_ATTR_ERSETZEN) und ssg_texttools.lsp (SSG_TEXT_ERSETZEN,
SSG_TEXT_PARALLEL, SSG_TEXT_HOEHE, SSG_TEXT_STIL) sowie der generische
Eingabe-Wrapper ssg_input.lsp, dazu Menue-/Lade-Integration,
zweisprachige Texte und Unit-Tests fuer die reinen Kerne.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SSG_RUN_ALL_TESTS_EXPORT setzte *export-test-override* nicht, dadurch
landeten CSV/Sivas-Exporte trotz Automatik-Modus in DXFM_RESULTS statt in
tests/output wie die DXF/DWG-Dateien selbst - jetzt analog zu
TEST_EXPORT_ALL behoben.
EXPORTSIVAS schrieb bisher immer zusaetzlich eine "_mit_bezeichnung.csv"
(Klartext-Kopie). Neuer Schalter "Sivas Export mit Bezeichner" im Dialog
CSV_EXPORT_KONFIG (Standard aus) macht das optional.
Die Attribut->Sivas-Merkmal-Zuordnung der build_*_details-Funktionen in
export_sivas.py (Gefaellestrecke/Kreisel/Eckrad/Geruest/VarioFoerderer,
soweit nicht von der Segmentanzahl abhaengig) liegt jetzt deklarativ in
cfg/sivas.cfg statt hartcodiert im Python - neuer Loader
lib/sivas_mapping.py. Ablauflogik (Gruppierung, Automation-Summenzeile,
Segment-Zaehlung) bleibt Code. Gegen den alten Code mit synthetischen
Testblöcken verifiziert: identische Ausgabe.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- ZUORDNUNG: ssg-id-check-all laeuft jetzt ZUERST, danach sind die
Wrapper-IDs endgueltig - Separator-Kopien, AS/ES- und Einheiten-Marker
bekommen ZUORDNUNG direkt beim Erzeugen. Entfallen:
csv:sep-proxies-zuordnung-setzen, csv:asmark-ids-setzen,
csv:unitmark-ids-setzen. zuordnung_fix/*cs-sep-fix-by-handle* bleibt
(count_sep_scan rechnet eigenstaendige Sensoren bewusst neu).
- sepliste-IDs: Zuordnung ueber die KS-Kettenfolge je Typ
(csv:sepliste-kette-paare) statt ueber die teils gespiegelten
sepliste-Koordinaten (csv:sepliste-paare, csv:sepliste-ids-setzen
entfallen). Die Kette wird je Lauf einmal berechnet (csv:kette-von);
die ID liest csv:block-to-json erst beim Schreiben. Behebt vertauschte
TrackIds/Nachbarn in HundM05 VF_1 (0031/0029).
- Element-Klassifizierung: eine Tabelle csv:element-familien (cfg-Muster)
fuer Suche und Klassifizierung; csv:proxy-typ entfaellt.
- Einheiten-Marker: K1/K2 nur noch in *csv-baustein-by-handle*
(csv:geometrie-merken), K1/K2-Attribute und
csv:unitmark-k-kos-strings entfallen.
Geprueft: HundM05-Export alt/neu headless verglichen - einzige Abweichung
ist die korrigierte Reihenfolge in VF_1. LISP-Unit-Tests 303/303.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
y.wang
s.hensch
s.ayadi
m.stangl