222 Commits

Author SHA1 Message Date
s.ayadi 47d1e8d395 Fix: fehlende Linienzug-Testantwort "AS-Element setzen?" ergaenzt
Analog zur bereits in df96071 nachgetragenen "ES-Element setzen?"-Antwort:
die in Commit 3e23003 neu eingefuehrte Frage am Einlauf fehlte noch in
linienzug_tests.json und hat die restliche Eingabe-Queue verschoben.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-03 15:44:13 +02:00
s.ayadi b744c94819 Add Etage-Typ-Unterstuetzung zu test_mubea.lsp + Testfall fuer Objekt 0061
mubea:build-vario(-one) liest jetzt ein optionales "typ"-Feld ("standard"
Default, "etage") und dispatcht auf berechne-etage/etage-foerderanlage-
einfuegen bzw. vf-block-erstellen mit dem passenden Typ. Neuer Testfall
VF_Mubea_Etage_0061 bildet Objekt-ID 0061 aus Mubea_Quali.dxf nach
(deltaL=12790, deltaH=0, seite=links, Winkel=9, L_GF1=1602.4).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-03 15:41:06 +02:00
m.stangl df96071f79 [FIX] Blockname-Kollision in omni:make-gerade + fehlende Linienzug-Testantwort
omni:make-gerade: itoa(fix(CDATE*1e6)) als Kollisions-Suffix sprengte den
32-Bit-INT-Bereich und liess den Lisp-Fehler mitten im BLOCK/INSERT-Kommando
laufen (BricsCAD blieb dann auf eine Eingabe wartend haengen) - trat bei der
Omniflo-Streckenzug-Testschleife auf, da ssg-timestamp nur Sekundenaufloesung
hat und mehrere Geraden pro Sekunde entstehen. Ersetzt durch einen laufenden
Zaehler.

linienzug_tests.json: die in 3e23003 neu eingefuehrte "ES-Element setzen?"-
Frage fehlte im Testskript und hat die restliche Eingabe-Queue um einen
Eintrag verschoben.
2026-07-30 15:46:00 +02:00
s.ayadi 21c1a65bfd ADD Scanners 2026-07-29 14:28:01 +02:00
m.stangl f2b72df6e0 [FIX] Separator/Scanner erhalten ID sofort beim Insert (wie Kreisel/GF/VF)
ssg-id-generate wird bereits ueberall sonst direkt beim Einfuegen
aufgerufen (KreiselInsert.lsp, Gefaellestrecke.lsp, vf_core.lsp,
vf_linienzug.lsp, OmniModulInsert.lsp, TEFInsert.lsp). Separator/Scanner
waren die einzige Ausnahme: weder ils-insert-sensor (Produktion) noch
mubea:build-separator-one (Testharness) riefen es auf - ihre ID kam
bisher ausschliesslich aus dem einmaligen ssg-id-check-all-Durchlauf vor
dem Export. Das war vermutlich die Ursache fuer die beobachtete doppelte
ID (Kreisel und Separator teilten sich "0003").

- Lisp/SSG_LIB_Commands.lsp (ils-insert-sensor) und tests/test_mubea.lsp
  (mubea:build-separator-one) rufen jetzt ssg-id-generate direkt nach dem
  INSERT auf.
- ssg_id.lsp: ssg-id-set-and-verify prueft nach jedem ssg-attrib-set-on
  sofort zurueck und warnt laut, falls das Schreiben (z.B. mangels
  ID-ATTDEF an der Instanz) stillschweigend fehlschlaegt. Ausfuehrliches
  dbg-Logging (ssg-id-collect-blocks/-max/-generate/-check-all/-set-and-
  verify) fuer die weitere Diagnose.
- ssg-id-check-all bleibt als Sicherheitsnetz fuer Faelle, die kein
  Insert-Hook abfangen kann (Copy/Array/Spiegeln in BricsCAD, Drawing-
  Merges).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-29 11:47:14 +02:00
