Files
qt-migration-legatus/qt5-before/dlbo/Lts/Proxies/Buildings/BuildingControlUnit/VWM
torstenandCopilot 7173785915 Qt6 Migration: Complete migration with DDS/RTI support and build validation
Major Changes:
- Merged latest Qt5 devel content from dlbo (292 files changed, 7 new dirs)
- Consolidated forward-declarations and include folders
- Removed unneeded modules per Niklas' repo check list

Build System Fixes:
- Fixed CMake VERSION_GREATER syntax in ParticipantManagement/CMakeLists.txt
- Added VLC packages (libvlc-dev, vlc-plugin-base) to docker_build.sh
- Added PostgreSQL dev packages (libpq-dev, postgresql-server-dev-all) to Dockerfile
- Fixed locale warnings (ANSI_X3.4-1968 → C.UTF-8)
- Fixed ArcGIS SDK path warnings when BUILD_ARCGIS=OFF

Code Generation Fixes:
- Fixed IDL enum collisions (PortType→CorePortType/DdsutPortType, PdmEventType)
- Fixed Grantlee template svc_translation.cpp.grantlee:
  - Changed {{ idl_enum.name }}_def:: to {{ idl_enum.name }}::
  - Fixed .underlying() calls for C++11 scoped enums (enum class)
- Removed generated files from repo (moc_*, *_dtc.h, *_ftc.h)

Validation:
- BUILD_RTI=ON: SUCCESS
- BUILD_RTI=OFF: SUCCESS
- C++17 standard maintained for RTI 7.7 compatibility
- Ubuntu 26.04 Docker environment verified

Remaining Warnings (expected):
- BgViewer, KDChart, KDReports, Poppler-Qt6 not found (optional features)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-09-15 18:20:26 +00:00
..

# @RDE_HEADER@
# $Id$
# $HeadURL$
# $Author$

https://devhub.defence-elec.de/jira/browse/GUEZE-688 U-Bahn: AWES ohne Wirkung

https://devhub.defence-elec.de/jira/browse/GUEZE-688?focusedCommentId=119903&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-119903

Stand 06/2021:
==============
Also, bei BT56 ist vor geraumer Zeit aufgefallen, das AWES auf das Dach seine Wirkung zwar entfaltet hat, die Wirkung aber im EG seinen Ursprung nahm.
In dem Zuge hat Christian Ehrlicher (so Philip Dassow) den Algorithmus angepasst. Es wird dann nach der nearest wall gesucht...
Damit wurde aber nicht nur AWES auf das Gebäude beeinflusst, sondern auch AWES neben das Gebäude. Der Source Code suggeriert, das dieses nicht unbedingt gewollte war... ("Detected hit was outside of the building - ignored" @ vwm_api.cpp)

Um die Wirkung von AWES neben das Gebäude zu berechnen (z.B. U-Bahn-Tunnel), wird der AWES-EinschlagOrt (z-Wert von "0") in der Koorinatensystem des Gebäudes verschoben. (BuildingProcess::sendCesHitOnBuilding). Die impactPosition bekommt dadurch einen z-Wert von ca. -90m, da Schnöggersburg bei 90m Höhe liegt.
Jetzt wird also die nearest Wall zu der (rel.) impactPosition gesucht. Dabei sind die Keller-Etage näher, als die Einstiegsgebäude - unglücklich.
Um bei der der Suche (Api::onHitCes) eine sinnvolle Wall (und damit room) zu finden, wird der z-Wert auf "1" gesetzt ("posImpactOnGround"; bei "0" würde dennoch eine unterirdische Wand gefunden, daher "1"). Somit wird dann eine passende Wall/room gefunden und der "direction"-Vector in die Hit-Structure eingetragen.
(Dabei wird noch die 3-dimensionale BoundingBox (bottomLeft, topRight) der Wand ermittelt, um Rundungsprobleme zu eleminieren.)

Somit wird für den Tunnel oberirdisch gesucht und gefunden - zumindest bei Einschläge neben die Einstiegsgebäude. bei Einschläge zw. den Einstiegsgebäuden (z.B. bei Raum 122) sollte der eine lange virtuelle Raum (derzeit "208") oberhalb von 116-129) gefunden werden. Die nearest-wall-Suche basiert allerdings "nur" auf den Stützpunkten der wall. Und die Stützpunkte von Raum 122 sind näher dran, als die von 208.
-> der virtuelle Raum oberhalb der begehbaren Räume 116-129 sollte analog zu diesen aufgeteilt werden. Für 104-112 gilt das gleiche.

Wie können Räume wie 122 unterhalb der Erdoberfläche stärker von AWES geschützt werden?
Dabei könnte man den (in Api::sendHitToVwm) den z-Wert des direction-Vectors nutzen. Bei U-Bahn-Tunnel führt dies z.B. zu ca- "-5" Meter.
Bei der Kanalisation funktioniert das nicht. Der Referenzpunkt des U-Bahn-Tunnel ist an der quasi an der Erdoblerfläche. D.h. unterirdische Räume (1nn, 2nn) haben neg. z-Werte, während 3nn positive hat.

Bei der Kanalisation ist der Referenzpunkt unten, es gibt keine neg. z-Werte!

Auch aufgrund der große Ausdehnung ist der Ansatz über den z-Wert der direction fragwürdig.

Und was ist mit dem Tunnel in Salchau?

Dieser Tunnel hat gar keine Wände! Daher bleibt die nearest-wall-Suche erfolglos. Der Tunnel erfährt keine Zerstörung. Auch mit mit einem Einschlag in den Brunnen keine Zerstörung erzielen...