Unverträglichkeit von Mesh und Free-Landclass?

[JOBIA]

Das ist ja das was ich sagte bei Default FS bekomme ich in SION keinen Crash hin egal zu welcher Jahreszeit. Das Schweizer Mesh wollte ich mir nicht downloaden. Ich saget ja auch das das Mesh einen Texturwechsel erzeugt der wird hier durch das Mesh ausgelöst. Dann crasht es eben. Lieder kann diese Landclass die hier das Maleur in Verbindung mit dem Mesh auslöst auch ohne jegliches Mesh programmiert werden. Kommt diese in den Bereich eines Airportpolys mit MaskClass 2 dann crasht es. Das Airportpoly liegt übrigends in dem File AB.... deshaln spilet dieses mit rein. Nur leider scheint es nicht nur diese eine Landclass zu sein die den FS crashen lässt.

Wie gesagt mir wäre eine Defaultsituation lieber zum testen.

[Horst LOWW]

Eigenartig, den ich habe den FS9 glaube ich wirklich „jungfräulich“ hinbekommen.

Also müssten wir noch die FS9 Einstellungen und die Grafikkarteneinstellungen überprüfen.

Oder es meldet sich noch jemand der schreibt das diese Situation wie oben, bei im auch crasht. Dann können wir ja unsere und deine Einstellungen vergleichen.

Aber ich glaube, es sind wirklich leere Kilometer, dies zu testen.

Du wirst sicher eine Situation irgendwann finden, die auch bei dir funktioniert und einen Crash verursacht, wenn du die default terrain.cfg benutzt. Obwohl es derzeit besser wäre, wenn du eine Stelle kennst.
Ich glaube im Frühjahr werden noch mehr Fragen diesbezüglich auftauchen.
Oder irgendjemand meldet noch einen Stelle.
Hängt ja von Tages- Jahreszeit ab.

Ich habe gleich nach dem Erscheinen des FS9 eine Situation in Seattle gehabt, da ich meinen ganzen Szenerieordner aktiviert habe, um dann langsam alle Fehler auszubessern.
Später habe ich noch zwei bis dreimal eine Situation gefunden (eher unabsichtlich). Da habe ich immer das passende LC File von einem Addon gefunden.

Vielleicht finde ich Zeit diese Situationen nochmals zu erzeugen, ohne dass du da viel runterladen musst.

Aber es ist sicher besser die Auswirkungen der terrain.cfg weiter zu testen, bis wir auch mit dieser eine Crashsituation finden.

Horst

[Horst LOWW]

Wie geschrieben , das Testen und Suchen ist eine Katastrophe.
Und das Erzeugen einer Situation, die bei jedem crasht, noch ärger.
Der Fehler wird erzeugt, hat aber zu viele Parameter oder Möglichkeiten.

Im Prinzip sollte man hergehen und ein eigenes LC mit Fehlern erstellen, die diese Theorie unterstützt. Dies auf sämtlichen Systemen durchtesten und dann hoffentlich eine Erklärung finden. Aber dies ist auch schwierig und eigentlich unnötig, wenn gar unmöglich.

Besser gesagt unnötige Zeit.

Ob dies Addon Mesh oder default Mesh ist, ist meiner Meinung nach, wirklich egal.
Es crasht auch bei anderen Situationen in default mesh (zumindest soweit ich es in Erinnerung habe).

Daher : terrain.cfg
MS hat diese Möglichkeit eingebaut, damit sie diesen (oder auch andere) seltene Fehler (vielleicht ist er auch nicht so selten) aushebeln können.
Wie man sieht es gibt es sehr, sehr viele Möglichkeiten.

Ich kann z.B Christians Flug nicht mit einem Fehler beenden (irgendwann hört man auf in der Gegend herumzufliegen).
Ich kann Herberts Flug mit einen Crash beenden, aber erst nach 10 Minuten.

D.h. Wann arbeitet er den Vorgang mit dem Fehler ab?
Dies sind noch 100 Fragen.(Höhe, Wetter, Sichtweite, Jahres und Tageszeit, usw.)

