Moin zusammen,

@Rolf:

Eine sehr gute Frage. Hoffentlich alle bei Aerosoft melden. Nur wird dies nicht passieren, weil wohl viele ganz sicher gar nicht merken, wo dann schlußendlich das Problem überhaupt zu suchen ist.

Muß man gar nicht nur an die Leute ohne Internet denken. Gehe mal in andere Foren. Was da manchmal an Zusammenhängen sich selbst irgendwie erklärt wird und mögliche Ursachen und Lösungen beschrieben werden... grauenvoll. :confused:

Von den vielen "Kids" mal ganz zu schweigen, die jede auch nur irgendwo erhältliche Austauschtextur einfach mal in den FS einspielen und damit für die meisten Probleme selbst sorgen. Kein FS ist 2 Monate nach der Installation mehr mit einer zweiten Installation zu vergleichen. Eine Sammlung von absolutem Chaos mit allen möglichen Addons, deren gegenseitige Lauffähigkeit unmöglich überall getestet werden kann.
Hier aber nicht das Thema und das Problem der CTD besteht definitiv. Wurde aber vielleicht aus obigem Grund anfangs einfach unterschätzt und falsch betrachtet.

@all:
Peter ist daran (aber auch nur hier... :p ) unschuldig. Habe ich ja mehr als deutlich eigentlich schon früher hier geschrieben.

Die Scenery Germany liefert Mesh, Landklassen, Flüsse und Flugplätze (natürlich neben den sonstigen VFR-Merkmalen) Alles unter dem FS2002 entstanden.

Flugplätze sind relativ unkritisch. Die verwendete Technik wird (bis auf gewisse Texturprobleme) im FS2004 (wenn auch langsamer) unterstützt. Layeränderungen sind dabei auch kein ernstes Problem.

Flüsse waren bis Januar absolut fehlerhaft. Da ich mit denen auch hier und da schon im FS2002 Abstürze hatte (da aber niemals genau den Grund lokalisieren konnte) war hier eine Fehlerursache auf jeden Fall zu suchen. Da ich ja selbst mit einer eigenen Arbeit im Spätsommer letzten Jahres dieses Problem hatte konnte ich hier meinen Kollegen fein helfen und meine Flüsse bei ihnen integrieren. Die sind jetzt auf jeden Fall "sauber".

Mesh und Landklassen führten nach dem 3.1-SG1-Patch (meine Flüsse) halt weiterhin zu Abstürzen. Jobia schilderte dies auch schon sehr oft sehr ausführlich... ein genaues Mesh mit detaillierten Landklassen führt unter Umständen zu den von ihm gefundenen Maskierungsproblemen...

Was soll Aerosoft da machen? Wer hat eine überzeugende Idee? Es geht wohl nur durch Anpassung dieser zentralen terrain.cfg. Kein Schlaumeier weltweit hat was anderes bisher dazu gefunden. Und dies hat Aerosoft dann halt gemacht... und zwar so, wie auch schon Burkhard Renk in seinem MyWorld-Forum beschrieben hatte. Wer denkt denn ernsthaft, dass die dort nur einfach auf einen Patch eines Users im Internet verweisen können? Elegant und stilvoll wäre es natürlich gewesen, z.B. mal Joachim zu fragen, ob sie seinen Patch einfach einbauen können... :rolleyes:

Ist wirklich dumm.... die SG1 ist eine Zusammenstellung von vielen verschiedenen Designtechniken, die auf Grundlage der momentan erhältlichen SDKs (also größtenteils die des FS2002) fehlerfrei erstellt wurde. Habe ja schon x-mal hier eine kleine Liste beschrieben, wie ich die SG1 bei mir auf meinem Rechner komplett fehlerfrei ohne jeden CTD oder sowas laufen habe. Dabei ist natürlich der "Jobia Patch" absolute Voraussetzung.

@Schubi:
Absprache ist hier aber - glaube ich - ganz sicher nicht das Problem gewesen.

Das Maskierungsproblem ist meiner Meinung nach erst dann zu umgehen, wenn man darüber was in SDKs lesen kann. Vorher ist Jobias Patch einfach Pflicht.

Ciao,
Rainer.

