Mesh-Konflikte, Flatten-Probleme

[torvald]

Hi,

ich habe Probleme mit - vermutlich irgendwelchen Meshkonflikten. Bei mir war kürzlich halb Spanien geplättet. Airports und Gewässer befanden sich auf hohen kegelförmigen Gebilden.
Durch Zufall habe ich dann entdeckt, dass die Datei "SRTM_3ARCSEC.bgl" aus der ISD-Freewareszenerie "Olbia VFR" schuld war. Das liegt doch in Italien! Wie kann denn eine so weit entfernte Szenerie mir Spanien verschandeln? Wie auch immer, nach Deaktivierung der Datei gings dann.

Jetzt hab ich noch mehr Gegenden gefunden, wo ich ähnliche Probleme habe (z.B. bei der Freeware "Alsace VFR V2".

Gibt es irgendeine Möglichkeit, ohne langes Probieren herauszufinden, welche Szenerien überhaupt in einer bestimmten Gegend geladen werden bzw. wirksam sind?

Danke für eure Hilfe.

Gruß, Daniel

[Martin Georg/EDDF]

Wie kann denn eine so weit entfernte Szenerie mir Spanien verschandeln?

Eine falsche geographische Koordinate in so einem File, und der Fehler ist da.

Gibt es irgendeine Möglichkeit, ohne langes Probieren herauszufinden, welche Szenerien überhaupt in einer bestimmten Gegend geladen werden bzw. wirksam sind?

Leider nein. Ein solches Tool suche ich auch schon recht lange.

[BC_Holger]

Hallo zusammen,

doch, so ein Tool gibt es, sogar zwei:

Da gibt es Jim Keirs LWMViewer: http://www.jimkeir.co.uk/FlightSim/LWMViewer.html

sowie das tmfviewer.exe Tool, das der FS2004 Terrain SDK beiliegt: http://www.microsoft.com/games/fligh...dk.asp#terrain

Beide Tools koennen Meshfiles sowie andere Landschaftselemente laden (Landclass, Strassen, Gewaesser, usw.). Jims Tool ist komfortabler, aber das TMFViewer Tool hat den Vorteil, dass man die Meshhoehen direkt ablesen kann.

Zum Abchecken von Meshfiles muss man wissen, das alle Meshfiles rechteckig sind und alle in ihnen enthaltene Daten angezeigt werden (es sei denn, ein Mesh mit hoeherer Aufloesung ueberdeckt dasselbe Gebiet). Es gibt also keine "durchsichtigen" Datenwerte. Wenn etwas falsch definiert ist, wird es auch so angezeigt.

Ich habe mal ein Screenshot vom TMFViewer mit einem korrupten Mesh angehaengt. Alles was dunkelblau ist, ist Seehoehe und das rote Rechteck oben rechts hat irgendwelche negativen Werte. Offensichtlich nicht zu empfehlen!

Ausserdem kann man bei beiden Tools per Cursor die sichtbaren Grenzen ablesen, damit also feststellen, ob das Meshfile im Interessensgebiet angezeigt wird. Bei LWMViewer kann man per Menu alle Default Landschaftsfiles dazuladen, so dass die Orientierung leichter faellt (im TMFViewer muss man File- und Foldernamen wissen).

Eigentlich sind diese Tools fuer Entwickler gedacht, sind aber auch fuer Endnutzer gut zu gebrauchen.

Ciao, Holger

[torvald]

Vielen Dank Holger für deine Mühe!
Die Tool werde ich gleich mal ausprobieren.

Gruß, Daniel

[JOBIA]

Zu

"Gibt es irgendeine Möglichkeit, ohne langes Probieren herauszufinden, welche Szenerien überhaupt in einer bestimmten Gegend geladen werden bzw. wirksam sind?"

Nein das gibt es eigentlich nicht.

Holger hat zwar recht mit seiner Aussage, dass man mit dem SDK Tool TMF Viewer bzw. LWM Viewer die Fläche solcher TMF Files beurteilen kann, auch deren Dateninhalt, aber das ist eigentlich nicht die direkte Antwort auf die Frage oben. Denn ob so ein Mesh, Landclassfile oder sonstiges überhaupt zur Anwendung kommt oder geladen wird, darüber sagen diese beiden Tools leider überhaupt nichts aus.


Was an einer Koordinate X/Y zur Anwendung kommt entscheidet der FS an einer eigenständigen Prioritätsregelung. So kommt es dann darauf an wie die Summe """aller""" im FS2004 aktiven Landclassfiles für diese Koordinate hinsichtlich Priorität in der Scenerybibliothek verwaltet sind.

Bei Meshfiles mit gleichen LOD Level gilt das selbe. Beim FS2004 wegen des Prioritätsbugs von der Logik umgekehrt. Umso niedriger das Mesh angemeldet ist umso höher die Priorität.

Bei Meshfiles unterschiedlicher LOD Level im gleichen Bereich kommt im Nahbereich immer das mit dem höchsten LOD Level zur Anzeige.

Gibt es dazu gleichwertige LOD Level Mesh Files muss auch hier beim FS2004 wieder der Prioritätsbug beachtet werden.

Diese Betrachtung bzw. überhaupt das Finden solcher Addondateien, dass können beide Tools nicht. Auch können sie nichts über die Priorität aussagen.

Über den Aufenthaltsort solcher Dateien auch nicht. Ausnahme LWM Viewer bei Defaultdaten einiger TMF Files.


Nun hat man aber ein Problem. Bevor ich ein LC oder Mesh File im TMF Viewer beurteilen kann, woher weis ich denn welches File ist überhaupt ein Mesh oder Landclassfile. In welchem Scenerypfad steckt es überhaupt.
Oftmals hat man solche Scenerien als eigenständige Addons angemeldet dann hat man Glück, dass ist des öfteren aber nicht der Fall.



Denn hin und wieder werden LC, WC oder Mesfiles von Addons irgendwo im FS2004 versteckt in Default FS Pfade untergebracht. Hin und wieder tragen sie auch keine verräterischen Namen wie z.B Mesh oder DEM. (Digital Elevated Mesh).

Wobei DEM in die Irre führen könnte. DEM wird z.B bei Flattenfiles in Area16N Technik bei Designtool SCC im Namen eingebaut.

Man könnte denken es handelt sich um ein Meshfile. Ist aber keines.

Ich habe auch schon Files mit LC im Namen gesehen, dass waren auch keine Landclassfiles.

Das bedeutet, dass man z.B bei mir im FS weit über 20000 Scenery.bgl Files als potente Störer hat. Selbst wenn man diese 20000 Files aufgrund eigenen Wissens auf nur noch 200 Files von Namen als Störer eingrenzen kann, dann bedeutet dieses 200 Files im FS and den unterschiedlichsten Orten aufzustöbern und anschliessend im z.B TMF Viewer öffnen. Das Verhalten der Priorität also was später überhaupt geladen wird, ist dann aber aufgrund eigenen Wissens zu treffen.

Wer das Wissen nicht hat, der kann dann aber auch nichts über deren Prioritäten aussagen.

So kann man z.B bei einer Custom Foto Scenery wie Real Germany störende eckigen Texturen erkennen. Das kann beim FS 2004 z.B eine höher gelagerte Landclasscenery sein. Das war beim FS2002 nicht so. Jetzt könnte man natürlich sagen OK ich weis, dass eine höher gelagerte Landclasscenery immer eine Fotoscenery überlagert.

Dem ist aber nicht so. Der FS2004 ist gemein. Es kommt darauf an wieviele LC Definitionen sind miteinander verbunden. Sind es nur sehr wenig und der Rest ist Transparenz LC Nummer 254 tritt der Effekt nicht ein.


Von daher sind diese Tools ideale Hilfsmittel wenn man weis welche Files überhaupt in Frage kommen.

Deshalb erwähne ich auch beide Tools in meiner Dok.

Nur das suchen und aufstöbern von potentiell störenden Scenerycode, dass nehmen sie einem nicht ab.

Deshalb habe ich diese Thematik mit aufgenommen. Sie wird enthalten sein.

Auch nehmen die Tools einem nicht ab zu entscheiden wie es sich dann später mit der Priorität verhält.


Der Sachverhalt mit dem Prioritätsbug bei Mesh hat sich ja durch Holger im FXP Forum ganz gut verbreitet. Holger hatte ja damals als erster hier im Forum über das Problem berichtet wenn ich mich recht erinnere.

[alfora]

Original geschrieben von JOBIA

Denn hin und wieder werden LC, WC oder Mesfiles von Addons irgendwo im FS2004 versteckt in Default FS Pfade untergebracht. Hin und wieder tragen sie auch keine verräterischen Namen wie z.B Mesh oder DEM. (Digital Elevated Mesh).

Genau das ist der Grund warum ich zusätzlich zu meiner FS9-Installation eine zweite Dummy-Installation gemacht habe auch die ich die ganzen Installer loslasse.

Die Dummy-Installation hat den Original-FS9-Pfad (weil manche Installer den voraussetzen und nicht ändern lassen) C:\Programme\Microsoft Games\Flight Simulator 9 und enthält nur eine leere Verzeichnisstruktur wie sie der echte FS9 (bei mir auf C:\Programme\FS9) auch hat. Nur eben ohne Dateien.

Ein Installationsprogramm lasse ich zunächst im Dummy-Verzeichnis installieren und schau mir danach an, welche Dateien wohin kopiert wurden. Dabei sind mir schon öfter solche dubiosen Speicherorte in FS9-eigenen Verzeichnissen aufgefallen.

Ich kopiere danach die Dateien in eigene Szenerie-Verzeichnisse und deinstalliere danach sofort wieder. Die endgültige Szenerie/Flugzeug wird dann manuell im echten FS9 installiert.

Das ist natürlich ein Mehraufwand aber dafür hat es mich schon etliche Male vor einer zerschossenen FS9-Installation gerettet bzw. mir überhaupt möglich gemacht, überhaupt etwas zu installieren!

[JOBIA]

Zu Alex

Prinzipiell ist Dein Verfahren nicht schlecht.

Es könnte aber hin und wieder Probleme geben. Du schreibst Du hast bei Deinem Dummy die Verzeichnisstruktur des FS aber leer Pfade also ohne Dateien.


Genau hier soll es bei AROE bei einigen Probleme mit dem Installer gegeben haben. Der Installer sucht Defaultdateien die er deaktivieren möchte. Findet er sie nicht installiert er nicht mehr korrekt.

Anderes Beispiel ATP 2004. Hier wird die terrain.cfg manipuliert (durch Editierung, es wird keine komplett neue Variante eingespielt)

Das kann man mit einem Dummy ohne Dateien nicht simulieren. Auch der FS9.1 Patch kopiert zwar fast alle Dateien neu ein paar werden aber auch editiert.

Hier also ein ähnliches Problem. Es wird nicht alles erfasst.

Man müsste den Dummy quasi wie einen original FS mit allen Dateien anlegen und nach einer Installation einfach mit dem Explorer nach Dateien neueren Datums im FS Dummy Pfad suchen lassen, dann wäre es eine 100% Sache um wirklich alles zu erfassen.

[wahltho]

... selche Scenery Files generell in welcher Gegend "aktiv" sind, war das Schiratti Control Center für mich eine wertvolle Hilfe. Damit konnte ich die Ursachen für so manchen Konflikt identifizieren

Leider gibt es keine aktuelle Version für den FS 9 mehr.

Sollte aber in den meisten Fällen trotzdem funzen.

[JOBIA]

Genau leider.

Denn das SCC konnte eigentlich nur Code bis/einschliesslich FS2002.

Alles was danach kam konnte es nicht.

TMF Technik also Mesh bzw. Landclassdaten inkl. Ihrer LC Definitionen bei fertigen BGL Files konnte es übrigends nie anzeigen.

War also schon immer für diese Techniken nicht als Auswertetool zu nutzen.

Für alles was Airporttechnik in FS2002 Code betrifft war es tauglich.

[Michael45]

Das "Paket" um ground2K4 bzw. ground2k2 (FS2002) bietet da auch eine Möglichkeit Meshdaten für ein definiertes Gebiet einzulesen, Höhendaten abzufragen und auch zu ändern. Allerdings, ob das alles was bringt, um die hier beschriebenen Probleme zu lösen - glaube ich eher nicht. Allerdings könnte man ein Gebiet korrigieren - aber mit welchem Aufwand!

Ich könnte mir vorstellen, dass FS die Höhendaten - relativ zu einer Basishöhe umsetzt. Dazwischenliegende Punkte (je nach Auflösung) werden dabei interpoliert. Irgendwo da "steckt" der Wurm drin.

Michael