Hallo zusammen,

Altiports: ich wollte die eigentlich auch testen, aber kriege immer einen CTD wenn ich das AltiportesAlpes.zip Sammelpack aktiviert habe, egal ob mit oder ohne Mesh.

Jedenfalls wird unser LOD10 Mesh das LOD9 Altimesh immer ueberschreiben. Abhilfe waere da, die Frankreich LOD10 Dateien von uns zu loeschen.

Mit dem Flicken fuer die Spitze bei Salzburg habe ich mir einen netten Patzer erlaubt. Ich habe den naemlich als LOD12 kompiliert und da die Anzeigenweite von LOD12 nur ein paar km betraegt, wird dann bei groesseren Abstaenden wieder unser LOD10 Mesh angezeigt. :heul:

Ich werde mir das nochmal genauer ueberlegen. Ein korrekt benanntes LOD10 Pflaster sollte eigentlich auch gehen, aber dann sind da ja noch unsere Buffermeshdateien, die ebenfalls den Fehler enthalten. Vielleicht ist also ein LWM3 Flatten doch der bessere Flicken. Mal sehen.

Joachim, das mit den wechselnden Prioritaeten je nach Standort habe ich selber mal bei Dateisaetzen in Alaska beobachtet, aber eine Nachfrage bei Avsim usw. hat da nichts ergeben, denn sonst wollte es noch niemand bemerkt haben. Wenn du da konkrete Tests durchgefuehrt hast, waere eine Diskussion dieser in deiner Doku durchaus wuenschenswert.

Ciao, Holger

Hi,

die Altiports sind auf den Vertex Level 19 abgestimmt, für einzelne Airports gibt es auch Versionen für 21. Vielleicht liegt hier der Grund für den CTD.

CTD
 

Habe ja jetzt auch das Altiports Pack (also alles in einem, neuste Version). Die Artifakte (merkwürdige Fehldarstellung

- siehe anderer Threat http://www.wcm.at/forum/showthread.php?threadid=185516 )

sind nun zwar weg und es scheint auch alles mit dem Myworld Mesh zu funktionieren. Allerdings hatte ich bereits CTD auch ohne dieses hier angesprochene Alpen-Mesh.

Die Altiports scheinen ein Thema für sich zu sein und in manchen konfigurationen Probleme zu bereiten. Nun habe ich mal dieses Alpen Mesh installiert und bin von Aux des Bains nach Courchevel geflogen. Unterwegs gab es keinen - nicht wie vorher - CTD , aber NACHDEM ich gelandet bin und schon auf dem Vorfeld stand. Dabei hatte FSPassenger diesen Flug noch nicht Mal registriert :-( Aber war eh Bruch , siehe Foto.

Wollte auch mal mich direkt vom gehe zu airport Menü nach Courchevel versetzen lassen - eben falls sofort CTD.

Wie gesagt - bin mir gar nicht sicher, ob es mit diesem neuen Altimesh zu tun hat?!

meine Einstellungen...
 

...habe ich hier als Anhang gepostet: FSnavigator. Damit sind die CTD anscheinend weg, auch das "Hindurchfallen" durch die Piste beim Landen. Irgendwie scheinen sich die Altiports nicht mit den Alpen Mesh zu vertragen, wobei, wie oben erwähnt es vielleicht nicht an den Alpenmesh liegt , sondern an den Wechselwirkungen untereinander. Werde auch morgen noch mal versuchen, das Alpenmesh, welches ich jetzt deaktiviert habe, anzuschalten, um zu sehen, ob und welche Priorität in der Scenery Bibliothek hilft...

erfolgreiche Landung
 

mit der Maule

und nocheinmal
 

die Maule in Courchevel. Übrigens meine ERSTE Landung ohne Schrott ;-)

hier nochmal meine Einstellungen
 

im FSNAVIGATOR...mit denen ich keine Probleme habe. Werde das Alpenmesh morgen mal aktivieren und sehen, ob es so zum CTD kommt...

Danke für die Rückantwort. Ich persönlich hatte dass bisher nie bemerkt und bin durch Jan Paul darauf aufmerksam geworden. Er hat dieses beim Austria Prof. Mesh in Verbindung mit FS Global gemeldet.

Ich habe daruf hin mal gestöbert und nirgends etwas gefunden. Dieser Bug scheint wirklich weitgehend unbekannt zu sein.


Dumm ist das weil hier natürlich alle die kalte Hand ins Gesicht geschlagen bekommen. Den Bug kann man nämlich nicht durch gezieltes Anmelden im FS in den Griff bekommen.


Da müsste eigentlich ein offizieller Patch her.

Man bekommt ihn meiner Meinung nach bisher nur durch konstruktive Massnahmen bei der Mesherstellung in den Griff. Diese dürften allerdings den wenigsten Meshdesignern schmecken.

Auch hat bestimmt keiner Lust seine Meshfiles zu überarbeiten.

Aber wie gesagt ich weis noch zu wenig darüber was da alles wann wie abläuft. Testdateien habe ich mir schon erstellt, sie stellen die Situation FS Global und ATP nach. Das ganze allerdings eindeutiger, so das man besser beobachten kann was passiert.

Bin aber noch nicht dazu gekommen groß zu testen.

Ich wollte noch etwas zur normalen Priorität sagen.

Das LOD10 Basismesh von Holger gewinnt in jedem Fall gegenüber anderen Mesh Addons die nur LOD9 haben die Oberhand.


Aber es werden ja Puffermehsfiles mit niederen LOD Level (LOD9 und LOD8)mitgeliefert. Diese stehen natürlich schon in Konkurenz zu anderen Mesh Addons.

So kann es dann passieren, wenn man dort die Priorität nicht beachtet, dass nun in etwas größerer Entfernung nicht Holgers Puffermesh arbeitet, sondern z.B My World sich hier vordrängelt.

Und schon verpufft im wahrsten Sinne des Wortes die Wirkung des Puffermesh.

Was ist überhaupt ein Puffermeshfile?

Puffermeshfiles sollen in der Tiefe des Raumes unnatürliche Höhendifferenzen vermeiden, weiterhin in Verbindung mit überrissenen Terrain_*_Radius Faktoren in der FS9.CFG die hellblauen Schlitze in der Erdoberfläche verhindern.


Das geht natürlich nur, wenn das Puffermesh auch zur Anwendung kommt.

Deshalb sollte auch hier auf Priorität geachtet werden, auch wenn es hier nicht ganz so wichtig ist, da es sich hier um eine Zone in etlicher Entfernung handelt.
Nur wir können natürlich im FS auch sehr weit schauen, dass sollte man nicht vergessen.

Hi,

Bei mir sieht Courchevel so aus:

1. Mesh Alps LOD10 mit Altiports
eingeschneit
Piste

2. Mesh Alps LOD10 ohne Altiports
Loch

Das Ganze bei folgenden Prioritäten:
prior
Ich habe kein welt/europaweites addon mesh, das VFRairfields mesh enthält nur das Germany-file - Switzerland habe ich entfernt).
Die übrigen (schlichter ausgestatteten) Altiports sehen normal aus.