Daher habe ich alles nur mit dieser Standartsituation getestet. Und dies crasht 100 Prozent bei mir.

Dies ist nur ein Hobby (daher auch eine Zeitfrage, dies alles durchzutesten), und vielleicht erkennt man nach einigen Monaten die Zusammenhänge, je mehr Fehler man registriert (denn es ist von zu vielen Parametern abhängig).

Ich verwende noch immer LC ohne Lichtmasten und habe bis jetzt keine Autogen-Probleme? (noch mehr Sachen zum Aufklären, zumindest für mich)

Also testen wir lieber verschiedene Terrain-Varianten, als diese Ursachenforschung zu betreiben.
Ist ja einstweilen damit behoben.

Und für dies alles braucht man sehr, sehr viel Geduld.

Horst

[Lexif]

Hallo!

Horst, ich habe immer noch Landclass-Bäume auf den Aprons. Und zwar mit beiden Varianten (mit/ohne Linien unter den Hochspannungsleitungen), und zwar auch in Sion!

Gruss, Felix

[Horst LOWW]

Ich habe gestern noch weiter geforscht und werde dies vielleicht am Nachmittag oder Abend zusammenfassen und Bilder anhängen.

Horst

[Rainer Hofmann]

Hi ,
seit der veränderten terrain.cfg (1) von Joachim habe ich keine Crashes mehr gehabt ; ich bin stundenlang von Nizza über die Schweiz geflogen und habe jede Ecke von Sion erkundigt : Ergebnis ....alles im Normbereich.
Grüße
Rainer

[Peterle]

Rainer, auch keine Bäume auf den Rollwegen und den Aprons? Wie hast Du den Schieber für die Autogen-Dichte eingestellt?

Viele Grüsse
Peter

[Rainer Hofmann]

Apron u. RW sind baumfrei ; autogen ganz nach rechts .
Gruß
Rainer

[Peterle]

... dann endlich total im Nebel - bei mir grünt und blüht es mit der gleichen terrain.cfg (aus der terrain.zip) und Autogen ganz rechts überall kräftig...

Danke für die Info
Peter

[JOBIA]

Hallo

Es gab ja bei meiner letzten Landclass terrain.cfg Varinate das Autogenproblem (Büsche, Bäume zwischen den Taxiways und auf dem Vorfeld).

Ansonsten kam es mit dieser bisher offensichtlich nicht zum Absturz.

Um dieses Autogenproblem zu verhindern wollte ich eine terrain.cfg Variante anbieten bei der anstatt auf Landclass direkt auf die entsprechenden Texturen verwiesen wird.

Leider hat es hierbei Probleme gegeben. Z.B verweist der FS bei Landclassnummer 128 zufällig auch auf die Texturserie die mit 128 im Namen beginnt hin. (das ist nicht immer der Fall) Hier und bei einigen anderen Einträgen ist es aber leider so.

Jetzt macht mir der FS2004 einen Strich durch die Rechnung.

Der FS liest bei einer Texturdefinition in der Terrain.cfg wie z.B 128b2su1.bmp die Textur erst gar nicht richtig aus. Er liest die Information von vorneweg. Da es aber auch die Landclassnummer 128 gibt, erkennt er diese Information in den Namen 128b2su1.bmp natürlich. Er ignoriert dann einfachden Rest ... b2su1.bmp.
Er hat bei 128... schon die Entscheidung getroffen das es sich um die Landclass 128 handelt die zugewiesen werden soll. Schon haben wir wieder Landclasszuweisung inkl. Autogen bei dem Rasenpoly.

Daher komme ich nicht drum herum ich muß auf andere Texturnamen verweisen. Daher müssen jetzt auch Texturen zwangsweise neu installiert werden.

Zusätzlich mußte ich darauf achten das hier alle Jahreszeiten sauber durchdefiniert werden. Lässt man das weg crasht es auch. Da es bei einigen Landclass aber keine Jahreszeiten wie Winter oder z.B Frühling gibt muß hier dann in der Regel Sommer als Ersatz definiert werden. (Landclass macht dieses automatisch)