Hi Rainer,
im groben und ganzen genau mein Reden(schreiben).
Das sehhe ich allerdings anders.
Ich kann mir absolut nicht vorstellen,daß niemanden von den Machern oder von der Aerosoft GmbH noch nichts über einen gewissen JOBIA gelsen haben.
Gerade seine Docs sind doch genau u.a. für solche Herren geschrieben.
Wenn auch nur einer etwas davon gelesen hätte,dann wäre dieses mit einer Absprache untereinander der ideale Weg gewesen.
Org.geschrieben von Joachim:
Ich denke das ist der Punkt!!!
Problem ist hier,das B.Renk eben nicht ganz richtig liegt/lag!
Und Du schreibst es selber............
Langsam stinkt mir diese Arroganz ,da hat jemand die problematik erkannt ( nicht zum 1.mal), zusätzlich Dokumentiert und niemand will sich die angebliche blösse geben.
Soetwas finde ich Krank:(

Org.geschrieben von Joachim:
Scheinbar hat man Dich darauf angesprochen?
Wenn dem so sei,wäre dieses genauso wie es sein müsste und man braucht in Zukunft nicht mehr mit soetwas zu Rechnen.

Mir geht es hier auch nicht speziell um Aerosoft oder das Peter Werlitz Team,sondern nur darum,daß solche Fehler gar nicht mehr passieren.
Wie ihr wohl merkt,senkt sich mein Blutdruck wieder;)

Tja - die SG1
 

...ich kann mich über Aerosoft nicht beschweren, es besteht reger Mailkontakt mit ernstzunehmender Hilfestellung.

Habe die Online-Patches installiert, sogar noch ein weiteres dazu erhalten.

Ging alles nur ein paar Flüge gut - solange die Flug- oder Rollgeschwindigkeiten höher zu werden scheinen, gibts wohl nach wie vor sogenannte Textur-Lade-Probleme.

Mein fs09 leidet - trotz Neuinstallation, "jungfräulicher" cfg - wieder unter CTD.

Siehe anderen Thread.

Ätzend. Langsam bin ich's leid. Vielleicht liegts ja auch daran - daß es ein MICROSOFT-Produkt ist.

MfG
Andreas

a)
Ein „Sticky“ im Forum der My* Produkt Serie.
http://forums.simflight.com/viewtopi...1a478bbf7fa10e

b)
Die Ersetzung und der Austausch von Orignaldateien, natürlich auch der Vertrieb, (von sämtlichen Dateien) des FS unterliegt dem Copyright von MS. Für Zusatzprodukte natürlich beim jeweiligen Hersteller. D.h, wenn du die terrain.cfg mit einem Schreibschutz versiehst und sie wird trotzdem „getauscht“ – ist dies rechtlich sehr bedenklich (auch Austausch von Texturen.
Wenn ich durch ein Installationsprogramm nicht explizit darauf hingewiesen werde, dass meine Originaldatei „manipuliert“ wird, ist dies ebenfalls rechtlich sehr bedenklich (Änderung der fs9.cfg).
Außer es handelt sich um eine neuere Version von MS selbst.
Als Autor, Entwickler oder Produzent darf man sich darüber ruhig Gedanken machen.

c) Der FS kracht erst bei TMVL von 20 oder 21 (siehe CTD Sion). Diesen kann man nur durch Änderung der fs9.cfg einstellen. Im Spiel ist dies nicht möglich. Dies ist kein Bug von MS und ihrem FS, sondern ein Fehler nur in Verbindung mit manipulierten Dateien oder Zusatzprogrammen.

Diese Problematik betrifft im Prinzip sehr viele Hersteller (Ausnahmen bestätigen die Regel).

Horst

Hallo Horst,

Ist leider nicht korrekt. Auch mit 19 kommt es zu CTDs, nur ist die Chance darauf geringer. Schließlich haben die Masken auch was mit der Steilheit der Abhänge zu tun (wenn ich Jobia die ganze Zeit richtig verstanden habe).

Ciao,
Rainer.

@ Rainer

Kannst du im Prinzip Recht haben.
Es wurde, ja soweit ich überall mitlese, bis jetzt nicht genau aufgearbeitet. Bzw. gibt es zuwenig (ich kenne keine) Stellen, wo dies mit einem nackten Flusi und 19 ebenfalls aus diesem Grund kracht. Oder ich habe diese Stellen und Beiträge überlesen.
Jaochim hat den Fehler zu schnell entdeckt :) (und die meisten haben seinen Patch)
Bzw. hat keiner einen nackten Flusi.
Holger hat uns in Sion darauf hingewiesen – Erhöhung des TWML – da es bei Joachim nicht gekracht hat mit default Szenerie.

