Horst auf alle Fragen kann ich Dir eindeutige Antworten geben. Zunächst mal eines. Einige interpretieren diese terrain.cfg speziell die Nr.1 als Lösung. Dazu soviel die Nr.1 war gleich der Blattschuß. Es ist aber nicht die Problemlösung. Das Problem ist immer noch da. Es ist für euch erst mal behoben, gelöst ist es aber noch lange nicht. Es war eine reine Idee von mir im Kopf. Also reine Theorie. Ich muß mir erst mal selbst anschauen wie die Rasenpolys an den Airports jetzt aussehen. Wenn ich mich recht an die Versuche bei den Hochspannungslinien zurückerinnere normal.

Ich selbst komme vermutlich erst nächste Woche dazu mir selbst das Problem anzuschauen. Wenn es mit dieser Variante Nr.1 klappt und Ihr keine Probleme entdeckt ist das vorerst OK. Die Endlösung ist es nicht. Daher bitte keine weiteren Danksagungen oder ähnliches sonst denken einige das ist jetzt die Lösung.z.B.


Zu Horst
Habe jetzt keine Lust Dir extra auf deine Frage eine Mail zu schreiben oder was auf die Homepage hochzuladen. Daher mach ich hier weiter.

Für alle anderen ist das lesen ab hier freiwillig.

"Warum sehen wir bei Addons keine Laternen auf den Strassen"?

Antwort:
Weil es nicht so programmiert wurde.
Es ist ganz einfach. Ehrlich gesagt ich habe gar überlegt dem User Files anzubieten wo diese Lampen/ Strassenschilder usw. fehlen.
Schau Dir die Autobahnen an. Da stehen außerhalb von Ortschaften in der Mitte von Autobahnen Strassenlampen und am Rande Strassenschilder mit dem MS Flugzeug drauf. Ist das realistisch ? Meine Meinung Nein.

Diese ganze Geschichte macht erst Sinn wenn Landclass passt also Städte da sind wo sie hingehören. Und wenn sich jemand des Strassensystemes annimmt, damit auch das so verläuft wie es sich gehört. Dann programmiert man Strassen mit Lampen nur da wo sie hingehören. In die Stadt! Nicht aber an die Überlandautobahn so wie jetzt. Man kann das auch ganz einfach mit jedem Designtool wie Ground 2K oder SCC programmieren. Ob es bei z.B Ground 2K schon unterstützt wird weis ich nicht. Wenn man sich mit dem ASM Code auskennt ist das kein Problem dieses auch nachträglich zu manipulieren. Das geht sogar mit Wordpad an der fertigen BGL. Oh Gott ich werde zu lang.

Kürzer!

Zu deiner Frage.

Schau Dir die Texturnummern der terrain.cfg an.

Beachte die Zeile VectorAutogen=

Dann suche weiter unten nach der Nummer bezüglich der Autogennummer.

Da fíndest Du sowohl die Hexnummer des dazugehörigen Bibliotheksobjekt als auch die Steuerparameter usw.

Hat MS diesmal sehr gut dokumentiert.

Ich sage nur Spielwiese.

Habe teilweise schon halbwegs erfolgreiche Tests gemacht bezüglich Wäldern die sich dem Mesh auffadieren. Soll heissen man hat ein Mesh. Liegt wie bisher ein flacher Wald darauf mit ein paar Autogenbäumen kommt das nicht richtig rüber. Durch Trickserei kann man die Waldtextur wie in der Realität ca. 20 bis 30m über dem Mesh anheben dann kommt das der Realität sehr nahe. Da bin ich momentan dran. Problem ist der Randbereich, die Flankensteilheit und die Maskierung mit einer Textur, bzw. ein paar Baumwipfel die aus der angehobenen Waldfläche rausschauen damit es realistisch wirkt. Aber auch dazu habe ich Ideen.

Nächste Frage:

Warum ist der default Fluss von MS (besser geschrieben: dessen Einbuchtung) bei exclude im Mesh noch immer zu sehen?

Ganz einfach man muß die Priorität beachten. Der Linienfluss wird gezeichnet. Die Zuweisungsnummer steht in der terrain.cfg. Anhand dessen findet der FS auch die Texturzuweisung inkl. Effekt wie Wellen usw. Weiterhin natürlich die Textur. Er findet aber auch über den Autogen Eintrag Offset=-20 eine Meshbeinflussung. Hier -20Meter.