Auch mußte ich für die Nacht extra Texturen erstellen. Bei Landclass ist das in der Steuerdatei lclockup.bgl definiert ob Nachttexturen vorhanden sein müssen bzw. ob der FS diese eigenhändig simmuliert. Da ich jetzt aber wegen des Autogenbewuchses von Landclass auf reine Texturen über VTP2 Polyzuweisung umschwenke muß ich diese Nachttexturen eigenhändig nachreichen. Würde ich das nicht machen könnte es passieren das man zwischen den Taxiways ev. leuchtende Landclasstädte sieht wenn der Airport in einer Stadt liegen würde.

Da ich damit noch nicht ganz fertig bin, kommt das ganze vermutlich erst morgen oder übermorgen. Auch werde ich es nicht mehr hier als Anhang liefern können, da das ganze zu groß ist. Ich werde es hier verlinken oder man wird es dann auf meiner Homepage runterladen müssen.

Anders geht es momentan nicht. Klar könnte man jetzt bei Sion diese Situation nachstellen die betroffene Landclass ausfindig machen und durch einen Landclasspatch beheben. Nur ehrlich gesagt ich traue Microsoft nicht. Es kann sein das nur eine einzige Landclass dieses Problem erzeugt. Sicher kann man aber nie sein. In einer Woche lädt sich irgendjemand ein neues Landclassfile und es geht wieder von vorne los, weil jetzt eine neue Kombination vorliegt.

Letzendlich ist meine Variante der terrain.cfg auch nur als Notlösung zu sehen, da es mir eigentlich wiederstrebt eine so wichtige Steuerdatei in geänderter Form anzubieten.

1) Ein Garant das jetzt alle Fehler weg sind ist sie auch nicht. Es ist nur ein Versuch allen möglichen Problemen vorher aus dem Weg zu gehen.

2) Wenn das alle machen würden, dann hebt man z.B meine Funktion in der terrain.cfg wieder aus und spielt eigene Funktionen ein. Daher sollte man eigentlich die Finger davon lassen.

Ein Vorteil hat sie allerdings. Man bekommt diese hässlichen unnatürlichen Streifen bei den Hochspannungsmasten weg.
Auch sehen die Airportpolys jetzt einheitlich aus. Sie verhalten sich unabhängig von der darunterliegenden Landclasscenery. Der Rasen ist in der Regel in Nordeuropa grün und nicht innerhalb der Rasenfläche mal grün oder total vertrocknet. (Chamäleoneffekt)

Einzige Ausnahme wenn durch so ein Rasenpoly eine Jahreszeitengrenze verläuft. Habe mir die entsrechenden Dateien noch nicht angeschaut.

Optisch sieht es aber bei SION danach aus.

Weiterhin will ich mal sehen wie das ganze zu den German Airports passt die hier teilweise Teilpolys mitbringen. Kann aber eine Aussage nur machen für die GAP Versionen mit Freepatch auf FS2004. Ev. muß ich aus optischen Gründen hier ein paar Tauschtexturen anbieten. Im Prinzip dürfte es aber zum Teil auch vorher schon nicht zu diesen bisherigen Chamäleonpolys gepasst haben.

Wenn man das Problem ohne Änderung der terrain.cfg angehen will und trotzdem auf der sicheren Seite sein möchte kommt man nicht drum hin sich spezielle Mesh und Landclasstestfiles zu erstellen. Weiterhin müssen großflächige VTP Polys mit allen verschiedenen MaskClassMap Werten erstellt werden. Dann heisst es alle Kombinationen durchtesten und immer wieder ev. fehlerverursachende Kombinationen auszufiltern.

Das kann etwas dauern.

Da ich bei der Suche nach dem Problem warum im FS2004 Landclassfiles so anders aussehen schon einige Entdeckungen gemacht habe, denke ich könnte es sogar sein das es hier im FS2004 auch Layerprobleme in Verbindung mit Landclass gibt.

Neueres ev. morgen oder übermorgen.