Fritz

Definitiv CTD
 

So, habe nun mit den Einstellungen siehe Anhang einen Flug ab Courchevel gewagt. Es wird alles gut dargestellt, aber nach wenigen Minuten gibt es einen CTD.

Ich gehe davon aus, dass dies nur mit dem aktivierten Alpenmesh passiert - jedenfalls in meiner Konfiguration.

Denke, ich kann auch mit My World Mesh und dem lokalen Freeware Altimesh (für die franz. Altiports) leben, zumal auch das Problem mit den merkwürdigen Fehldarstellungen gelöst zu sein scheint....(betonung liegt auf scheint!)

prioritäten
 

Darauf bezogen, habe ich das lokale Altiportsmesh recht weit unten angeordnet (sieht man auf dem Screenshot des FSNavigators nicht).

Hier noch ein Foto mit dem Alpen Mesh - Alps mesh LOD10 - Switzerland and France\mesh Alps LOD10 by Ferranti & Sandmann - leider führt es IN MEINEM FALL zum CTD.

und noch ein Foto
 

von Courchevel mit Alps mesh LOD10 - Switzerland and France\mesh Alps LOD10 by Ferranti & Sandmann

Zum Auftreten des "Salzberg-Peaks" und dessen umständlicher Beseitigung möchte ich doch einmal die Frage aufwerfen ob es denn wirklich nötig ist die einzelnen Mesh-Dateien so gross zu machen dass sie ein einfacher Modem-Besitzer kaum noch laden kann.
Der Fehler "Salzberg-Peak" wird dadurch bewirkt dass in zwei der Orginal-HGT-Dateien jeweils eine einzige Zahl falsch eingetragen ist. Für mein LOD9-Mesh habe ich das korrigiert, an Arbeitszeit hat mich das eine halbe Stunde gekostet und das auch nur deswegen weil zwei Dateien Fehler hatten und ich erst nur eine davon korrigiert hatte und somit die Korrektur zweimal machen musste. Die kurze Korrekturzeit kommt nun allerdings auch dadurch zustande dass ich die Mesh-Dateien in "Micro-Tile -Technik" erstelle bei der die Dateien 1x1grad groß sind, bei LOD9 sind das ca. 2 MB, für die die Kompilierzeit unter einer minute liegt (der Begriff "Fleckerlteppisch-Mesh" statt "Micro-Tile"hat sich international nicht durchsetzen können). Um den Fehler zu beheben bräuchte ein User also nur eine 2 MB-Datei für LOD9 oder eine 8 MB-Datei für LOD10 zu saugen und nicht den halben Block von 20 MB bzw. 80MB.
Was spricht denn bei Freeware-Mesh dagegen die Dateien kleiner zu halten?
Ansonsten ein grosses Dankeschön an Holger Salzmann dass er uns den Tipp mit den Daten von Jonathan de Ferranti mitgeteilt hat. Die Löcher in meinem Alpen-Mesh hatte ich schon immer mal gescheit stopfen wollen.

