Ja das hatte auch einen Grund.
Mal ein Beispiel: SCASM Kompiler (den Bereich bis FS2002 Technik).
Diesen hatte Manfred ja anhand des SDKs programmiert.
Der SCASM Code der mittels Designtools erzeugt wird lässt bei Manfred z.B komfortablerweise Nachkommastellen zu bei den Runwayhöhen.
Im Scasm Code *.sca wird man diese wiederfinden.
Das ist für den Designer komfortabel.
Eigentlich ist das aber nicht ganz korrekt da der FS die Runwayhöhen Bytemäßig als Ganzzahl und die Nachkommastellen als Fractionalteilerwert abglegt. Die sind dann aber garnicht im Raster der Nachkommastelle also wird der nächst liegende Fractionalwert genutzt.
Peng der erste Rundungsfehler. Übrigends da LWM Technik und Runwaytechnik andere Fractionalteilerverhältnisse haben kann es hier sehr schnell zu Höhendifferenzen kommen.
(Flackergefahr von Bodenpolys)
Ok wir können im Bytecode so schon Abweichungen bekommen. Mit anderen Worten die BGls bekommen schon Fehler.
Das geht oft halbwegs gut ab.
Jetzt kommt ein Dekompiler liest die Bytes aus.
Er liest jetzt die Fractionalwerte aus.
So hat z.B Fractionalwert 1/256 (bei den älteren Runwaycodes verwendet) Dezimal die Wertigkeit 0,00390625. Nehmen wir mal an im Byte code steht bei einer Runway im Fractionalwert 127 dann ergibt das als reguläre Dezimalnachkommastelle den Wert 0,49609375
Übrigends LWM2 arbeiten mit Fractionalwert 1/128. Da habe ich damals im FS2002 (die Flackerdoku auf meiner Homepage die aber schon lange runtergenommen ist) einen Bug im FS2002 festgestellt. Durch den Bug konnte er nicht jeden Fractionalwert umsetzen. Das hatte zur Folge das schon Defaultairports von flackernden Bodenpolys betroffen waren.
Leider nehmen es die Dekompiler nicht so genau sie geben in der Regel gerundete Werte raus, weil das besser aussieht oder wie auch immer.
Auch AFCAD2 arbeitet hier nicht sauber wenn ich mich recht erinnere.
Alles Fehler die Auswirkungen haben könnten.
Ev. wurden die Routinen der Dekompiler nur auf eine Nachkommastelle getrimmt.
Unser dekompilierter SCASM Code hat also weder etwas mit den tatsächlichen Werten der BGL zu tun und auch nicht mit den eigentlich nicht richtigen dezimal Werten die der eigentliche Programmierer in seinem Desgintool gesetzt hat.
Die Fehler summieren sich was den dekompilierten Code betrifft auf.
Das war nur ein Beispiel für Fehler. Ich habe es jetzt nicht im Kopf aber ich meine mich erinnern zu können das die FS2004 Runways überhaupt keinen Ganzzahlwert mehr im Bytecode kennen. Bei ihnen wird die komplette Höhe also Ganzzahl und Nachkommastelle als eine einziger Fractionalwert abglegt. Müsste man jetzt mal schauen.
Ich hatte Rolf und Christoph gerade wegen der Flackerprobleme bei Verwendung FS2002 Runwaycode mit LWM2 (anderer Fractionalwert) empfohlen im LWM Raster zu blieben. Weiterhin eine gewünschte Nachkommastlle bei der Höhe im SCASM Code so zu definieren das sie direkt ohne Fehler im Fractionalwert umgesetzt werden kann. Auf diese Weise schliesst man Probleme schon im Vorfeld aus.
(Beim FS2004 Runwaycode nicht tragisch da dieser in Verbindung mit Mesh nichts auslöst)
Auf jeden Fall enstehen so Fehler. Diese und natürlich ev. doch der ein oder andere unbekannte Code (der nicht im SDK steht) lässt eine im schlimmsten Fall eine dekompilierte BGL umkippen.
Ein FS2002 Beispiel ist z.B auch folgendes . Einen Airport dekomiliert und wieder kompiliert. Keine Fehlermeldung alles prima sieht auch optisch alles OK aus.
Bei genauer Kontrolle ergibt sich aber das sämtliche Taxiwaybegrenzungslinien verschoben sind. Das ganz so stark das man es keinem anbieten kann.
Das nur mal so als Info was bei Dekomplilern rauskommen kann.
So hat z.B AFCAD2 Probleme mit der Höheninterpretation.
Es dekompilert ja auch.
Ich hatte das neulich erlebt da hatte der Croatia Probleme mit einem FS2002 Airport den er für den FS2004 nutzen wollte.
Hier konnte ich dann das Problem durch zusätzliche eigene Files beheben.
Hier habe ich dann direkt im AF2 File den Code geändert. Auch JABBGL hatte da Probleme.
|