Sprich der programmierte Linienfluss drückt eine Senke von 20m in das Mesh. Bei 20 eben einen Hügel von 20 Meter. Nur so nebenbei da jemand den Parameter in diesem Thread erwähnt hat. Hat der Terrain_max_vertex_level eine Zahl oberhalb 19 wird diese Senke in der Flanke steiler. So um auf die Frage zurückzukommen warum dieses trotz Exclude sichtbar bleibt. Der FS muß natürlich halbwegs logisch vorgehen. Leider beachtet er hier nicht die unterschiedlichen Topografieelemente. Er liest im Prinzip alle höhenrelevanten Daten aus um das Drahtgitter also das Höhenmodell zuerst aufzubauen. Da bekommt er natürlich jetzt von den Straßen oder Flüssen die Meshbeinflussung mit. Sprich das Mesh ist durch einen Linienfluss -20 Meter schon mal versaut. Irgendwann kommt später erst die optische Information des Linienflusses also die Textur. Diese optische Information kannst Du excludieren. Mehr nicht, die Senke bleibt, da sie viel früher entstanden ist. Abhilfe den gleichen Code der Linienflüsse noch mal laden jetzt mit +20Meter. Geht ohne Probleme alles damals nach erscheinen des FS2004 ausprobiert. Leider gibt es noch die Möglichkeit keine Änderung in Metern einzugeben sondern den Befehl flat. Sprich das Mesh in dem Bereich von z.B Strassen waagerecht platt zu machen um realistische Einschnitte in einen Hang zu schneiden. Das ist ein Befehl den kannst Du nie mehr rückgängig machen, da ja kein mathematischer Faktor angegeben ist. Du weist ja auch nicht welche Höhenwerte in dem Mesh vorgelegen haben. Leider! Ich glaube auch nicht das MS uns in einem SDK so eine Art Interpolationsliniencode in die Hand drückt um das nachträglich auszubügeln. Die einzigste Möglichkeit die ich sehe ist es zu verhindern das dieser z.B Strassencode erst gar nicht gesendet wird. Das geht nur über löschen des ganzen Default Files. Was bedeutet man muß alle Strassen des entsprechenden Files neu nachzeichnen um kein Loch im Strassensystem entstehen zu lassen.

Im Prinzip das was ich vor ein paar Monaten hier ins Forum geschrieben habe bezüglich ATP Problemes. Wäre alles nicht so schlimm. Leider decken sich die Files nicht mehr mit den FS2002. Darauf habe aber einige Teams aufgebaut.

Gruß Joachim

Hallo!

Sehr interessante Diskussion hier!

@JOBIA:
Danke für die Erklärung. Werde mal probieren, Autobahnen um einige Meter anzuheben, was meiner Meinung nach ja oft auch in der Realität so ist. Dass würde dann aber wohl bedueten, auf "flat" zu verzichten, was ja manchmal auch ganz interessant sein kann. Ob das geht?
Du wolltest wissen, wie die Airport-Polys aussehen? Ganz einfach - die sind WEG! Wer sich mal nach Tempelhof begibt, wird schnell realisieren, wie blöd das aussieht. Deshalb werde ich auch wieder zur original terrain.cfg zurückkehren. Blwibt zu hoffen, dass es eine endgültige, elegantere Lösung gibt. Bis dahin werde ich die Rasenstücke eben vor jedem Schweiz-Flug ausschalten müssen...

Gruß, Felix

Wie gesagt ich habe es mir selbst noch nicht angeschaut. War aber meine Vermutung weil sich hinter der Zuweisung ganz im Gegensatz zum FS2002 keine Textur mehr verbirgt sondern nur noch diese Mapping Funktion.

Ehrlich gesagt diese Chamöleonairportpolys haben mir noch nie gefallen. Hat man ein Landclassfile welches Kornfeld unter einem Airport hat, dann wird in diesem Bereich vertrockneter Rasen gemappt.

Ist in EDDF bei mir der Fall.

Es wäre aber kein Problem die terrain.cfg so zu ändern das wieder Texturen sprich Landclass zugewiesen wird. Dann haben wir feste stabile Polys. Da passt dann auch die GAP Serie dann wieder besser zu.
Sie verwendet ja wie gesagt in Teilbereichen eigene. Wir könnte uns dann passende raussuchen und diese für die GAP Serie im Haupttexturordner ablegen.

