Nein SCASM meine ich nicht damit, denn SCASM ist ja kein Dekompiler sondern ein Kompiler der aus einem speziellen Textcode SCA die BGL erstellt. Ich beziehe mich auf diesen Text von Dir aus einem aktuellen Thread:

"Ausgangspunkt SDK 2002 derzeit leider noch hier:
http://www.microsoft.com/games/flig...wnloads_sdk.asp
Werkzeug findest du hier:
http://www.scenery.org/design_utilities_a.htm
Dann analysierst du die BGL Datei und stellst sie in Textformat dar. Anschließend löscht du alles was du nicht brauchst und compelierst es wieder in eine BGL Datei. "



Eine BGL Datei dürften die wenigsten mittels FS2000/2002SDK analysieren können und in ein Textformat nämlich hier in den SCASM SCA Code umstellen können. Ergo sprichst du mit dem Werkzeug offensichtlich ein Tool an, welches in der Lage ist eine BGL zu dekompilieren und z.B in den SCA TextCode zu übersetzen. Einen Scenerdekompiler halt. Dann soll der User hier das was er nicht benötigt (insofern er diesen SCASM Textcode SCA interpretieren kann) löschen. Anschließend soll er diesen manipulierten Code jetzt mit dem erwähnten SCASM Kompiler von Manfred in eine neue BGL kompilieren.

Genau das hast Du mit deinem Text beschrieben, bei mir jetzt nur genauer aufgedröselt. Also nutzt Du doch einen bestehenden Scenerydekompiler. Und diese bestehnden haben halt doch größere Fehler die ich nicht akzeptieren würde.

Mit da Du Fehler des Scenerydekompilers akzeptierst meinte ich eben folgendes. Der Programmierer der ein ADDON produziert erledigt dieses in grafischer Form z.B über das SCC (Schiratti Control Center). Beim Kompilieren werden aus grafischen Vektordaten enstrechend dem was man programmiert (Poly, Runway, Strasse usw.) bei der Kompilierung zunächst der nicht ganz leicht verständliche SCASM Texcode SCA erzeugt. Hier bei entstehen zum Teil erste geringfügige Fehler (Rundungen) bei der Vektorumsetzung. Im SCASM Code selbst lässt Manfred Moldenhauer (der Entwickler von SCASM) unter anderem komfortable Dezimalwerte mit Nachkommastelle zu. Wenn dann aber dieser SCASM Textcode SCA in die BGL mittels SCASM kompiliert wird, muß er in einen entsrechenden SDK kompatiblen Code kompiliert werden. Hier sind keine Dezimalreste zulässig. Es werden jetzt Dezimalreste oft in bestimmte Fractionalteilerwerte umgerechnet um in ein bestimmtes Byteschema zu kommen welches wie gesagt die wenigsten User verstehen würden. Eben dieses Byteformat und noch ein paar andere komplizierte Sachen werden in der Regel im Scenery SDK beschrieben mehr nicht. Daher können die wenigsten mit einem SDK etwas anfangen außer in der Regel Programmierer die Designtools programmieren. Es gibt auch ein paar leichter zu verstehende SDKs die dann aber auch nicht diesen Informationsinhalt haben.

So bis hierhin haben wir nun den Weg der Erstellung eines Sceneryaddons beschrieben. In diesem Weg kann ein Scenerydesigner aber schon selbst ein gewisse Fehlerquelle von z.B Rundungsfehlern eingebaut haben. Es sei denn er hat Dezimalreste so geschickt angegeben das es bei der Umsetzung in Fractionalwerten zu möglichst wenigen Fehler gekommen ist.


Jetzt kommst Du mit dem Analysieren ich gehe jetzt davon aus da Du auf Tools verweist, das Du einen Scenerydekompiler meinst der diesen Textcode erstellt. Und eben genau diese bisher verfügbaren Dekompiler arbeiten wieder sehr ungenau sie haben ev. sogar absichtlich starke Fehler beim Dekompilieren drin. Sie setzen z.B Fractionalwerte nicht sauber in Dezimalreste die jetzt z.T 5 stellig sein müssten nicht sauber um. Oder sie dekompilieren generell bei gewissen Information falsch. Und schon hast Du beim Textcode selbst schon starke Fehler drin. Da wurstelst Du jetzt noch drin rum veränderst ev. etwas. So nach getaner Arbeit nimmst Du Dir den bearbeiteten Textcode und kompilierst ihn mit SCASM wieder zu einer BGL und schon hast Du etliche Fehler drin die zunächst vielleicht nicht stören aber doch je nach Sceneryinformation stark negativ auffallen. Das meinte ich mit akzeptieren von deiner Seite denn exakt diesen Vorgang hast Du in deinem Text mit wenigen Worten beschrieben. Da Du dieses akzeptierst und dann den SCA TextCode vorliegen hast könntes Du dann mit SCMOVE die Scenery verschieben offensichtlich aber nicht drehen falls dieses nötig wäre. Wie der Rest abläuft weist Du ja offensichtlich. Ich kann wie gesagt niemanden empfehlen die Fehler eines Scenerydekompilers zu akzeptieren. Man sollte sich dann das SDK anschauen und selbst den Byte Code verstehen lernen um für private Zwecke (nur da ist es zulässig) was zu ändern.

