Ich habe noch etwas Wichtiges vergessen:
DANKE an AROE,
ohne Euch hätte ich gar nicht gewußt, was man am Wochenende noch so machen kann.

Mhm, Respekt vor deiner Arbeit, wirklich... wenn du's echt schaffst, das richtig zu stellen, was die Entwickler selbst nicht geschafft haben, kann ich nur sagen, "Hut ab"! *anerkennendnick*


Aber vergiss nicht... es zwingt dich keiner, das zu tun ;)


und @Thorsten:
Dich hab ich ja nicht unbedingt angesprochen vorhin ;)

und @Umfrage... ich find die Leute witzig, die für "Hab`s nie gehabt!" mitgestimmt haben http://www.haus-air.at/smileys/chen.gif

lg,
Chris :-)

Ok, kein Thema. :-)

Nicht falsch verstehen. Das was der Dekompiler als Fehler meldet sind nicht unbedingt Fehler. Der Dekompiler kann ev. funktionsfähigen Code nur nicht interpretieren.

Folglich fehlt der Dir später bei der Kompilierung in eine neue BGL.

Du glaubst dann es wurden die Fehler im ursprünglichen Code ausgemerzt.

In Wahrheit fehlt Dir jetzt Code.


Wie gesagt das kann man auch schön bei älteren Objektcode nachweisen.

Es gab da diverse Kompiler die Objektcode nicht korrekt umsetzen.

z.B BGL Analyze hat auch diverse Fehler in der Umsetzung.

Wer weis, was Dir jetzt fehlt. Das kann man bei solch flächenmäßig großen Files nie wissen.

Aber wie ich erwähnte ev. waren es nur bewusst eingesetzte Stolperfallen die jetzt wie Du sagst einfach nur fehlen. Sprich der Code ist in Ordnung.


Ich wollte auch nur auf diesen Sachverhalt hinweisen, weil er auftreten kann.

Hi,

auf Svalbard ENSB gibt es ein ähnliches Problem wie mit Usedom:

http://img409.imageshack.us/img409/8124/svalbard0wx.jpg

Hallo,
Ich warte ja immer, bis ein Produkt (Flusi Addons, seit wann?) halbwegs fertig ist, bevor ich so etwas kaufe.
Außer zwei theatralischen "Faschingsscherz" – Beträgen, habe ich noch immer nicht erfahren, ob es jemals Updates gibt.
Anscheinend ist tatsächlich Fastenzeit.

@ rolfuwe

Nebst Sbuilder (für simple Veränderungen) (und ja: man kann auch simpel aus Polygonen Linien machen ;) – falls du auch noch Uferlinien haben willst, was bei Flugwerk anscheinend nicht funktioniert) gibt es auch LWMViewer2 von Jim Keir für simple Objektverschiebungen.
Aber zuerst würde ich die original Daten von den CDs zuückkopieren.

Ich habe keine AROE Daten, deshalb kann ich dir nicht weiterhelfen.

Mit der Verteilung: Solltest du mit Flugwerk oder FSQ (keine Ahnung) Rücksprache halten, da du die Daten 1:1 verwendest.
Es sind nicht deine Daten, auch wenn du sie bezahlt hast.

Horst

Und was macht AROE mit dem Deutschen Eck (SG1)in Koblenz?

Es bricht wie eine Eisscholle in den Rhein ab. Grässlich!

@JOBIA
Der Compiler macht trotz Fehler eine BGL.
Wenn man diese BGL wieder öffnet sind die Fehler verschwunden.

@Chris
Den Dank reiche ich zum großen Teil an Dietmar Frenzl weiter. Er beschäftigt sich hauptsächlich mit Scenerien und deren Bearbeitung und kennt sich in der verfügbaren Software sehr gut aus. Ohne seine Vorarbeit hätte ich nie eine AROE-Datei aufgemacht und bearbeitet.

Uwe

@ Horst LOWW
FSQ hat noch nie auf meine Anfragen geantwortet.

Mit SBuilder kann man LWM (Land/Wasser), VTP-Poligone und Linien editieren und neu malen.
Das sind z.B. die Texturen wie in LC mit und ohne Autogen oder Straßen, Uferlinien usw. und vieles andere.

Deutschen Eck (SG1)
 