Zu diesem ersten Probeflug der hier angegeben wurde welches Barth LC File brauche ich da. Das Bayern. Welches Mesh wurde verwendet nur das Allemagne von Faitman oder auch noch andere. Denn nakcig kann ich den Fehler im FS anhand des Fluges der da zum download war nicht nachvollziehen.

Noch 'ne kleine Info...
 

... zum ursprünglichen Problem:

FS2004, Mesh suisse_mesh (nur scenery-Ordner mit mesh-bgl, natürlich), keine Addon-LC's mehr aktiv (soweit ich's feststellen konnte ;) ). Crash, wenn der Flughafen Sion dargestellt werden soll. suisse_mesh deaktiviert: Alles klappt.

Mit aktivem suisse_mesh und versuchsweise auch Joachim's vierter terrain.cfg (dohneclassmap): Alles funktioniert (sieht die Landschaft etwas anders aus?), auch mit allen anderen (LC)addons. Mit Joachim's terrain.cfg a) geht's ebenfalls.

Die Slopes in der Umgebung Sion sind MIT mesh sehr steil, ohne relativ sanft. Sim-Zeit: Tag, 26. November.

Viele Grüsse
Peter

Ich hatte zum Zeitpunkt dieses Fluges nur die LC-Files von F. Barth und das Faitmen-Mesh aktiviert.
Vermutlich dürften - der geografischen Zuordnung entsprechend - die Bayern-LC-Files genügen, bin mir aber nicht sicher.

LC- bzw. Scenery-Files für die Schweiz habe ich nicht verwendet.
Die Crash-to-Desktop-Situation bei Sion kam auch erst später als weiteres "Corpus delicti" in der Erfahrung anderer hinzu, dürfte also für den von mir geposteten Flug daher eher unerheblich sein.

Eigentlich habe ich es nicht als Frage hingeschrieben sondern eher als Hinterfragung für so manchen Flusianer. Also eher ein Ansporn zum Nachdenken.
Aber wie immer eine kurze ausgezeichnete Erklärung.

Ich halte nicht viel davon, wenn sich zwei per Email unterhalten, denn dies hilft dem Dritten der ebenfalls nach Lösungen sucht, überhaupt nicht. Und mit einer Homepage kann man auch keine Dialoge führen.

Gehört zwar nicht zu Crash-to-Desktop, hatte leider noch keine Zeit weiter zu testen, um zur Aufklärung der Zusammenhänge beizutragen, aber:

-Ich sage nur Spielwiese.
Glaube ich auch.

Zu den Flusseinschnitten:
Ein Punkt von vielen auf meiner Liste (der Tag hat leider nur 24 Stunden), wo ich noch nicht nachgeforscht habe.
Hier stelle ich mir schon länger die Frage, warum man das Flusssystem nicht an den Mesh anpassen kann?

Nachdem die Taleinschnitte ja vom Fluss erzeugt worden sind, gehört er an den niedrigsten Punkt der Meshdaten für diesen kleinen Abschnitt (Problem sind sicher die Zuläufe an den Hängen, und wie weit die Daten von tiefsten Punkt abweichen).

Natürlich kann ich dies nur für bestimmte Meshdaten nützen, aber vielleicht ist eine kleine Routine machbar, mit der man dies selbst einfach abändern bzw. an seine Meshdaten anpassen kann.
Also die Linien an den niedrigsten Punkt verschieben.

100 % wird man nie erreichen, da ja die Meshdaten ja auch nicht ganz stimmen. Sie würden aber dann wenigstens halbwegs zusammenpassen.
Für kleinere Abschnitte müsste man dies dann individuell anpassen.

Wie geschrieben, dies habe ich wirklich noch nicht durchgedacht und vielleicht steht ja irgendwo, dass dies absolut nicht möglich ist. Es geistert halt nur manchmal in meiner laienhaften Phantasie herum.

Horst

Probleme mit Mesh
 

Hi

In Sestri (Genua) stehen oder besser gesagt hängen die beiden Default Maschinen (im Hintergrund) ca. 1 Meter in der Luft.

Diese FS 2002-Szenerie funktioniert aber sonst im FS9 einwandfrei.

Herbert