s.ayadi 98f1c64c3d Fix des Redefines im Lisp. Erzeugte lange schleifen. Jeder Block nur einmal laden 2026-07-28 16:11:31 +02:00
m.stangl 1d5d7c141e [FIX] Scanner-Insert in TEST_MUBEA: eff wurde durch AND statt IF zu T
mubea:build-separator-one nutzte (and blockname (ssg-ils-block-laden
blockname)) fuer eff - AutoLISPs AND liefert bei mehreren wahren
Ausdruecken T zurueck statt des letzten Werts (anders als in Common
Lisp/Scheme). Sobald ein Blockname (z.B. "Scanner") direkt gefunden
wurde, statt ueber den Separator_SP-Fallback zu laufen, wurde eff=T
an "_.INSERT" uebergeben. Fix: (if blockname (ssg-ils-block-laden
blockname)).

Ausserdem: Scanner-Testeintrag in mubea.json ergaenzt und
_vario_count/_separator_count in test_mubea.py, damit erwartete
Ergebniszahlen auch bei "anzahl">1 (Template->mehrere Kopien) stimmen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-28 13:49:21 +02:00
m.stangl bc1457e9bd Aktuellen Stand von Mubea der funktioniert. 2026-07-28 13:13:47 +02:00
m.stangl 4f1177c1f2 Einige Werte zu GF und VF korrigiert 2026-07-28 11:52:01 +02:00
m.stangl ad7a7243ba Fix der Gefällestrecke: Nimmt auch Fliesskommazahlen für den Winkel an. An Mubea Layout gemerkt. Funktionen zur Einfügung vno Geraden dazu 2026-07-28 11:03:15 +02:00
m.stangl cee2a81b55 Varioförderer Masse geändert 2026-07-27 22:16:36 +02:00
m.stangl e974e63c40 weiter am Mubea Test gebaut. Korrektur der GF und VF koordinaten 2026-07-27 22:09:20 +02:00
m.stangl a8fac86754 Mubeat Test hinzu 2026-07-27 16:54:04 +02:00
m.stangl 2f2e7c46d9 erste Fassung der Erzeugung von Mubea als Test hinzugefügt 2026-07-27 16:04:32 +02:00
y.wang 3e23003b24 Modus 1 GF/VF-Split: Menüpunkt Neue Linie aufgeteilt in GF-Linie und VF-Linie;Testdaten für Lineinzug_tests.json angepasst. weil der 26°-Gefälle-Testfall jetzt korrekt Option 2 (VF statt GF) wählt.;Neuer Befehl Vario_Kette_Merge: Verschmilzt mehrere einzeln gebaute VF_n-Blöcke via KS_AUS→KS_EIN-Nachbarschaft zu einem Gesamt-Block (aggregierte Attribute, Lücken-Erkennung),Neuer Menüeintrag: [Vario_Kette_Merge]^C^C(ssg-ensure VarioFoerderer) Vario_Kette_Merge 2026-07-27 09:23:33 +02:00
m.stangl 60f2b72e39 Omniflo-Streckenzug-Test + skriptfaehige Aluprofil-Geraden
Neuer Test: 4 Geraden -> 180-Grad-Kurve (4x 45-Grad-Bogen) -> 4 Geraden
als lueckenlos verketteter Streckenzug (U-Form).

- testdata/omniflo_strecke_tests.json: 12 Elemente mit berechneter,
  verketteter Platzierung (x, y, drehung, x_ende, y_ende, Bogen-Mittelpunkt)
- test_omniflo_strecke.py: Geometrie-Validierung ohne BricsCAD (Struktur,
  Katalog-Abgleich, Verkettung, Kurvensumme 180 Grad, gemeinsamer Mittelpunkt)
- test_omniflo_strecke.lsp: C:TEST_OMNIFLO_STRECKE baut die Strecke auf
- alltests.json/README.md: Test registriert und dokumentiert