Es macht für mich auch wenig Sinn, jetzt den Fehler MS nachzuweisen.
Besser wäre es, eine rechtlich unbedenkliche Lösung für Zusatzprogramme zu finden.

Übrigens Danke für OWL2003-fs2004, mit vorbildlicher Installation und Beipack PDF. Bin erst jetzt dazu gekommen. Ich denke, es wird jeder schaffen die Szenerie in seinen FS zu integrieren. Meine Ordnung wurde nicht zerstört, und mit einem sehr schönen Produkt erweitert. Danke

Horst

Hallo,

wenn man in der terrain.cfg Dinge wie z.B. Mask Class Map verstellt was sind die konsequenzen ? Auf was muss man verzichten ? Wird das Mesh ungenau oder funktionieren irgendwelche Add-Ons nicht mehr ?
Vielen Dank im Voraus.

Philipp

Korrekt hast Du im Prinzip richtig verstanden Rainer. Der LOD Level also der Punktabstand der Höhenpunkte wird durch das Mesh vorgegeben. Hat man ein Mesh mit sehr hoher Auflösung z.B LOD11 wird dieses erst durch Manipulation des TMVL sichtbar. Ohne dieses arbeitet es nur mit niedrieren LOD Level.

Ausschlaggebend für diesen CTD ist allerdings die Flankensteilheit von einem Höhenpunkt zum nächsten. Da ist es im Prinzip egal wie hoch der LOD Level des Mesh bzw. der Wert des TMVL ist. Beispiel TMVL auf 21. Rasterabstand des Mesh 38Meter. Der eine Punkt hat eine Höhe von 0 Meter der andere 38Meter. Ergibt eine Flanke mit 45°. Nehmen wir mal an diese löst mit entsprechender Landclasspositionierung und Mask Class Map Funktion einen Crash aus.

Jetzt sagt man. "Ja das passiert nur bei manipulierten TMVL Faktor".

Also den Wert auf Default19. Klar jetzt würde ev. einer der Höhenpunkte von 38Meter ausgelassen. Es würde erst der nächste genutzt. Die Flanke würde flacher und wir hätten keinen Crash an dieser Position.


Jetzt komme ich mit einem anderen Beispiel. TMVL auf 19. Ein Mesh mit Rasterabstand 76m Dieses wird bei TMVL 19 ohne Probleme dargestellt.

Der eine Meshpunkt auf 0 Meter der andere auf 76 Meter. Was passiert wir haben eine Flankensteilheit 45°. Was bedeutet dieses. Crash to Desktop bei TMVL19. Jetzt ist es sogar gefährlicher da die Fehlerfläche größer wird.

Auf der anderen Seite dürften diese Konstellationen vielleicht in realen Meshfiles seltener oder an anderen Stellen vorkommen. Auch glaube ich nicht das alle bisher gemeldeten Crashs nur bei Usern aufgetreten sind die am TMVL maipuliert haben, sei es wissend oder unwissend. Einige haben den Crash in SION gemeldet in Verbindung mit einem anderen Mesh. Anderes Mesh bedeutet auch andere Flanken möglich. (auch bei unverändertem TMVL)

Also von daher Horst denke ich werden die Problemstellen einfach wechseln.

Ich muß mal nachschauen von irgendjemand hatte ich eine Mail mit einer Crash Stelle die definitiv auch mit TMVL 19 auftritt.

Noch etwas man muß die verschiedenen Flattentechniken im Auge behalten. Schau Dir LWM Flatten an. Hier ist der Rasterabstand in den bakannten Vectorpoints hat also überhaupt nichts mit dem Raster von LOD zu tun. Bei dem alten Area16N Flattenbefehl verhält es sich wieder anders. Daher können hier Flanken entstehen die nahezu unabhängig von jedem LOD Level oder TMVL sind.

Es ist alles letzendlich nur eine Frage der Höhendifferenzen und der Konstellationen anderer Elemente.

Zu deinem Sticky. Man beachte hier wird nicht die MaskClassMap=2 wie bei meinem Patch geändert. Nur 1 und 3. Es gibt somit kein Airportrasenproblem wie jetzt beim aktuellen SG1 Patch es bedeutet aber auch es können weitere Crashs möglich sein.