Herbert
Dies ist meiner Meinung nach ein schlechtes AFCAD- File. Ich habe zwar noch nie eines gesamt erstellt, sondern nur abgeändert. Hier findet man ja wirklich genügend mehr oder weniger gute bgl-Dateien.
Aber dieses Problem war im FS2002 das Problem, wenn bei der Erstellung des AFCAD nicht 29,92 eingestellt war und damit die Höhendaten des Flugplatzes nicht gestimmt haben.
Aber diese ISD Szenerie hat glaube ich noch keinen Update erhalten (daher gibt es kein passendes AF file) daher kann es auch andere Fehlerquellen beinhalten.
Warte auf den Update, den in diesem Zustand kannst du in ja auch nicht richtig anfliegen.
Man möge mich korrigieren.

Peter
Du musst jede bgl-Datei ansehen, um zu wissen welcher Code hier drinnen ist.
Den im Prinzip ist es egal, wie man die bgl Datei nennt, wichtig ist der Inhalt.
Und hier geht jeder Autor anders vor (ist ja im Prinzip auch sein Recht) und nennt sie nach seinen Vorzügen, die man halt nicht immer nachvollziehen kann.
Es können auch in nicht LC bgl Dateien, diese Information stehen.
Wenn ein vernünftiger Autor bereits LC oder EXL oder FLAT oder ME oder OBJ oder AF2_ usw. nennt und dann erst seine Kürzel, dann weiß man ja relativ rasch, was man suchen soll.
Dies macht die Suche nach Fehlern eben sehr, sehr mühselig und zeitaufwendig.

Horst

Zum (Ur)Thema: ich glaub ich hab's!
 

Zumindest für meinen Teil. Weil die Fehlerproblematik offensichtlich so komplex ist, kann ich nur für meine CTD-Probleme sprechen.

Ich habe Joachims Terrain.cfg durchgetestet. Machen wir es kurz: mit wenig erbaulichem Ergebnis. Alle 4 Varianten in der exakt gleichen Testconfiguration: Flug am 8. Nov. um 8.31 Uhr von Vrsa nach Portoroz.
Flugzeug: die original C172. Und die Resultate waren so was von unterschiedlich - aber egal welche Cfg ich verwendet habe! Eimal konnte ich nicht einmal die Startsituation laden (mit Version 1). Dann dachte ich Version 2 ist es! Doch auch schmecks.. nach 20 Minuten crasht der FS. So ging es weiter mit allen Varianten. Einmal gings bis kurz vor der Landung in Portoroz, dann konnte ich gar landen und wieder starten, kam dann aber nur mehr bis kurz vor Vrsa...

Jetzt habe ich alle Originaltexturen wieder aufgespielt. Den Texture-Ordner im Hauptverzeichnis. Wieder Crash! Den Textureordner im Scernery Word Verzeichnis: und siehe da - keine Abstürze, 4 mal hin und her zwischen Vrsa und Portoroz - nix. Keine Abstürze!

Jetzt hab ich den Verdacht - und den hatte ich eigentlich von Anfang an - dass ich mir mit irgendwelchen Austauschtexturen ein faules Ei gelegt habe. Ich werde auf jeden Fall weitertesten. Nach dem gestern der Flusi ja auch längere Zeit nicht gecrasht ist (Version 2 von Joachim), bin ich noch immer nicht ganz sicher, ob ich den Fehler gefunden habe.

Was ich auf jeden Fall auch feststellen konnte - und das wurde hier ja bestätigt - gibt es zusätzlich noch einen Zusammenhang mit den Jahreszeiten. Aber das alles auszutesten hat mich viele Nerven und Stunden gekostet - und wird's wohl auch noch. Bin gespannt was rauskommt.

Bernd

Hallo Horst,,
 

ja, aus dem Grund habe ich alle(!) addons in der Scenery-library deaktiviert, ausser suisse_mesh (und den originalen FS-Einträgen). Es besteht allerdings noch die geringe(!) Wahrscheinlichkeit, dass aus einer früheren Installation LC-bgl's sich irgendwo in der FS9\scenery herumtreiben.

Leider ist das also kein schlüssiger Beweis, dass ein "jungfräulicher" FS9 plus "Nur-mesh" den crash macht. Es besteht ja auch noch eine Restwahrscheinlichkeit, dass im suisse_mesh irgendwelche LC-Daten stehen - ich glaub's aber eigentlich nicht (ist nur EIN bgl):

Ich werd' halt den Verdacht nicht ganz los ;)

Viele Grüsse
Peter