Gruss,

Falko

CTD
 

Leider habe ich mich zu früh gefreut. Der CTD tritt in meiner Config. auch ohne das hier angesprochene Mesh von Alps mesh LOD10 - Switzerland and France\mesh Alps LOD10 by Ferranti & Sandmann auf :-(

Somit geb ichn erst mal auf. Irgendetwas harmoniert zwischen dem Lokalen Altiports Mesh, den Altiports (Courchevel etc.) und MyWorld Mesh nicht und führt bei mir zum CTD. Diesmal wars auf 3/4 Strecke zwischen von Aux deBains nach Courchevel, FL100.

Ansonsten wurde bei mir alles gut dargestellt, siehe obenstehede Screenshots.

Danke Kustra und Holger für die Info!
 

Komme leider erst jetzt dazu zu lesen und antworten.

LG

Bernd:hallo:

Hallo zusammen,

zu dumm das mit den Altiports, aber vielleicht gibts ja irgendwann eine spezielle Version fuer unser Meshfile ;-) (das war jetzt keine Ankuendigung, sondern eine Hoffnung)

Falko, ich gebe dir natuerlich Recht, dass eine Kompilierung von kleineren Zellen das Updaten vereinfachen wuerde. Allerdings wuerde das den Modemnutzern nur bei Patches helfen, denn das Gesamtpaket muessen sie ja so oder so laden.

Ausserdem scheint die Groesse der Teilstuecke das Ladeverhalten (d.h. die Prioritaet) zu beeinflussen, zumindest waere das eine logische Erklaerung fuer das Phaenomen, das Joachim und ich weiter oben angesprochen haben.

Fuer den Meshersteller ist der Umstand aber schon groesser, wenn man Fleckerlteppisch-Mesh erstellt. Entweder schneidet man aus den Rohdaten die Teilstuecke aus oder man nutzt die UseSourceDimensions Einstellungen in der inf Datei. In beiden Faellen muss man aber erst die Rastergrenzen fuer die entsprechenden LODs ermitteln, um Ueberschneidungen oder Loecher zu vermeiden. Das kann man zwar mit EXCEL oder Scripten teilweise automatisieren, aber ob ich das fuer ein grosses Stueck mache oder fuer 50 kleine ist schon ein Unterschied.

Ciao, Holger

Altiports
 

Hallo Holger,

wie oben beschrieben habe ich den CTD sowohl mit Eurem Mesh als auch OHNE gehabt.

Ich hatte in beiden Fällen das MyWorld Mesh und das spezielle lokale Altiports Mesh (weiss nicht wie gross die Abdeckung ist, sind ca. 16 mb) aktiviert.

Was nun der Störenfried ist, ob es an Prioritäten in der Scenery.cfg oder Einstellung des Terrain /Radius etc. in der fs9.cfg liegt, kann wohl nur ein Fachmann beantworten- ich gehe mal davon aus, dass Jobia u.a. kräfti am "brühten" sind. Aber sicher haben die meisten , wie ich auch, eienn festen Job und nicht unbegrenzt Zeit (und Lust) diesen Bug zu analysieren.

Interessant in diesem Zusammenhang noch, dass die Fehlermeldungen betreff. der Scenery.dat und die bei mir dargestellten Riesenberge/Fehldarstellung verschwunden sind. Wahrscheinlich nachdem ich die neusten Altiports heruntergeladen hatte.

Dennoch bleibt unklar, inwiefern ein Mesh oder die Altiports selbst in bestimmten Konfigurationen für den Crash to Desktop verantwortlich sind!?

Würde mich nicht wundern, wenn ich bei abgeschalteten Altiports mit der verwendung von Holgers Mesh bzw. auch Myworld Mesh keine Probleme hätte...

Ich frage mich derweil noch, ob ich meine altes LAGO Mesh anstatt Myworld Mesh verwenden sollte? Weiss nicht welches besser ist?! Es scheinen bei Myworld Mesh im gleichen Ordner die Landclassen zu sein, daher würde ich bei deaktivieren ja auch die Lanclassen von Myworld Europe deaktivieren, deren Darstellung ich aber gut finde.

SOllte ich hier allzuviel durcheinanderbringen, bitte ich um Korrektur, kann es hier nur so mit meinem ungesunden Halbwissen ;-) beschreiben und eingrenzen. Ich hoffe , dass meine tests Euch, insbesondere Joachim und Hoger geholfen haben?

Ich denke es ist nicht die Aufgabe von Holger, bestimmte eventuell vorhandene Bugs in den Altiports selbst zu beseitigen...

Zumal die Ursache nicht wirklich bekannt ist...

Zur Abdeckung vom Altiports Mesh:

Couvre du Nord Dittinguen (en Suisse) à Chamois à l'Est (en Italie)
et Valberg, Lftz au Sud, et au Rhône à l'ouest.

et le côté Est du fleuve Rhône pour y intégrer La Bacchus, Le Mt Aiguille, etc.

Man kann sich das auch schön im TMF Viewer anschauen.

http://download.microsoft.com/downlo..._sdk_setup.exe

Zur Abdeckung vom Altiports Mesh:

Couvre du Nord Dittinguen (en Suisse) à Chamois à l'Est (en Italie)
et Valberg, Lftz au Sud, et au Rhône à l'ouest.

et le côté Est du fleuve Rhône pour y intégrer La Bacchus, Le Mt Aiguille, etc.

Man kann sich das auch schön im TMF Viewer anschauen.

http://download.microsoft.com/downlo..._sdk_setup.exe

Hallo zusammen,

eine neue Version des Patches fuer die Problemstelle in Salzburg, sowie fuer zwei Gipfel in den franzoesischen Alpen, ist jetzt hier erhaeltlich: http://forums.simflight.com/viewtopi...=299577#299577

Lasst mich wissen, ob es dieses Mal klappt wie geplant :ms:

Ciao, Holger

@Holger

<Falko, ich gebe dir natuerlich Recht, dass eine Kompilierung von kleineren Zellen das Updaten vereinfachen wuerde. Allerdings wuerde das den Modemnutzern nur bei Patches helfen, denn das Gesamtpaket muessen sie ja so oder so laden.>

- Genau das meine ich, es würde das Ausbessern von Fehlern sehr vereinfachen.

<Ausserdem scheint die Groesse der Teilstuecke das Ladeverhalten (d.h. die Prioritaet) zu beeinflussen, zumindest waere das eine logische Erklaerung fuer das Phaenomen, das Joachim und ich weiter oben angesprochen haben.>

-Das ist ja gerade das Problem, man kann große Teile nicht mit kleineren Teilen mit gleichem LOD überschreiben. Sind alle Teile klein kann man sie einfach austauschen.

<Fuer den Meshersteller ist der Umstand aber schon groesser, wenn man Fleckerlteppisch-Mesh erstellt. Entweder schneidet man aus den Rohdaten die Teilstuecke aus oder man nutzt die UseSourceDimensions Einstellungen in der inf Datei. In beiden Faellen muss man aber erst die Rastergrenzen fuer die entsprechenden LODs ermitteln, um Ueberschneidungen oder Loecher zu vermeiden. Das kann man zwar mit EXCEL oder Scripten teilweise automatisieren, aber ob ich das fuer ein grosses Stueck mache oder fuer 50 kleine ist schon ein Unterschied.>

-Also, ich hab das für Deutschland in LOD9 mit den inf-Dateien gemacht. Das sind inzwischen sogar 99 Dateien. Für die Rastergrenzen habe ich die den HGT-Dateien entsprechenden Grenzen gewählt, jeweils die nächste LOD9-Grenze nördlich oder östlich zu den HGT-Grenzen. Falls man sich auf so eine Norm einigen könnte wären die verschiedenen Mesh's kompatibel zueinander. So habe ich z.B. für Deutschland vier verschieden Mesh's von gleicher Qualität die alle nicht zueinander passen.
Falls Du für Dein LOD9-Puffer-Mesh auch die erste LOD9 Grenze nördlich des letzen verwendeten nördlichen Breitengrads gewählt haben solltest, hätte man einen Nahtlosen Übergang von Deinem Alpen-Mesh zu meinem Micro-Tile-Mesh für das restliche Deutschland. Die LOD Grenzen kann man sehr einfach berechnen.

Gruß, Falko

Hi,

ich habe das Prioritäten Problem mit Austria Pro und FSGlobal bei mir folgendermaßen gelöst.

Statt FSG verwende ich das Mesh von Yohann Baptiste welches Großflächiger als FSG ist. Man muß aber Trotzdem den FS in Salzburg starten damit Austria Pro auch zur anzeige kommt. Damit FSG sich nicht vor das Baptiste Mesh schiebt, habe ich die entsprechenden FSG BGL's (L9N1601.BGL bis L9N1604.BGL) entfernt.

Zu
"Das ist ja gerade das Problem, man kann große Teile nicht mit kleineren Teilen mit gleichem LOD überschreiben."

Eben nicht so haben wir es z.B bei ATP das kleine FS Global Teile das großflächigere ATP Mesh überschreiben (also genau umgekehrt wie Du schreibst), aber eben nicht überall.

Da hört leider noch sehr viel mehr zu dieser Problematik.

jedenfalls hat das letzte update von Holger seinen Zweck erfüllt, die Salzburg Attraktion ist nun verschwunden, herzlichen Dank hierfür!

Gruß

oscar.o

CTD
 

Hat hier noch jemand einen CTD gehabt? Ich bin mir immer noch nicht sicher, ob es an den Altiports (Courchevel etc.) liegt, an den Meshes oder beidem?

Zu

Nun zunächst mal verwendest Du unkorrigierte SRTM Meshdaten. Ich glaube das ergibt eh keinen Sinn diese Daten die ja jedermann ohne Basiswissen per SRTM Tool einfach innerhalb weniger Minuten in eine FS Mesh BGL resampeln kann zu nutzen.

Leider gibt es die sinnvolle Korrektur selbst in einigen Addon Meshfiles nicht.

Warum ergibt es aber keinen Sinn Microfiles zu machen.


Klar wäre das praktisch wenn man mal bei Bugs kleine fehlerhafte Teile wie jetzt geschehen austauschen kann.

Nur nutzt man unkorrigierte SRTM Daten, dann würde ich schon sagen, das man die ganze Alpenregion als einen einzigen Bug bezeichnen könnte, selbst wenn sehr vieles korrekt ist.

Außerdem entstehen hier wieder hunderte an Dateien wie man ja bei Dir schon (jetzt schon 99 Stück) sieht.

Im Fehlerfall oder sinnvolle Priorität ist das überhaupt nicht mehr zu bewältigen.

Nehmen wir doch einfach mal die Bugs an Airports wie sie z.B Henning meldet. Also z.B auch Bodentexturflackerprobleme durch Wechselwirkung AREA16N Flatten, Runwaycode und Mesh.

Klar kann man das zunächst ermitteln in dem man irgendeine Scenery abmeldet. Nur will man dann hunderte BGls absuchen um die zu ermitteln um die es sich handelt. Der Aufwand welches Addon nun gerade hinsichtlich Priorität je nach Startort (der Bug den wir hier erwähnten) wird mit Microfiles noch unberechenbarer.



Was aber meiner Meinung auch dagegen spricht ist der Barth Effekt.

Kennst Du noch die ersten Barth Landclass LC Files für Deutschland?

Das was ich jetzt überarbeitet hatte, was man im Zuge des German Landscape Projektes Downloaden kann.


Der Verwaltungsaufwand für den FS wird sehr hoch. Man hat wesentlich längere Ladezeiten.

Da jedes Landclass und natürlich auch Meshfile einen Datenheader mit sich schleppt wird das Verhältnis Nutzdaten zu Datenheader extrem ungünstig.

Deckt ein File 300 x 300 km ab ist der Datenheader nicht anders als bei einem kleinen File welches nur 1km x 1km abdeckt. Nur das Du jetzt 90000 mal diesen Header der auszuwerten ist hast.

Ist natürlich jetzt ein Beispiel welches nicht ans LOD Raster angelehnt ist.

Das Prinzip ist aber leider so.

Weiterhin ist die Datenkompressionsrate der BGls bei großen Files größer als bei vielen kleinen.

Bedeutet hat man exakt identische Informationen für eine große Fläche, dann ist unabhängig vom Header das große File kleiner in den MBs als die vielen Einzelfiles die die selbe Fläche abdecken.

Meiner Meinung spricht sehr vieles gegen kleine Files.

Wenn man ein gutes perfektes Mesh hat, dann wird es auch keiner nötig haben hier irgendwelche Bereiche raus abzuschalten.

Wenn ich mal Mesh außen vor lasse und nehme mal Landclass, dann möchte ich behaupten das fast alle Anwender mittlerweile Chaos und keinen Überblick haben und kaum einer wissen dürfte welches Landclassfile wo gerade aktiv ist.

Das selbe gilt für Mesh auch. Wenn dann noch diese Microfiletechnik kommt ev. dann auch noch mit ein oder zwei Puffermesh die dann natürlich auch noch in Microtechnik sein sollten dann gute Nacht FS.

Zu


Aussage Holger

<Fuer den Meshersteller ist der Umstand aber schon groesser, wenn man Fleckerlteppisch-Mesh erstellt. Entweder schneidet man aus den Rohdaten die Teilstuecke aus oder man nutzt die UseSourceDimensions Einstellungen in der inf Datei. In beiden Faellen muss man aber erst die Rastergrenzen fuer die entsprechenden LODs ermitteln, um Ueberschneidungen oder Loecher zu vermeiden. Das kann man zwar mit EXCEL oder Scripten teilweise automatisieren, aber ob ich das fuer ein grosses Stueck mache oder fuer 50 kleine ist schon ein Unterschied.>


und Deine Antwort

-Also, ich hab das für Deutschland in LOD9 mit den inf-Dateien gemacht. Das sind inzwischen sogar 99 Dateien. Für die Rastergrenzen habe ich die den HGT-Dateien entsprechenden Grenzen gewählt, jeweils die nächste LOD9-Grenze nördlich oder östlich zu den HGT-Grenzen. Falls man sich auf so eine Norm einigen könnte wären die verschiedenen Mesh's kompatibel zueinander. So habe ich z.B. für Deutschland vier verschieden Mesh's von gleicher Qualität die alle nicht zueinander passen.
Falls Du für Dein LOD9-Puffer-Mesh auch die erste LOD9 Grenze nördlich des letzen verwendeten nördlichen Breitengrads gewählt haben solltest, hätte man einen Nahtlosen Übergang von Deinem Alpen-Mesh zu meinem Micro-Tile-Mesh für das restliche Deutschland. Die LOD Grenzen kann man sehr einfach berechnen.