Da hat SG1 ungenaue Koordinaten benutzt.
Viele Scenerieentwickler benutzen AROE auch weil sie mit hoher Genauigkeit SceneryObjekten positionieren können. Wen der FSX mit genauen Koordinaten arbeitet, ist man mit AROE auf der sicheren Seite. Die viele anderen Payware (SG usw.) stimmen dann auch nicht. Wird dann auf Microsoft oder SG geschimpft??? Das mit AROE mache ich nur, weil, egal was es ist, wenn`s Fehler hat, wird gefummelt.
Uwe

Du musst das so sehen. Der Dekompiler wertet die BGL aus. Er bringt eine Fehlermeldung weil er Code nicht interpretieren kann. Dieser Code kann nicht in Quellcode den man später kompilieren kann umgesetzt werden.

Jetzt kann es sein, dass der Dekompiler sich nicht dran stört er arbeitet stur weiter setzt alles was er noch umsetzen kann um.

Sprich Du hast jetzt ein Quellcode von den Daten her die der Dekompiler erfolgreich umsetzen konnte.

Das was er nicht umsetzten konnte also das was die Fehlermeldung auslöst fehlt jetzt einfach.

Logisch das dann das was erfolgreich in Quellcode umgesetzt werden konnte später wieder erfolgreich in die BGL umgesetzt werden kann.

Nur es fehlen Dir jetzt ev. Informationen die im ursprünglichen Code noch enthalten waren.

Bei flächenmäßig riesigen Files fällt das nicht auf.


Am besten ist Du dekompilierst machst am Quellcode garnichts weiter und kompilierst neu.

Dann vergleichst Du den Bytecode der Dateien wo die Stellen sind.


Frage kannst Du mir mal eine AROE Datei nennen mit der Du dieses Problem hast.

Kannst mir ja mal diese Datei per Mail schicken an jobia@t-online.de

Ich habe AROE ja auch von daher dürfte es auch kein Lizenzproblem sein.

Kannst mir mal mitteilen womit Du überhaupt arbeitest.

@Uli, schau mal bei den Screenshots von den German Landmarks nach:

http://www.cr-software.com/de/VFRObjects1_03.htm#

Uwe,
sei mal im verteilen unseres Nordafrikapatches etwas vorsichtig, das könnte rechtliche Probleme auslösen!

Die Fehler sind nicht beim Decompiler zu suchen, denn AROE hat auf "etliche" LWM-Wasserpolygone noch Areafills in LOD 10 und LOD 11 drübergepackt, möglicherweise durch ihren Automatismus bedingt. Die werden auch ordentlich, ohne Fehler eingelesen.
Das sind die Stellen, die der Compiler dann hinterher bemeckert, ein schlaues Bürschen also.
Du hast also unseren Nordafrikapatch getestet, in diesem Bereich keine Fehler mehr festgestellt, wie siehts aber mit Süditalien, Sardinien, Malta und den restlichen Inseln aus?
Weiterhin bestehen hier widersprüchliche Aussagen, ob AROE was im Afri Szenerieordner verändert hat. Dann wäre mein Default-Nordafrikapatch weiterhin notwendig.

Wenn das alles funzen sollte, könnte ich FSQ mal ein faires Angebot machen. Die schicken mir ein Packerl mit der AROE-CD drin und bekommen dafür unseren Nordafrikapatch. Das werden die aber nicht tun, denn wie sagte hier der Support-Manager: Wir sind Kaufleute und Flusifreunde gibts in diesem Geschäft nicht. Oder so ähnlich.

Eigentlich brauch ich AROE nicht, wegen SG3, ich könnte das Programm aber auf meinen Laptop aufspielen, dort ist der Flusi in Deutsch drauf, da ist auch "eine" FS2004 DVD mit dabei und die FS9.exe hat die gleiche Dateilänge wie der deutsche "No-CD Crack". Dann könnte ich mit großer Sicherheit weitere "Fehler", wie Gebäude auf RWYs, usw beseitigen. Ich hab da so meine Vermutung, was da schief läuft.

Irgendjemand schlug hier mal vor, Länder an- und abschaltbar zu machen, das wird wohl wegen des enormen Aufwandes wohl ein frommer Wunsch bleiben.

Uwe, ich kann Deinen Ärger über die "unausgereiften" Areale in AROE gut nachvollziehen, das, was wir für uns machen und berichtigen geschieht im stillen Kämmerlein, dieses aber in die Öffentlichkeit zu bringen ist eine rechtlich andere Seite.

Cheers,
Dietmar

Genau so sieht es aus.

Was mich besonders freut hier zu lesen, dass jemand eine FS2004 DVD Version besitzt die eine FS9.EXE hat die vom Bytecode offensichtlich identisch mit der NOCD EXE ist.

Da gab es solche Andeutungen, wo man eigentlich nie sicher sein konnte ob es stimmt.

Demnach kann man es aber als offiziell stehen lassen. Es hat nie einen NOCD Crack gegeben. Es ist eine offizielle FS9.EXE aus dem Hause Microsoft.

In dem Zusammenhang ist auch noch interessant, daß sowohl die deutsche DVD fs9.exe die gleiche Bytelänge hat wie der US No-CD-crack, nämlich 516096 bytes.
Die Übersetzung in die Landessprache wird durch die language.dll vorgenommen, deren Länge ist für die jeweiligen Versionen auch unterschiedlich.

Die originale fs9.exe mit der CD4 Abfrage hat in der US-Version 1394659 bytes, 878563 bytes werden also nur dazu verwendet, ob die CD4 ins LW eingelegt ist, mehr als das eigentliche Programm.
Irgendwie Verschwendung, bei bundles mit dem Laptop verzichten die doch auch drauf.

Hi Dietmar,

das war neulich mal mein Vorschlag...

Ich denke, es würde schon reichen, wenn die Landesgrenzen dabei so in etwa eingehalten würden. (Zumindest solange ich keine Add-Ons direkt in den Grenzgebieten installiert habe...)

Natürlich wäre es ein sehr großer Aufwand, alle Straßen direkt an den Grenzen "abzuschneiden" (und dabei die Grenzen exakt einzhalten) und in verschiedene Dateien zu packen...

Wie heißt der Spruch: Man soll die Hoffnung... :-)

Bis denne

Bernd

Ich habe noch einen besseren Screenshot vom Deutschen Eck von Rolf bekommen:

http://img313.imageshack.us/img313/3238/deck2tj.jpg