Leider habe ich momentan zu wenig Zeit sonst hätte ich mich auch schon mehr damit beschäftigt. Ich habe hier einen Verdacht das es bevorzugt da crasht wo zwei MaskClassMap Funktionen aufeinander stoßen. Wir bedenken in Sion war noch eine kleines Linienflüsschen welches ziemlich nah am Airportflattenpoly kratzte. Was sagt uns das? Wir wissen ein Linienfluss hat eine MaskClassmap Funktion. Das Airportpoly im Prinzip auch. Nur es sind verschiedene MaskClassMap Nummern.


Ein theoretisches Beispiel die LC Nummern stimmen nicht. Es geht nur ums Prinzip. Das Mesh ist steil. Der FS wechselt aufgrunddessen von LC35 auf LC 120. Der erste Wechsel. Von der einen MaskClassmap Funktion der Flüsse möchte der FS z.B von LC120 auf 130 wechseln. An der selben Stelle möchte er durch MaskClassmap des Airportpolys von LC120 auf 140 wechseln.

Mag er diese zwei Wechsel. Crasht er zum Desktop. Wie verhält es sich hier mit den Prioritäten.

Zum größten Übel kommt jetzt noch eine Saisongrenze dazu wie in SION.
Da ist die Hölle los an Schaltfunktionen hinsichtlich Landclass im FS.

Im Prinzip ist das testen gar nicht so schlimm. Trotzdem habe ich momentan andere Prioritäten. Aber ich denke den Bug selbst kann man finden. Nur vermutlich nicht anders als momentan lösen das dürfte das Problem werden.

Zu dieser anderen Geschichte ob da nun wer auf mich verweist oder nicht das ist mir persönlich schon seit längerem egal.

Die meisten hier im Forum dürften eh wissen wer das zuerst entdeckt hat. Das reicht mir um mich in meiner Arbeit zu bestätigen. Ob die anderen das dann aus anderen Foren übernommen haben juckt mich nicht.

Im Prinzip hat es Richard Ludowise ein paar Stunden später entdeckt.
Es passiert halt immer wieder das Leute nahezu zeitgleich Fehler rausfinden.

Nur es reicht halt nicht aus die MaskClassMap einfach auszuschalten. Zumindest nicht bei den Airportpolys. Von daher gibt es momentan nur meinen Weg des Patches.

Dem Richard hat die Scene eh sehr viel zu verdanken. Meiner Meinung einer der wichtigsten Männer in der Designscene. (hatte ich aber schon mal erwähnt) Ohne ihn wäre die damals neue LWM/VTP Technik nicht so schnell programmierbar gewesen.

Meine Aussage bei Punkt c) war nur mit einer original FS-Installation, ohne irgendwelche Zusatzszenerie und Mesh, gedacht.
Aber wahrscheinlich wird man auch hier eine Stelle finden. Da gebe ich euch beiden sicher Recht.

Zu Joachims Text vielleicht 3 Bilder:
Sind alte Bildschirmfotos aus der „Sionaufarbeitung“.

Bild 1
Die Stelle etwas genauer, die ich damals gemeint habe, und wo ich ein Bild angehängt habe.
Hier sieht man das Airportpolygon (grün) und Mesh. Ein kleiner Teil von AB liegt auf dem Mesh.
Dies crasht ohne Joachims Patch.

Die Reduzierung auf 19 alleine bei Holger oder manchen Addon Mesh bringt ja nichts.
(Castlegar (CYCG) und Trail (CAD4)).

„Ich habe hier einen Verdacht, dass es bevorzugt da crasht, wo zwei MaskClassMap Funktionen aufeinander stoßen.“ (Joachim)
Ähnlichen Verdacht hat ja auch Holger damals gehabt.

Manchmal kommt auch ohne Forschung, Licht in die Dunkelheit. Derzeit ist dies wirklich nicht tragisch. Außer man kann auch andere CTD nachstellen (100 Prozent), die mit MaskClassMap Funktionen zutun haben.

Bild 2
Zu Seasonlinie (gibt ja mehrere Seasons) in Sion. Eine verläuft genau N-S (entlang der Gridlinie) wo das Flugzeug steht. Das Bild soll ja nur die Area Linien zeigen (innerhalb des roten Bereichs).

Bild 3
So sieht Sion mit Addon in machen Jahreszeiten aus (habe ich schon einmal angehängt).
Das Zusatzproblem, das Joachim meint.

Hier bringt Joachim wahrscheinlich mit seiner Landclass Doku :) etwas Licht in meine Dunkelheit.

Horst

Bild 2