Ok über die Größe eines Meshfiles habe ich ja schon geschrieben.



Ich denke nicht das Holger ein Problem hat die LOD Grenzen zu berechnen, es hört sich jetzt fast so an als wenn Du das so interpretierst.

Ich denke nur ihm ist der Aufwand zu hoch, weil er ebenso wie ich keinen Sinn darin sieht.

Welche Grenzen mal wählt ist jedem selbst überlassen. Das hängt nämlich zum Teil auch von den Rohdaten ab die man hat. Nicht jeder nutzt großflächige löchrige SRTM Daten.


In der Regel produzieren alle immerhin schon rechteckige Meshfiles.

Aber es gibt auch Extreme wie z.B bei der Swiss Pro. Man hat offensichtlich wirklich nur für die Schweiz Top Daten gehabt. Von daher ist das Swiss Pro LOD11 Mesh ein Mesh welches gemergt wurde.

Es ist ein Mesfile welches aber überhaupt nicht rechteckig ist. Es hangelt sich in kleinen LOD Quadranten um die Schweiz herum.

Trotzdem ist es sinniger Weise nur ein Meshfile.

Klar man hätte es auch anders mergen können. So konnte man aber den Speicherbedarf noch mals optimieren. Was hätte es gebracht große Teile außerhalb der Schweiz für die man keine Top Daten hat in LOD11 zu resampeln.

Ich denke zu einer sinnvollen Meshprogrammierung gehören einige Gedankengänge.

Aber ich gebe Dir in folgendem Punkt recht, sinnvoll wäre eine Einigung auf feste Größen der Meshumsetzung, z.B LOD5 Quadrant bei LOD9 oder ähnlich, denn dann bekommen wir auch diese unberechenbare Priorität in jedem Fall in den Griff

CTD durch Landclass
 

Hallo Jobia,

es scheint so, wenn ich Dich richtig verstehe, wäre es zu aufwendig, festzustellen, was und bei welchem Mesh zu einem CTD oder anderen Problemen führt.

Kann es nicht auch sein, dass in den Altports Landclassendateien versteckt sind, die diesen Landclass CTD auslösen, wenn der Texture ordner nicht leer ist. (gab es doch bei AROE). Oder bringe ich da etwas durcheinander. Sorry, mittlerweile verliere ich da die Übersicht, zum Mal mir die Materie fremd ist - auch wenn man durch Deine Beiträge einiges lernen, verstehen kann...

Im Anhang der scenery Ordner von Courchevel...

hier der anhang
 

als jpg

@Henning,

die Altiport enhalten keine Landclass Dateien. Ob eine Scenery LC Dateien im Scenery Ordner hat, kannst du mit dem Flight Sim Manager prüfen: http://www.ranainside.com/software_f...m_manager.html

Re: CTD durch Landclass
 

ich habe in diesen Thread bisher nie von CTDs bezüglich Mesh gesprochen.

Ich habe mir auch keinerlei Gedanken darüber gemacht woher das kommen kann, weil ich keine Zeit dafür habe, bzw. verschwenden will.

Wie gesagt da musst Du etwas ganz falsch interpretiert haben.

Mir ging es nur um das Prioritätsproblem bei Meshfiles.

Aber nicht das mit der bekannten Vertauschung sondern das quasi willkürlich varierende.


Es gibt übrigens keinen CTD wenn Landclass einen Texture Ordner hat der leer ist. Es gibt ein Speicherleck, dass ist dann aber kein CTD.

Hallo,

bzgl. CTD mit den Altiportspaket scheint Fritz etwas herausgefunden zu haben: http://forums.simflight.com/viewtopi...=299974#299974

Ciao, Holger

Re: Re: CTD durch Landclass
 

@Jobia:
Ich habe vermutet, dass die Probleme mit den Prioritäten der Meshes(das hab ich schon verstanden) , die Fehlermeldung bezüglich scenery.dat´s und Fehldarstellungen (Riesenberge, NICHT den Salzburg Bug) wie ich sie im Zusammenhang mit den Altiports hatte UND den CTD miteinander zu tun haben. Es steht Dir natürlich frei, Dich um diese CTD nicht zu kümmern, habe da auch nichts erwartet.

Wollte halt keine Ursache ausschließen, die die Probleme mit den Altiports , insbesondere Courchevel auslösen könnte. DAchte mit meinen Erfahrungen auch in diesem Threat konstruktiv meine Erfahrungen einbringen zu können , auch wenn es mir mehr um die Altiports selbst geht, als um dieses nette neue Alpenmesh.


