Mesh-Konflikte, Flatten-Probleme
 

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

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

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

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

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

Gruß, Daniel

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.

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!

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.

Um zu sehen...
 

... 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.

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.

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

Du hast vollkommen recht. Je komplexer das Add-On desto schwieriger wird die Installation, keine Frage.

Aber gerade bei diesen komplexeren Add-Ons steht meistens eine Firma dahinter. Da ist die Wahrscheinlichkeit für einen guten Installationsvorgang dann viel höher.

Außerdem hab ich vergessen zu erwähnen, dass es in diesen Dummy-Verzeichnissen natürlich die wichtigen *.cfg-Dateien gibt. Sehr oft wird ja eine Scenery gleich in scenery.cfg angemeldet also sollte die vorhanden sein.

Ich will eher Fehler durch "dumme" Installer vermeiden. Leider gibt es in der Freeware-Szene manchmal solche Exemplare. Eben solche, die ungefragt Texturen ins globale FS9-Verzeichnis einspielen oder die terrain.cfg komplett ersetzen oder so. Ich hatte auch schon Installer, die einfach jüngere Versionen von Gauges mit älteren überschrieben haben. Und das Ersetzen von FSUIPC hat ja auch schon Tradition. :)

Das wäre mir neu. Habe zwar lange nichts mehr mit ground2K gemacht. Aber mir ist nur bekannt, dass man mit Ground 2K Landclass, Waterclass oder z.B über LWM technik die sogenannte Remeshfunktion programmieren kann. Das hat aber nicht mit regulären Mesh zu tun.

Eine Dekompilation von Mesh oder Landclassfiles ist mir nicht bekannt.

Ev. kann Rainer dazu etwas sagen, er hat ja lange mit Ground2K programmiert. Sollte sich so viel seit meiner letzten Zeit mit diesem Tool getan haben.

Bisher verschwiegt Microsoft diesen Kompressionsalgorithmus bei Mesh und LC.

Da muss man sich selbst mit auseinander setzen so ist zumindest mein Kenntnisstand.

Hallo...

Versucht dochmal den Filemon von Sysinternals. Der Zeigt bei mir zb alle bgl-dateien (Filter) an die geöffnet und gelesen werden.
Vieleicht hilft das weiter.


Sysinternals



Gruss Foxi

Hallo Foxi

Bringt uns hier nicht weiter. Wie gesagt ich habe in meiner Dok etwas zu dem Thema drin, möchte darüber aber noch schweigen. Trotzdem ist das Tool ein sehr guter Tipp von Dir.


Es dürfte eine sehr gute Hilfe sein für Leute die Probleme haben, dass der FS nicht startet bzw. beim laden von Scenerien irgendwelche Fehlermeldungen bringt. Ev. ist es sogar eine gute Hilfe für Leute die plötzliche Probleme haben. Sei es Crash to Desktop oder irgendein anderes urplötzliches Phänomen wie z.B der Verdacht bei GAP3. Da klagen ja einige Leute (im Raum Düsseldorf) glaube ich urplötzlich über unscharfe Texturen.

Mit diesem Tool hat man ev. eine Chance das Problem auf gewisse BGLs einzugrenzen. Hat man die BGLs, dann weiterhin ev. auf gewisse Texturen.

Danke ist wie gesagt allgemein ein guter Tipp. Könnte bei anderen Probleme sehr hilfreich zur Fehlereingrenzung sein.

Hallo..

Die eigentliche Frage lautete ja ob man rausfinden kann welche Szenerien überhaupt geladen werden und das geht mit dem Filemon sehr gut.
Um zu schauen ob ein File falsche Daten beinhaltet ist es natürlich nicht geeignet.


Gruss Foxi

Hallo Joachim,

nein, Dein Wissen ist immer noch aktuell. Unter richtiger Meshbeeinflussung stelle ich mir auch was anderes vor. Ground2k4 beherrscht lediglich remesh.

Ciao,
Rainer.

Was nützt Dir das in diesem Fall. Oben ging es zunächst darum, dass es Probleme mit einem Meshfile gab. Man hat einen Verursacherfile gefunden.

Die Frage bezog sich doch darauf ob man solche Fehler mit einem Tool welches zeigt was wo geladen wird eingrenzen kann.

Dazu ist das genannte Tool aber nur bedingt geignet.

Denn wenn man mal sieht was alles geladen wird, bzw. aus welchen File wiederholt Informationen nachgeladen werden, dann ist hier ein Rückschluss überhaupt nicht mehr möglich. Denn viele Meshfiles wurden zeitlich schon weit zuvor geladen. Es können also etliche Meshfiles bereits in der Listung enthalten sein, aktiv sind sie aufgrund Priorität dann doch nicht.

Nütz also für diese Zwecke eigentlich nichts.

Für diese andere Sache die ich erwähnte schon. Da ist es vermutlich sogar sehr gut geeignet.


Nein eben nicht. Denn es werden ständig Files nachgeladen. Auch welche die schon aktiv sind.