Muss ich dir absolut zustimmen und gebe dir natürlich recht. Man merkt diese Ungenauigkeiten relativ bald und dies ist ja sicherlich nicht Sinn und Zweck von Änderungen und man kann dies ja sehr schön überprüfen.
In seinem Fall dachte ich käme er sehr schnell zu einen Erfolgerlebnis, es handelt sich ja nur um ein Gebäude.
Welchen einfachen Weg würdest du im vorschlagen, um die bgl Datei zu ändern?
Horst

Um die BGL zu ändern. Für jemanden der keine Ahnung vom SDK und der Bytestruktur hat bleibt wohl nur diese Möglichkeit. Nur dann sollte man mindestens ein bischen Ahnung vom SCASM Code haben sonst ist auch das mit dem Dekompiler/Kompiler auch fast sinnlos. Ich habe diese Wienscenery nicht um die es da wohl geht. Gab es da nicht sogar einen Patch für. Ansonsten würde ich da wo es geht transparente Texturen empfehlen. Die lassen sich einfacher erstellen. Die BGL lädt zwar alle Objekte aber man sieht sie nicht. Ist der gleiche Effekt aber einfacher als in lizensierten BGLs rumpfuschen. Man stört damit niemanden ja man könnte die Transparenztexturen sogar weitergeben.

Nachteil wäre nur das sich die Performance nicht verbessert was der Fall wäre wenn man in der BGL Objekte löschen würde. Und natürlich das ein Flugzeug ev. in so ein unsichtbares Objekt crashen könnte wenn man sehr tief durch die Gegend fliegt.


Zu Flieger Horst noch mal Dein Text:
"Durch die Fototexturen und v.a. die wahnsinnig hohe Mesh-Auflösung
ist jeder noch so kleine Hügel ausgebildet - und das wirkt so plas-
tisch, so dass man getrost auf autogen verzichten kann"

Ich habe den LOD Level des Mesh noch nicht ermittelt er wird aber eh nicht höher LOD9 dargestellt, er kann sogar niedriger sein. Er ist also nicht wahnsinnig hoch, sondern wäre dann im üblichen Rahmen von ADDON Mesh Files. Der LOD Level scheint aber bei den Einzelteilen der Megascenery nicht überall gleich hoch zu sein. Auch habe ich mehrere Stellen gesehen wo man eindeutig Schattenwürfe in der Fototextur entdecken kann, hier müßte also ein hügelieges, zerklüftetes Gelände existieren. Tut es aber nicht es ist nur ein runder Hügel. Aber ansonsten hast Du recht im Gebirge passt Gelände und Schattenwurf sehr gut zusammen das sieht toll aus. Und ich habe aufgepasst ich habe meinen FS wieder so eingestellt das er Mesh überhaupt mit einer hohen Auflösung einstellt.

Denn hier kommt eine weitere Unverschämtheit der Megascenery. Es nimmt bei den Installer langsam überhand. (gut wenn man vorher das Handbuch ganz genau gelesen hätte, hätte man es vorher gewusst, schlecht wer da nicht gut Englisch kann) Denn was machen die hier ohne beim Installer groß drauf hinzuweisen. Es werden die FS9.CFG aller in XP angemeldeten User auf Ihre persönlichen Werte gesetzt um eine möglichst gute Performance im FS zu erzielen und das ohne wenigstens eine Sicherungskopie anzulegen. Das Mesh stellt man gleich auf einen schlechteren Wert ein. Ich denke da hätte man aber schon ein bischen deutlicher vor warnen können und mindestens eine Sicherungskopie anlegen können.

Ansonsten wen es interessiert. Die Megascenery ist meiner Meinung nach nicht auf dem Niveau der Real Germany was Texturen betrifft. Ein Umstand der auf das Rohdatenmaterial von Satelliten zurückzuführen sein dürfte. Wie sie im Vergleich zur Giga Scenery dasteht weis ich nicht da ich die GIGA nicht habe.

Zu den Nachttexturen. Es ist schon toll das es sie überhaupt gibt. Sie sehen auch toll aus. Haben zwar nicht das Niveau der Defaultnachttexturen hinsichtlich Position und Lichtquellen. Straßenoberflächen sind grünlich da wo kein Lichter stehen also Autos fahren würden. Haben aber mehr Farben als die Defaulttexturen und das ist realistischer als bei den DefaultFS Texturen. Die Nachttexturen passen allerdings nicht zu den Tagestexturen, kann man sehen wenn man die Texturüberblendung aktiviert (die sie natürlich auch abschalten) und auf eine Übergangszeit wie Morgengrauen geht. Dann sieht man nämlich das auch da wo große Gebäude stehen auf dem Dach die verschiedensten Lichtquellen unpassend rumstehen und zwar die selben die man sonst auch wo anders außerhalb von Gebäuden findet.

Aber wie gesagt wenn man daruf nicht achtet oder nur bei Tag oder Nacht fliegt bzw. die Texturüberblendung abschaltet sieht das schon toll aus.

Abweichungen bei Airports hinsichtlich Foto und Defaultairports gibt es aber doch einige genauso wie bei RG1.