@Holger:
Werde mir mal diese geänderte (?) AF2 Datei von Courchevel ansehen - gibts die als Download?
Ich habe mal Courchevel in einem Extra Ordner gelegt und seperat von den Altiports ind der Scenery.cfg angemeldet. Natürlich die Courchevel Dateien in dm Altiportsordner mit den übrigen Airfields gelöscht.
Nun hab ich mal nur Courchevel aktiviert und die anderen deaktiviert: Nach einem Testflug KEINE CTD!! Muss es aber zur Sicherheit noch mal wiederholen. Im FS9 AddOn MEnü kann ich eine Startposition aswählen. Die ist bei mir direkt auf dem Vorfeld in Startrichtung RW24 und NICHT im Hangar! Habe die neuste Versuin von Courchevel (falls es nicht bereits eine noch neuere gibt?). Allerdings passen die FS9 Hauptmenü- Positionen nicht, beziehen sich wohl auf den Default Airport, der ja nun versetzt wurde.

Meine Aussage war in keinem Fall negativ oder ähnlich Dir gegenüber gemeint.

Nur momentan habe ich einfach keine Zeit für die Altiports. Denn so wie man sieht, bestehen schon allein durch die verschiedenen Versionen die Du besitzt bzw. die im Netz vorhanden sind extrem viele Möglichkeiten woher der Fehler kommen kann.

Da jetzt erst mal die Konstellation zu haben die überhaupt einen Fehler bringt.

Das kann bedeuten ich würde mir das ganze Zeug runterladen, Du weist zum Teil ist das bereits geschehen, dabei haben wir ja erkannt, dass es unterschiedliche Versionen gibt.

Dann versuchen genau die Konstellation zu haben. Dann probieren bis man auch mal einen CTD hat.

Wenn man dann mal einen hatte, erst dann kann man anfangen zu suchen.

Aber bis man einen CTD hat, dass kann dauern, wenn so viele unterschiedliche Versionen und Konstellationen bestehen (da natürlich das Meshfile schon eine Rolle spielt siehe unten)

Wenn man schon einen riesen Aufwand hat einen Fehler überhaupt erst mal zu provozieren, dann kann ich mir diese Zeit nicht erlauben, da laufen viele andere Sachen bei mir parallel die darunter leiden, deshalb beschäftige ich mich mit solchen lokalen schwer nachzustellenden Fehlern momentan nicht.

Zu den CTDs selbst.

Sehr oft standen CTD Probleme in Verbindung mit Mesh, so damals auch in Sion FS9 vor dem offiziellen Patch.

Hier trat es nur mit Addon Mesh oder aber mit dem Default Mesh auf, wenn man zusätzlich den TERRAIN_MAX_VERTEX_LEVEL veränderte.

Gründe sind die dann anders verlaufenden Polygondreiecke des Terrainpolygonmodel.

Aber das ist nie der eigentliche Grund.

Grund ist, dass die eigentliche CTD Fehlerstelle in einen Neigungszustand gerät, dem sie sonst nicht unterliegt.

So wird z.B bei Landclass ab bestimmten Neigungen ein automatischer Texturwechsel bei sehr vielen LC Nummern eingeleitet.

Es gibt aber noch sehr viele weitere Automatismen bei Landclass.

Wenn dann Neigungsautomatismus und andere Automatismen ungünstige zusammen kamen, gab es im ungepatchten FS2004 damals den CTD.


Hier kann es jetzt ähnlich sein.

Es kann aber auch sein, dass hier ein anderer Code vermutlich im Airport Addon existiert der eine bestimmte Neigung nicht mag.



Wird dieser jetzt durch ein anderes Mesh oder geänderten TMVL jetzt mit einer bestimmten Terrainpolygon Neigung beaufschlagt, macht es Peng und Du hast ein CTD.


Übrigens

Der Problem Code könnte ev. ein VTP Polygon sein welches eine LC Nummer zuweist. So kommt man dann doch z.B zu LandClass Informationen die laut Jan als offizielles Landclass BGL file in den Altiports nicht existieren.

Es wird quasi Landclass über andere Technik zugewiesen.

In Sion z.B stand das Problem auch in Verbindung mit landclassbasierender Technik.

Hier war es auch ein VTP Polygon welches landclassartige Informationen liefert.

Wenn ich mir den einen Screenshot des verlinkten Beitrags anschaue, dann scheint man nämlich bei der aktuellen Altiportsversion die schräge Runway in vormals alten Polygoncode durch ein meshkompatibles VTP Polygon ersetzt zu haben.

diese Bild bei dem TMVL Default 19 gestanden haben soll.

http://www.tg29.at/perfect.jpg

Hier die rechts schräg abfallende Runway. Anhand der erkennbaren Rauschüberlagerung bei meshkompatibler Oberflächen kann man ziemlich sicher sein, dass es sich um ein VTP Poly handelt.

Ev. ein Landclass VTP Polygon.

Komisch mit dieser neuen Version hat man einen CTD.

Es gibt da also vermutlich Zusammenhänge.

Es kann aber auch ein ganz anderes Problem sein.