OmniModulInsert.lsp: omni:insert-block in skriptfaehigen Kern omni:make-gerade
+ omni:read-src-attribs aufgeteilt. Der Kern erzeugt eine Aluprofil-Gerade
non-interaktiv aus zwei Punkten (kein getpoint/ssg-start), sodass der Test
echte Gerade-Bloecke statt nackter Linien baut. Interaktives Verhalten von
omni:insert-block bleibt unveraendert (Vorschau-Text, Laengenpruefung).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-23 17:51:05 +02:00
m.stangl 3f7074f06b Lisp-Unit-Tests fuer reine Standardfunktionen + run_tests.bat --lisp
- tests/test_unit.lsp: Mini-Test-Framework (tu-eq/tu-eqf/tu-true/tu-nil)
  und Testfaelle fuer reine Funktionen aus ssg_core, ssg_lang, ssg_id,
  vf_core, export, Gefaellestrecke, OmniModulInsert, KreiselInsert.
  Befehl TEST_UNIT schreibt tests/output/unit_results.txt.
- tests/test_unit.scr: Headless-Startskript (laedt SSG_LIB, ruft
  TEST_UNIT, beendet BricsCAD), pfadunabhaengig ueber DXFMAKRO.
- bin/run_tests.bat: Schalter --lisp startet BricsCAD headless, wertet
  den Report aus (RESULT: OK/FAIL) und setzt den Exit-Code.
- tests/README.md: Abschnitt zu den LISP-Unit-Tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-23 14:44:35 +02:00
m.stangl 1c5f29a250 test_foerderer.py: Spaltenindizes an neue Fehler-/IDs-Spalten angepasst
CSV-Header hat inzwischen eine "Fehler"-Spalte (export_csv.py, zwischen
Nachbarn und Merkmale) und der Sivas-Export eine "IDs"-Spalte (export_sivas.py,
vor details) bekommen - der Test war darauf noch nicht nachgezogen und
erwartete die alten Spaltenpositionen/Header, wodurch Header- und
Merkmale/details-JSON-Pruefungen fehlschlugen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-23 12:55:50 +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
m.stangl ad287b683d CSV-Export: Nachbarschaftserkennung neu aufgebaut (ohne shapely), Fehlerspalte ergaenzt
Nachbarschaft wird jetzt in drei getrennten Gruppen geprueft statt global
ueber alle Elemente: Kreisel/Eckrad gegeneinander, Kreisel/Eckrad gegen
Gefaellestrecke/Foerderer/Strecke-Modul (diese drei nicht gegeneinander),
und Omniflo-Elemente gegeneinander (rasterbasiert vorgefiltert nach x/y-
Koordinate). Ersetzt die bisherige shapely-STRtree-Loesung durch reines
Python, da die shapely-Abhaengigkeit den regulaeren CSV-Export in der von
BricsCAD genutzten Python-Umgebung brechen konnte.

Neue Spalte "Fehler" markiert Elemente mit zu wenigen Partnern
("unverbunden"/"nur ein Partner") je nach TeileArt-Mindestanzahl.

Ausserdem: SSG_RUN_ALL_TESTS-Absturz nach TEST_KREISEL behoben (ssg-start/
ssg-end nutzten flache globale Variablen statt eines Stacks, wodurch
verschachtelte Aufrufe den *error*-Handler dauerhaft korrumpierten) und
FILEDIA=0 um den DXFOUT-Kommandozeilenaufruf ergaenzt.
2026-07-23 10:35:42 +02:00
m.stangl 6ab698286f CSV-Export: Nachbarschaftserkennung ueber Bounding-Box-Ueberschneidung (STRtree/shapely)
Neue Spalte "Nachbarn" (kommaseparierte TeileId-Liste) in export_csv.py:
zwei Elemente gelten als benachbart, wenn ihre Bounding-Boxes (x/y-Ebene)
sich ueberschneiden. Toleranz konfigurierbar in mm ueber cfg/export.cfg
[Nachbarschaft] -> toleranz_mm, siehe lib/export_neighbors.py.
Nur EXPORTCSV betroffen, EXPORTSIVAS bleibt unveraendert.

shapely als neue Abhaengigkeit in requirements.txt ergaenzt.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-22 15:26:30 +02:00
m.stangl 57badf0556 Sivas-Export: Spalte Hoehe[m] entfernt
Die Hoehe-Angabe steht bereits pro Element in der details-JSON-Spalte
(z.B. "Hoehe in m" aus dem MONTAGEHOEHE_m-Attribut bei VarioFoerderer/
Linienzug), die separate Top-Level-Spalte war redundant.
2026-07-22 13:01:24 +02:00