Separator_SP_2D/_3D-Sensorsymbole, die beim Zusammenbau der Compound-Bloecke
(VF_n/GF_n/KREISEL_n) als Sub-INSERT in deren Blockdefinition verpackt
wurden, waren fuer (ssget "X" ...) unsichtbar und blieben daher ohne eigene
ID und ohne Zeile im Export-JSON. csv:sep-proxies-erzeugen (export.lsp)
sucht solche verpackten Symbole jetzt vor jedem EXPORTCSV/EXPORTSIVAS ueber
den neuen rekursiven Helfer ssg-collect-nested-inserts (ssg_core.lsp) und
legt fuer jeden Fund eine echte, temporaere Kopie an seiner Weltposition an
(silent ueber vla-InsertBlock statt command-line INSERT). Diese Kopie
durchlaeuft ID-Vergabe/Export unveraendert ueber die bestehenden Funktionen
und wird danach wieder entfernt (csv:sep-proxies-loeschen).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
cs-zuordnung-noetig-p prueft ohne jede Boundingbox (nur Attribute lesen +
interne Ketten-Separatoren aus der Blockdefinition zaehlen), ob der teure
cs-zuordnung-lauf (Boundingbox+Regen je Carrier und Sensor) ueberhaupt
noetig ist. Voller Lauf nur bei leeren ZUORDNUNG-Eintraegen oder wenn die
Summe ANZAHL_SCANNER/ANZAHL_SEPARATOR ueber alle Carrier nicht zur Anzahl
der Scanner-/Separator-Symbole (+ interne Ketten-Separatoren) passt.
Sonst wird uebersprungen (neue Meldung sens-skip).
csv:run-export ruft die Zuordnung jetzt nur noch bei Bedarf auf. Der
interaktive Befehl ZAEHLE_SEP_SCAN rechnet weiterhin immer komplett neu
(deckt auch den Fall ab, dass ein Sensor ohne Summenaenderung von einem
Carrier zu einem anderen verschoben wurde).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
count_sep_scan.lsp neu als wiederverwendbare Engine (cs-zuordnung-lauf),
die automatisch vor jedem CSV-/Sivas-Export laeuft (export.lsp,
csv:run-export). Zaehlt Separator_SP/Scanner je Carrier (Kreisel/Eckrad,
VF_*, GF_*) ueber die gemeinsamen cfg/export.cfg-Muster und schreibt
ANZAHL_SEPARATOR/ANZAHL_SCANNER, so dass die Summe zur Szene passt.
Scanner ausserhalb jeder Carrier-Boundingbox ohne ZUORDNUNG werden per
Abstand dem naechsten Kreisel/Strecke zugeschlagen (ZUORDNUNG = Carrier-ID).
Ist der Abstand zum zweitnaechsten Kandidaten fast gleich (<= strittig_diff_mm,
neu in cfg/export.cfg [Sensorzuordnung]), gilt die Zuordnung als strittig:
Konsolenausgabe der ergaenzten Scanner + JSON-"warnung"-Feld mit den IDs der
strittigen Kandidaten (csv:block-to-json), das export_csv.py in der Spalte
"Warnungen" ausgibt.
Menue: ZAEHLE_SEP_SCAN-Vorlauf vor EXPORTSIVAS entfernt (laeuft jetzt
automatisch im Export); interaktiver Befehl bleibt erhalten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Die Omniflo-Nachbarschaftserkennung (export_neighbors.py, nur EXPORTCSV) wird
zweistufig:
- Broad-Phase ueber shapely-STRtree auf den Bounding-Boxen (Fallback: das
bisherige Raster, falls shapely fehlt).
- Narrow-Phase (KOS-Verfeinerung): zwei moegliche Nachbarn gelten nur dann als
benachbart, wenn ein Anschluss-Koordinatensystem K1-K4 des einen naeher als
omniflo_ks_toleranz_mm (neu, Default 10mm) an einem K-Punkt des anderen
liegt. Das verwirft bloss ueberlappende BBoxen ohne echten Anschluss.
Elemente ohne K1-K4 fallen auf reine BBox-Ueberschneidung zurueck.
Geraden fuehren keine echten K-Bloecke in der Zeichnung; ihre K1 (Anfang) /
K2 (Ende) werden beim Export aus Einfuegepunkt + Laenge + Rotation
synthetisiert (csv:gerade-k-kos-strings in export.lsp) und stehen damit in den
CSV-Spalten K1/K2 - wie echte KOS - und nehmen an der Kollisionspruefung teil.
Verifiziert an results/test-omnicollision: gerichtete Nachbarschaften 20 -> 14.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Ist BricsCAD nicht ueber bin/start_briscad.bat gestartet worden, ist DXFM_LIB
in der Sitzung nicht gesetzt. Bisher liess das (strcat (getenv "DXFM_LIB") ...)
mit "bad argument type <NIL> ; expected <STRING>" abstuerzen. Jetzt wird das
vorher geprueft und ueber ssg-textf (exp-dxfm-lib-missing, de/en) gemeldet;
JSON/CSV-Sammlung laeuft weiter, nur der Python-Aufruf entfaellt.
Unter Windows 11 traf ein blankes "python" den WindowsApps-Platzhalter
(kein echter Interpreter, Exitcode 49). Der Export schrieb die JSON, aber
nie eine CSV - ohne jede Fehlermeldung, da "fire and forget" per startapp.
- export:python-exe: Aufloesungsreihenfolge cfg/export.cfg [python]
interpreter= -> DXFM_PYTHON -> Projekt-venv -> %SystemRoot%/py.exe ->
"python"; WindowsApps-Platzhalter werden verworfen
- export:run-python: synchroner Aufruf per WScript.Shell.Run, stdout/stderr
nach DXFM_LOG/export_python.log, Exitcode-Auswertung
- export:log-ausgeben: erste Logzeilen in die BricsCAD-Kommandozeile
- setenv.bat setzt DXFM_PYTHON (venv oder py-Launcher)
- cfg/export.cfg: neue Sektion [python]
- lang/de_DE.json, lang/en_GB.json: neue Meldungstexte (exp-python-exe,
exp-export-done, exp-python-error, exp-python-store-hint, exp-csv-missing,
exp-python-call-failed)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
csv:block-to-json ergaenzt fuer jeden Block einen Insertpoint-String
(Position+Rotation als Z-Quaternion, csv:kos-encode) sowie K1-K4 als
reine Positions-Strings (csv:trans-encode, 0.1 mm). KS_EIN/KS_AUS werden
auf K1/K2 gemappt, falls keine echten K1/K2 vorhanden sind. Neue CSV-
Spalten Insertpoint;K1;K2;K3;K4 in export_csv.py.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nur EXPORTCSV betroffen, EXPORTSIVAS bleibt unveraendert:
- Position/Boundingbox: Bounding-Box je Block per vla-getboundingbox
(Lisp/export.lsp, csv:get-bbox), Mittelpunkt und Ausdehnung x/y/z.
- Planquadrat: aus x/y-Koordinate berechnet nach cfg/export.cfg
[Planquadrate] (Schrittweite, numerisch/alphabetisch je Achse,
alphabetische Zaehlung mit Excel-Spalten-Umlauf Z->AA), siehe
lib/export_planquadrat.py.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Vollstaendiger i18n-Rollout ueber alle Feature- und Kernmodule: alle benutzersichtbaren princ/prompt/getXXX/alert-Texte laufen jetzt ueber die zentrale Sprachtabelle in ssg_lang.lsp (Deutsch/Englisch, umschaltbar via SSG_SPRACHE). 403 Tabelleneintraege, 497 Aufrufstellen in 17 Dateien.
Ausgeschlossen wie geplant: Debug-Ausgaben (dbg*), Lademeldungen, [DUMMY]-Platzhalter, [CFG]/[OMNI]-Diagnosemarker.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
s.ayadi
m.stangl