Es wurde ein weiteres Bild mit TMVL nicht auf Default 19 sondern 20 gezeigt. Das sah dann so aus.



http://www.tg29.at/snowed_in.jpg

Ok der Airport ist jetzt schrott. Wir sehen aber auch dass sich das Gelände im Airportbereich komplett geändert hat. Von der Runway ist nichts mehr zu sehen. Auch texturtechnisch nicht.
Weil sie nämlich offensichtlich Landclass basierend ist. Es wurden Neigungsschwellen überschritten. Es kann gut sein, dass hier ein Problem liegt.

Beim Screenshot liegen wir schon sehr nah dran.


Man muss aber wissen, dass Mesh dynamisch arbeitet. Wären wir weiter weg, dann sähe das Mesh und der Airport ganz anders aus.

Ev. sogar korrekt.

Nur das sehen wir aus der Entfernung ev. nicht.

Fliegen wir jetzt den Airport an, kann es gut sein, dass nur in dem Moment wo das Mesh dynamisch schaltet es zum CTD kommt.

Setzen wir den Flug so nah am Airport auf, dass diese Schaltschwelle nicht durchlaufen werden muss, dann kommt es ev. überhaupt nicht zum CTD.

Das erinnert auch stark an dieses Fehlerbild der urplötzlich innerhalb Sekundenbruchteilen unscharfen Bodentexturen verursacht durch einige Airport Addons.

Bei zwei Freeware Airports konnte ich die Ursache Dank Hilfe eines FXP Forenmitglieds der mir Problem auslösende Flugsituationen liefern konnte ermitteln.
Dieser Bug wurde aber auch in Verbindung mit der aktuellen GAP Version die Düsseldorf enthält gemeldet.

Viele haben geklagt, aber auf Nachfrage von mir gab es auf einmal niemand mehr der das Problem bei sich nachstellen konnte, bzw. mir eine Flugsituation liefern konnte.

Genau das ist das Problem auch hier.

Wenn ich einen riesen Aufwand betreiben muss um einen Fehler überhaupt zu haben, dann kann ich mir diese Zeit momentan nicht erlauben.

Dieses nur mal als mögliches Hintergrundwi

Gibt ein erstes Update: AVSIM

CTD Altiports
 

Jobia;

Danke für die ausführliche Antwort. Ich selbst bin auch schon genervt, da ich nicht recht weiterkomme. Daher werde ich mich wohl auch erst mal nicht weiter mit den Altiports beschäftigen, zumal ich nicht das Hintergrundwissen über Dateien etc. habe. Es braucht ne Menge zeit und die hab ich auch nicht, will schließlich Fliegen...Dennoch hätte es mich gereizt, dass Problem zu finden, hab da sonst keine Ruhe ;-)

Zum CTD: Habe mal dieses http://www.vf-air.com/AltiportsAlpes.zip packet statt diesem http://www.vf-air.com/AltiAlpes.zip installiert. Letzteres scheint alles in allem zu sein, aber ich glaube nicht wirklich...Kömmt mir von der Datenmenge komisch vor....

Aber egal: Mit dem ersteren habe ich lange keinen CTD gehabt , ABER nach dem ich den Flieger auf dem Airport abgestellt hatte und kurz was essen gegangen bin, kam ich zurück und siehe da: kein FS mehr....ohne überhaupt irgendetwas zu tun, gab es einen CTD.....

Überhaupt tritt der CTD erst nach einigen Minuten Flug auf. Das heisst auch wenn ich in dem lokalen Gebiet bleibe.

Den Patch für das Mesh habe ich installiert. Aber denke auch, dass die Altiports selbst die Ursache sind. Betrachtet man den Flieger auf dem Vorplatz von Couchevel, hatte ich öfters einen Crsh mit gebäude, obwohl den flieger nicht bewegt. D.h. da sind einige programmiertechnischen Unsauberheiten drin!

Holger, vielen vielen Dank für das großartige Mesh. Ich habe es gestern installiert und bin im Berner Oberland geflogen. Es ist faszinierend wie detailiert dadurch die Landschaft wird. Vorher hatte ich ein SRTM Mesh welches immer dann lückenhaft war, wenn die Landschaft interessant wurde - eine schöne Bergkette, die dann abrupt wie an einer Wand abgeschnitten war u.s.w..

Weiß jemand, ob es für die Schweiz ein Korrekturfile für Flüsse und Straßen gibt bzw. ob detailreiche-LC existieren? Momentan habe ich als LC My World. Die Flüsse und Straßen verlaufen aber recht häufig an Berghängen.

Schöne Grüße

Simeon

Hi

Unser Horn. Holgers Mesh sei Dank!

http://img301.imageshack.us/img301/1...mar70169bc.jpg

Herbert

Auch von mir ein dickes Dankeschön! Die Mesh ist großartig, und es war kein Problem die AP2004 Mesh durch deine zu ersetzen, die wirklich deutlich besser aussieht.