![]() |
Fehlerhafte Standardscenery korrigierbar?
Hallo Forum,
die Graspiste in EDNP (Pfarrkirchen) wird im fs9 leider sehr unschön von einem Fluss getrennt. Da ich in der Gegend wohne, kann ich mit Sicherheit sagen, dass die dortigen Segler beim Landen nicht durch den Fluss fahren müssen ;-) Meine Frage: Gibt es eine Möglichkeit -mit Hausmitteln bzw. Freeware-Tools- diesen Fehler zu korrigieren und den Fluss in diesem Bereich dahin zu verschieben, wo er hingehört? Danke im Voraus für jeden Tipp, Fred |
Probier's mal mit Afcad
|
Hi,
Afcad hab ich, und auch schon mal (nach Anleitung) einen Tower-Viewpoint erstellt. Ansonsten hab ich keine Erfahrung mit dem Programm. Kannst Du mir eine -kleine- Hilfestellung geben? Was korrigiert man mit Afcad? Die Bahn oder den Fluss? Grüsse, Fred |
Sorry ich kenn mich da auch gar nicht aus.
Ich hab nur vor kurzem gesehen das man mit Afcad sogar ganze Flughäfen erstellen kann. Bahnen verschieben dürfte dann auch kein Problem sein, und es müsste auch für afcad ein Tutorial geben. |
Hi Fred,
habe eben mal in meinem default-FS9 nach der Graspiste von EDNP Ausschau gehalten, und siehe da, sie wird von der Rott (soll sie ja wohl sein?) nicht durchtrennt. Vielmehr verläuft der Fluß etwa 100-150 m rechts mehr oder weniger parallel zur RW07. So wie es auch in Google-Earth deutlich zu erkennen ist. Wenn also bei Dir die Runway durch das Gewässer geteilt wird, so ist dies kein Fehler des Flusi, sondern wahrscheinlich das Resultat irgendeines Addons in diesem Gebiet, mit dem der Flußlauf "korrigiert" wurde. Mit Afcad könnte man da gewiß etwas nachhelfen, nur müßte neben der Verlegung der Runway ja auch eine flatten-Datei für das künftige Terrain erstellt werden, denn sonst wird es auf der neuen Piste doch arg holprig. Und genau an diesem Punkt muß ich leider passen. Kenne mich zwar recht gut mit dem Afcad-Programm aus, aber mit dem flattening habe ich mich noch nie befaßt. Aber vielleicht findet sich ja noch eine hilfreiche Hand. Oder Du machst selbst den Verursacher der "Flußverlegung" ausfindig und deaktivierst oder löschst ihn. Gruß Erich P.S. Hier noch das Bild der default-Scenery http://img84.imageshack.us/img84/3025/fsscr003at0.jpg |
Hallo Erich,
vielen Dank für Antwort und Screenshot. Eindeutig ok so! Die Fehlersuche dürfte interessant werden: Ich hab einiges an Addons installiert, aber räumlich ziemlich weit entfernt (gäbe es was für Ostbayern, hätte ichs ;-) Ich hab selbst etwas mit Afcad gespielt und konnte problemlos die rwy verschieben. Nur: Der obligatorische "Grasstreifen" um die Runway bleibt an Ort und Stelle. Meine verlegte rwy liegt nun an dessen Rand und das sieht wirklich sehr dämlich aus. Weisst Du denn, wie dieser Streifen im FS festgelegt wird und ob/wie man ihn verändern/verlegen kann? Das Flattening wäre dann der nächste Schritt. Oder ist der Grasbereich um die rwy und das durch die flatten-Datei festgelegte Gelände ein und dasselbe? Gruss aus München, Fred |
Hallo Fred,
mit dem Thema Szeneriedesign habe ich mich leider bisher kaum befaßt, so daß ich Dir diese Frage nicht verbindlich beantworten kann. Ich gehe aber davon aus, daß man bei der Konstruktion dieser flatten-Datei auch die erforderliche Bodentextur einbinden kann, es sich also um einen Vorgang handelt. Vielleicht findet sich ja noch jemand, der Dir seine Hilfe bei der Korrektur anbietet. Tschüß Erich |
Hier übrigens noch meine derzeitige Ansicht von EDNP (nach der kleinen Änderung durch Afcad...):
http://img374.imageshack.us/img374/3172/ednpyj9.th.jpg Gruss, Fred |
Hallo Fred,
Dein Screenshot deutet darauf hin, dass Du für diesen Bereich ein modifiziertes Landclass-bgl-file installiert hast. Das könnten für Deutschland z.B. die Landclass-Dateien von Frank Barth sein. Einfach mal schrittweise alle verdächtigen Szenerien im FS2004 deaktivieren und die daraus resultierenden Veränderungen prüfen. So läßt sich der Fehler zunächst eingrenzen und letztendlich lokalisieren. Es kann aber durchaus sein, dass die jetzige Darstellung bei Dir genauer und zutreffender ist, als die Default-Szenerie. Wenn das der Fall sein sollte und der verschobene Airportuntergrund sehr stört, müsstes Du Dich intensiver mit einem Szenerieeditor für Landclass-Dateien (z.B. Ground2k4 von Christian Fumey) beschäftigen. Viel Erfolg bei der Suche der LC-Datei Claus-Peter |
Zu
Zitat:
Landclass Dateien haben rein garnichts mit Grasrunways von Airports oder diesem gezeigten VTP Linienfluss zu tun. Landclass ist also bei diesem Problem komplett außen vor und hat mit dem Fehlerbild nichts zu tun. Ich habe es im default FS nicht kontrolliert aber wenn Erich recht hat und es in seinem Default FS nicht existiert, dann wird es ein Addon sein was das Problem verursacht. Es kommt also nur eine falsch positionierte Addon Runway oder ein falsch positionierter Addon Fluss in Frage. Ich würde daher zunächst die Default Westeuropa Scenery abmelden. Das ist eine FS default Scenery die Deutschland enthält. Hier spielen zwar auch sehr viele Addons daten ein. Aber zum testen sollte man das schon mal ausprobieren. Denn nun sollten alle Default Airports aber auch Defaultflüsse hier weg sein. Wenn nicht kommen diese Elemente durch eine Addonscenery. Ist alles weg, dann schlummert diese Änderung die im Default FS regulär nicht existieren soll in der Default West Europa. Dann hat ein Addon hier manipuliert Bleibt aber ohne West Europa eine Runway oder Fluss übrig, dann ist es von einem Addon welches eigenständig angemeldet ist. Jetzt brauch man eigentlich nur die potentiellen Addons abzumelden bis auch dieser Addonfluss oder Addonairport verschwunden ist. Schon hat man den Störer. Wichtig ist das natürlich der FS Änderungen in der Scenerybibliothek nur nach Neustart übernimmt. |
Ob hier nun ein Addon aktiv ist oder nicht, die Frage ist doch was hier an der falschen Stelle ist -- der Fluss oder der Flugplatz.
Ich habe mir den Platz mal im FS mit Ultimate Terrain Europe angeschaut und mit Google Earth verglichen. Die Bahn scheint ziemlich gut an der richtigen Stelle zu liegen (Grasbahnen sind ja nicht unbedingt so in den Flughafendaten enthalten und können sich ja auch verändern). Hier ein Bild: http://i2.photobucket.com/albums/y41...kirchen-UT.jpg Die Gewässer, Straßen, die Eisenbahnlinie und der Golfplatz kommen von UT Europe. Die Landclass ist von Frank Barth. EDIT: SORRY!! Ich habe grade erst gesehen, dass bereits vorher schon gezeigt wurde, dass der Fluss nicht aus der Standardszenerie ist, mein erster Absatz ist also überflüssig. |
Zur Info diese Rasenpolys um die eigentliche Runway drum herum haben nichts mit AFCAD kompatiblen Code zu tun. Es handelt sich bei diesen Rasenflächen um VTP Polygoncode der in ganz anderen BGL Files abgelegt ist.
Möchte man diese auch manipulieren muss man zusätzlich zu AFCAD mit Tools wie z.B Ground2K arbeiten. Es gibt wenige Airports im FS2004 die hat Microsoft falsch positioniert. Sie haben Koordinaten die sich nicht auf das geodätische Datum WGS84 beziehen als WGS84 Koordinaten ausgelegt. In einigen Airportkartenwerken in Deutschland findet man auch das geodätische Datum ED50 legt man das als WGS84 aus passt es nicht mehr. Dieser Fehler den Microsoft selten begangen hat, kann man eindeutig nachweisen. Ich vermute hier aber auch eher das dieser vermutliche Addon Fluss falsch liegt . (was natürlich zu klären ist) |
Hallo Leute,
vielen Dank für Eure Hilfe! Am liebsten wäre mir natürlich ein Lösungs-Zweizeiler gewesen, aber jetzt weiss ich zumindest, dass man was machen kann. Mein nächster Schritt wäre nämlich gewesen, diesen kleinen Platz (der mir sehr am Herzen liegt) etwas auszubauen. Dafür wäre die jetzt fällige Arbeit mit den diversen Tools ohnehin nötig gewesen... Nochmal vielen Dank! Mal sehen, wie weit ich komme ;-) Grüsse, Fred |
Zitat:
Ich habe mich da auch etwas unglücklich und laienhaft ausgedrückt, da ich als ausgewiesener "Nichtszenerieexperte" alle Basisszenerieelemente wie Landklassen, VTP-Polygone, VTP-Strassen u.s.w. , die man mit dem gleichen Szenerieprogramm (das bereits erwähnte ground2k4) erstellen bzw. bearbeiten kann, immer in einen Topf schmeiße. Zitat:
Wenn man die geposteten Bilder von Erich (Standardszenerie), Lexif und Fred vergleicht, kann man m.E. eindeutig erkennen, dass hier 3 verschiedene Landclass-Dateien den Untergrund bestimmen. Standard-LC, Frank Barth-LC und ?????-LC. Diese unbekannte LC-Datei befindet sich vermutlich mit der VTP-Datei, die die geänderte Lage des Flusses bestimmt in einem gemeinsamen Szenerieordner. Der Airportuntergrund hingegen erscheint mir nach Vergleich der 3 Screenshots nicht von der Standard_Szenerie abzuweichen. Mit dem von Dir geschilderten Verfahren sollte der Fehler allerdings einzukreisen sein Claus-Peter |
Wegen meiner alten Aussage:
"Landclass ist also bei diesem Problem komplett außen vor und hat mit dem Fehlerbild nichts zu tun" und Deiner Reaktion darauf: Zitat:
Damit haben die verschiedenen Landclass Files rein garnichts mit dem Hauptproblem zu tun. Deshalb habe ich das erwähnt. Denn es hat sich so angehört, als wenn man nur das Landclassfile ermitteln muss, welches diese Optik erzeugt, dann hat man den Fehler Scenery Kandidaten. Dem ist aber nicht so, da das Landclassfile mit dem Problem nichts zu tun hat. Auch werden Landclassfiles die zu ein und dem selben Addon gehören speziell wegen des Speicherlecks oft von anderen Scenerien dieses Addons die z.B VTP Polys enthalten können getrennt. Von daher ist die Chance zu gering. Da bei Landclass auch fast immer mit der Transparenz LC 254 in einem LC File gearbeitet wird, wäre selbst wenn man die LC Scenery des Addon ausfindig macht welches diese Bodentextur Optik im Umfeld des Airports erzeugt noch lange nicht gewährleistet, das von diesem Addon auch VTP Poly oder ev. der Fluss stammt. Ich wollte nur verhindern, dass hier jetzt in die falsche Richtung gesucht wird. |
Hallo,
mit Ground2k kann man ein default-Flugplatz-"Grundstück" überdecken, wenn man dem neuen Rasenpolyglon eine hohen Level, z.B. 24, zuweist. |
Zu
Zitat:
Ist dann nur ein Byte im Code welches gesetzt wird und schon wird das Default Poly deaktiviert. Das hat gegenüber Deiner Variante zwei Vorteile. 1) Man hält sich an die Vorgabe Layerstruktur von Microsoft. Das kann nämlich sehr wichtig sein, wenn ein Addon wie z.B AROE oder was auch immer an so einen Airport eine real existierende VTP Zufahrtsstraße heranführen will. Ist diese nämlich in einem niederen Layer wovon man ausgehen kann, dann endet die abrupt an Deinem neuen Rasenpoly. Sie erreicht also den Airport optisch überhaupt nicht mehr. 2) Es kann ja sein, dass so ein neues Rasenpoly weil es reale Flächen haben soll ev. kleiner als ein vorhandenes Rasenpoly ist oder die Flächen zumindest nicht deckungsgleich sind. Dann sieht man bei Deiner Lösung beide flächenmäßigen Polyanteile. Selbstverständlich das mit höherer Priorität oben. Von daher wäre meine Lösung die sichere, wenn man denn überhaupt ein neues Poly erstellen möchte. Ich denke sinnvoller wäre es hier erst mal zu kontrollieren, was wirklich falsch ist. Wenn man das ermittelt hat, zu ermitteln wo das Falsche her kommt. Erst dann sollte man handeln. |
Hier meine Bearbeitung des Falles:
http://img522.imageshack.us/img522/1241/edspbd0.jpg Wo der Fehler lag, ist mir klar geworden, als ich die Default-Koordinaten des Flugpaltzes aus AFCAF mit denen aus Google-Earth verglichen habe. Der Default-Flugplatz ist nämlich um ca. 280 m in etwa 070° gegenüber GE verschoben. Wenn Sternhagel dann ein Addon hat, in dem der Fluss nach GE ausgerichtet ist, kommt es zu dem beschrieben Konflikt. |
ZU
Zitat:
"Es gibt wenige Airports im FS2004 die hat Microsoft falsch positioniert. Sie haben Koordinaten die sich nicht auf das geodätische Datum WGS84 beziehen als WGS84 Koordinaten ausgelegt. In einigen Airportkartenwerken in Deutschland findet man auch das geodätische Datum ED50 legt man das als WGS84 aus passt es nicht mehr. Dieser Fehler den Microsoft selten begangen hat, kann man eindeutig nachweisen." Ich denke ich schaue jetzt spaßhalber mal selbst wirklich nach. |
Leider ist in meinen digitalen Kartenwerken die Runway selbst nicht eingezeichnet. Da steht nur Sportflugplatz ohne genau Koordinate.
Auf jeden Fall kann man aber folgenden Sachverhalt nachweisen. Wenn man die FS Koordinate in den digitalen Kartenwerken als Ref Point nimmt und diese Koordinate auf das geodätische Datum ED50 bezieht, wandert der Aiport weg von dem Fluss Rott. Legt man diese FS Koordinate aber als WGS84 aus wandert er in Richtung Fluss Rott, was diese Problematik bestätigt. Microsoft scheint auch hier wie bei einem anderen süddeutschen Airport das geodätische Datum falsch ausgelegt zu haben. Der Aiport selbst ist also falsch definiert. Der Addon Fluss scheint richtig zu sein. |
Habe jetzt auch den Thread von damals gefunden als wir das Thema falsch ausgelegtes geodätisches Datum schon mal hatten. Es war im Zuge einer internen Mail Diskussion mit dem VFR Airfields Team Rolf Schon und Christoph Rieger aufgetaucht, als es um exakt ähnliches Problem im FS2004 bei Ihren Addons ging.
Später hatten wir das dann, weil es passt hier auch im FXP Forum erwähnt. Siehe: Antwort an Joachim hier z.B Rolf seine Anmerkung auf unseren damaligen internen EMail Verkehr: r_schon Elite Dabei seit: Oct 2002 Daheim in: Beiträge: 1273 Hallo Joachim, Ohne mich fachlich an der Diskussion beteiligen zu wollen ( besser zu können ). Das war Konstanz. Das hatten wir damals als nicht erklärbaren Mangel erkannt und Du hast dann herausgefunden, daß hier Geo Daten vertauscht waren. Im Übrigen, ich lese mit Interesse mit. Gruß Rolf |
Guten Abend, zusammen.
Vielen Dank für Eur vielen Antworten, da haben sich gleich mehrere Ansätze aufgetan. Mit schrittweisem Deaktivieren meiner Addons glaube ich jetzt, einen Zusammenhang gefunden zu haben. Interessanterweise nicht mit einer Bayern-Szenerie, sondern einer für Österreich und zwar einer professionellen. Diese erzeugt vier Einträge in meiner Szeneriebibliothek, u.a. Landclass und Mesh, doch das Deaktivieren des "Objects"-Eintrags macht den Unterschied. So sieht es mit aktiviertem Layer aus: http://img325.imageshack.us/img325/640/ednpmit1wi6.jpg Und so bei deaktiviertem Layer: http://img45.imageshack.us/img45/6561/ednpohne21vs7.jpg Es ergeben sich neue Fragen: 1) Wieso wird, wenn ich diesen Addon-Layer ausblene, mein Default-See mit ausgeblendet? 2) Was kann ich überhaupt noch tun? Verzicht auf die besagte Szenerie kommt nicht in Frage. Gibt es noch andere Optionen? Etwas ratlose Grüsse, Fred |
Wahrscheinlich hat die betreffende Szenerie die Default Szenerie in dem Bereich in dem sie aktiv ist deaktiviert indem die entsprechenden Dateien umbenennt.
Waren da nicht mal Berichte, dass Austria Pro bis nach Süddeutschland reinreicht? Hab die Szenerie allerdings nicht. Edit: Seh grad eben erst deine Screens -- wurden vorher wohl nicht geladen. Merkwürdig, dass die Default Szenerie da ist, der See aber "leer" ist. |
Zitat:
Diese Seen hier z.B der Addon See, sind so genannte LWM Polygone. Das M steht im Namen für Mask. ES sind also auch Masken. Technisch ist es so. Du hast oben eine weltweite Landclassschicht mit Ihren Texturen . Unten drunter liegt eine weltweite Waterclassschicht mit Ihren Gewässertexturen. Du hast also auch unter dem Matterhorn Wasser. So ein LWM macht jetzt hier nichts anderes als das es die Landclassschicht quasi ausstanzt, so das unser Gewässer zur Ansicht kommt. Was aber wenn nun ein Defaultsee falsch liegt. Da nützt es nichts, wenn ein Designer jetzt ein neues LWM einsetzt um hier einen neuen See auszustanzen. Denn das einmal geöffnete Defaultloch bleibt erhalten. Man muss es also zuvor verschliessen. Genau das wird dieses Addon machen. NUn es könnte hierzu mit LWM Technik arbeiten. Denn man kann im Code auch sagen, das so ein LWM nicht stanzen soll, sondern verschliessen. Weil es einfacher ist, manipulieren Addons aber oft gleich das FS defaultfile oder deaktivieren es durch umbenennen. Denn dann kommt der Defaultsee überhaupt nicht mehr zu Anwendung. Logisch, dass er dann fehlt wenn nun Dein Addon abgemeldet wird. Denn dieser deaktivierte See befand sich ursprünglich mal in der Default West Europa Scenery des FS. Musst mal in den entsprechenden Scenerypfad schauen. Nennt sich in ungefähr so: E:\FS2004\Scenery\Eurw\Scenery Dort wirst Du mit Sicherheit deaktivierte Default Files finden die nicht mehr nur .bgl als Extension haben sondern etwas manipuliertes z.B .off oder .bgloff oder sonstetwas. Das sind dann deaktivierte Defaultfiles die z.B Gewässer enthielten. Die Austria Prof. die vermutlich hier sogar für zuständig ist hat z.B 4 Defaultfiles auf diese Weise deaktiviert. Sie nennen sich z.B jetzt hp951140.bgl.AT4 Zu2) Wenn der Airport wirklich aufgrund eines Geodätischen Datum Interpretationsfehler von Microsoft falsch positioniert wurde, wäre es natürlich am sinnvollsten diesen zu verlegen. |
Moin zusammen,
Jobia: Zitat:
Fred: wenn du mir deine mall-Adresse gibst, schicke ich dir mal einen Lösungsvorschlag. |
Aus dem Kopf kann ich das nicht mehr, habe das letzte mal bestimmt vor 2 Jahren oder schon länger her Ground2K nicht mehr angefasst.
Habe es auch nicht mehr auf dem PC und keine Zeit dafür. Es sollte aber ausreichen dort ein VTP Poly an die korrekte Stelle zu zeichnen. Ich meine Ground2K unterstützte auch schon das positionieren über FSUIPC. Natürlich bei dem neuen VTP Poly den Layer wie die Defaultrasenpolys wählen und eine passenden LC die Rasentexturen ohne Autogen verwendet zuweisen. Dann konnte man meines Wissens irgendwo setzen ob dieser Code auch gleich das VTP Exclude enthalten soll. Dann nur noch in eine BGL kompilieren, ab in den FS natürlich höher positioniert als die Default Westeuropa, dass sollte es gewesen sein. Wäre schön wenn Dir hier jemand anders der aktuell mit Ground 2K arbeitet auf die Schnelle etwas zu sagen kann, denn ich kann es nur noch vom Prinzip erläutern. |
Alle Zeitangaben in WEZ +2. Es ist jetzt 17:57 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag