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
|