![]() |
![]() |
|
|
|||||||
| Simulationen Alles zum Thema Simulation |
![]() |
|
|
Themen-Optionen | Ansicht |
|
|
#81 |
|
Elite
![]() Registriert seit: 15.11.2002
Beiträge: 1.466
|
Nochmals
Das zip von Joachim heißt bezeichnender Weise probtest.zip. Es ist nur zum probieren, aber keine endgültige Lösung von Absturzproblemen(da ja andere Probleme hinzukommen) Horst |
|
|
|
|
|
#82 |
|
Inventar
![]() Registriert seit: 02.01.2002
Alter: 61
Beiträge: 4.238
|
Zu Lexif
Es ist natürlich kein Problem sowohl die Autobahnen anzuheben als auch die Flatteneigenschaften der selben zu erhalten. Ich vermute mal der offset Eintrag zwei mal hintereinander unter einer Zuweisungsnummer wird zum Crash führen das wird wohl nicht gehen. Probieren könnte man es aber. Wenn man gewisse Sachen beachtet kann man aber die terrain.cfg durch eigene Einträge erweitern. Man könnte hier jetzt eine eigene Zuweisungsnummer einfügen. Die Definition macht man mit einer Anhebung von sagen wir mal 1 bis 2 Meter gegenüber dem Mesh je nach dem wie hoch man die Straße haben möchte. Jetzt sucht man sich die Straßen BGLs raus die man manipulieren möchte. Hier von erzeugt man zusätzliche Kopien in denen man auf die neu geschaffene Zuweisungsnummer verweist. Jetzt sorgt man dafür das diese Straßen vor den Defaultstrassen geladen werden. Das war es. Was wird passieren. Der FS lädt die Straßenkopien mit der neuen Zuweisungsnummer und hebt sie über dem Mesh um den Betrag an den Du definiert hast. Sie sind optisch sichtbar aber an einem Querhang natürlich ev. schräg wie wir das vom FS2002 kennen. Irgendwann lädt er den selben Straßencode (den Default) nochmal. Dieses mal aber mit der Flatteninformation. Jetzt wird diese von Dir angehoben Fläche geflattet. Da es deckungsgleiche Codes sind dürfte es keine Probleme geben. Sollte es hier zu geringfügigen Texturstörungen im FS kommen definiert man bei der selbst erzeugten Zuweisungsnummer in der Terrain.cfg keine Texturzuweisung für Straßen. Zum Thema terrain.cfg: Ich möchte nicht ausschliessen das wegen dieses Bugs um den es hier in diesem Thread eigentlich geht, es passieren könnte das als einzig sinnvolle Lösung die Manipulation der terrain.cfg übrig bleibt. Ich werde mal nachschauen wie die Zuweisungsnummer tendentiell bei den Airportpolys ausfallen. Wenn MS das entsrechend der geografischen Lage gemacht hat, könnte man so eine Vorserien terrain.cfg machen mir der man wieder vernünftige Rasenpolys bekommt. Eines sollte man dazu wissen. Mit dieser Datei kann man tolle Sachen machen. Es ist und bleibt aber eine allgemeine Steuerdatei von der man eigentlich die Finger lassen sollte, es sei denn man macht das nur privat für sich selbst. Warum? Ein Beispiel. Jetzt komme ich an und biete euch eine terrain.cfg die so manipuliert ist das man das Problem dieses Threads behebt und zeitgleich ev. die Rasenpolys der Airports wieder mit festen Oberflächen wie im FS2002 mit grünen Rasen (mit allen Jahreszeiten usw.) erzeugt. Das sieht in der Regel besser aus als der jetzige Chamäleoneffekt und passt zusätzlich besser zu den GAPs die eigene Teilrasenpolys mitbringen. Da hätten wir jetzt eine neue terrain.cfg Variante die auf der Default terrain.cfg basiert. Jetzt komme ich in zwei Monaten an und gebe euch eine neue terrian.cfg mit der sich die Wälder automatisiert gegenüber dem Mesh abheben oder aber z.B das an Bahnlinien Masten für die Oberleitung stehen. (Alles möglich) Nur auf was für eine terrain.cfg baue ich auf. Klar in meiner Version sind alle Änderungen drin. Jetzt kommt aber der Lexif und möchte für alle eine terrain.cfg anbieten in denen Autobahnen höher als das übrige Mesh sind. Weis er das es von mir eine terrian.cfg Variante gibt. Nein, weil er dieses im Forum nicht mitbekommen hat weil er z.B im Urlaub war. Jetzt nutzt jemand seine terrain.cfg Version die meine überschreibt und alles was ich gemacht habe war für die Katz weil es in Lexif seiner Version nicht enthalten war. Im Prinzip müßte jetzt jeder anfangen und sich aus beiden Varainten selbst eine eigene zu basteln. Deshalb tendiere ich dazu Finger weg von der Datei. Wenn es nicht anders geht bitte gut dokumentieren auch das der User sich eine Erinnerung als Textdatei auf dem Desktop ablegt. Schnell hat man so was vergessen. |
|
|
|
|
|
#83 |
|
Inventar
![]() Registriert seit: 02.01.2002
Alter: 61
Beiträge: 4.238
|
Zu Horst war das jetzt wieder ein Ansporn. Das was unten steht oder eine echte Frage.
"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?" Man muß nämlich hierbei unterscheiden. Das Flussbet ist ja nichts mehr als ein kleines Gymmick. Da wird auch keiner eine Routine schreiben die sich Informationen aus dem Mesh holt viel zu aufwendig wäre das. Letzendlich haben wir es ja bei Rainer sehen, das die Flüsse ja auch viel breiter sind. Das gibt der VTP2 Liniencode eh nicht her. Deshalb löscht Rainer diese durch Excludecode (das Mesh bleibt wie oben erwähnt im FS2004 leider abgesunken). Dann werden sie komplett in anderer Technik LWM neu gemacht. Was anderes macht auch keinen Sinn. Schön wäre ein Tool welches sich anhand Kartenmaterial in digitaler Form sich die Informationen selbst besorgt und sie in entsprechenden SDK kompatiblen Code umsetzt. Im Prinzip das was in vereinfachter Form dieses Tool von Falko Dienstbach aus den E00 Daten macht. Nur die E00 Daten sind halt nicht optimal. Außerdem muss eh Hand angelegt werden. Das sind eigentlich alles Träume. MS wird aber solche ähnlichen Tools haben. Nur sie geben sie uns leider nicht. Sie geben uns ja auch keine Information über solche Dateien wie die lclockup.bgl. Würden sie das hätten wir diesen Bug vermutlich schnell ausgemerzt. |
|
|
|
|
|
#84 |
|
Elite
![]() Registriert seit: 15.11.2002
Beiträge: 1.466
|
Ja, dies war schon eine Frage in welche Richtung man denken kann.
Ich gehe ja nur davon aus, dass ich default Flussdaten und Meshdaten habe. Also müsste man diese Flussdaten so verschieben, dass sie zu den Meshdaten passen. Man generiert damit neue Flussdaten. Wenn mein Rechner dafür 2 Tage benötigen würde (wäre mir ja egal) um dies zu optimieren, anzupassen, zu vergleichen usw . Hauptsache die neue errechneten Flussdaten stimmen halbwegs zu den Meshdaten. Wie weiter oben geschrieben, nur angedachte Phantasie, über die man nicht unbedingt weiter nachdenken muss. Horst |
|
|
|
|
|
#85 |
|
Elite
![]() Registriert seit: 30.01.2003
Alter: 60
Beiträge: 1.362
|
Hallo Horst,
damit Deine Idee funktioniert muß Microsoft über ein gesamtes Gebiet immer gleich "falsch" liegen mit den Flüssen als "VTP-Linien". Nur so ein "Move" wäre überhaupt technisch machbar. Die Handarbeit ist ansonsten enorm. Frage mal meine rechte Hand bzw. Schulter... Bin mir nicht sicher, ob dies überhaupt so ist, zumal manchmal auch kleine Abweichungen schon zu "Berg- und Tal-Flüssen" führen, wie ich ja beim Main und bei der Donau selbst noch gesehen habe. Allerdings kommt dann auch noch hinzu, dass Microsoft "Vereinfachungen" von Flußläufen oder Seegebieten durchgeführt hat, die dann doch wieder stören. Interessant wäre dies aber auf jeden Fall nicht nur bei Flüssen, sondern auch bei Autobahnen. Mit den Flüssen sind wir durch die Germany1-Szenerie und meine Wenigkeit ganz gut versorgt. Wenn jetzt noch jemand hergehen würde und die Straßen und Eisenbahnen anpasst.... Ich verspreche dann auch, mich um die richtige Lage der Brücken zu kümmern. Ciao, Rainer. |
|
|
|
|
|
#86 |
|
Elite
![]() Registriert seit: 15.11.2002
Beiträge: 1.466
|
--- damit deine Idee funktioniert muß Microsoft über ein gesamtes Gebiet immer gleich "falsch" liegen mit den Flüssen als "VTP-Linien".
Das verstehe ich nicht ganz. Horst |
|
|
|
|
|
#87 | ||
|
Elite
![]() Registriert seit: 30.01.2003
Alter: 60
Beiträge: 1.362
|
Hallo Horst,
sorry. Dann versuche ich es noch einmal. Zitat:
Zitat:
--- schnipp --- damit Deine Idee funktioniert muß Microsoft über ein gesamtes Gebiet immer gleich "falsch" liegen mit den Flüssen als "VTP-Linien". Nur so ein "Move" wäre überhaupt technisch machbar. --- schnapp --- Wie willst Du sonst Deine Flussdaten verschieben. Einzeln? In eine x-beliebige Richtung, wie es Dir gerade gefällt? Ok, und wie regelst Du dann bisherige Einmündungen von Flüssen in andere? Nur lang genug ziehen bis es passt geht ja nicht. ![]() Ciao, Rainer. |
||
|
|
|
|
|
#88 |
|
Elite
![]() Registriert seit: 15.11.2002
Beiträge: 1.466
|
Die würde ich so verschieben, dass sie sich an den tiefsten Punkt der Meshdaten orientieren.
D.h im Gebirge fließt der Fluss nicht den Hang entlang, sondern an der Talsohle, wo er auch hingehört und wo der tiefste Punkt der Meshdaten ist. Die Meshdaten bzw Höhendaten sind die Orientierung für die Verschiebung. Bei Autobahnen und Eisenbahnlinien fehlt vor allem halt das Datenmaterial, bzw die Orientierung, denn dazu kann man ja die Meshdaten nicht hernehmen. Die Straßen und die Bahn hat ja der Mensch gebaut. Ich sehe halt nur die Vielzahl der bgl Dateien als ein kleines Problem. Wenn man dies für ganz Europa macht wird ein schwächeres System sicher Probleme bekommen. Für Teilbereiche aber sicher absolut in Ordnung und sehr schön. Mache ich für mich bei manchen Stellen auch. Gedanken eines Laien. Horst |
|
|
|
|
|
#89 |
|
Elite
![]() |
Hallo, Leute!
@Horst: Ich denke, dass es sehr kompliziert wäre, ein Tool zu schreiben, dass das Mesh dann analysiert, und Flüsse dann so modifiziert, dass sie im nächsten Tal im Mesh liegen. Es könnte auch Probleme geben, wenn: -du ins Flachland gehst => keine Täler -der Fehler der MS-Dateien so groß ist, dass der Fluß in ein falsches Tal "rutscht" (Wenn er z.B. genau auf einem Hügelkamm liegt). Es wäre schön, wenn man im FS das ganze Mesh einlesen könnte, und dann nur "Quellen" zu definieren müßte, und die Flüsse sich dann wie im echten Leben "in ihr Bett legen". Wird aber eben leider doch immer ein Traum bleiben... @JOBIA: Hm, ich denke, deine Idee ist total genial: Straßen duplizieren und eine Datei abändern. Dann sorgt eine für Flatten, die andere für die leichte Erhebung. Ich hab nur genau zwei Fragen: -In welchen bgls liegen die Straßen? -Welcher Parameter muß in der bgl verändert werden um die Verknüpfung mit einem Eintrag in der terrain.cfg zu wechseln? Bzw.: Welcher Wert in der bgl verknüpft die Straße mit einem Eintrag in der terrain.cfg? Und welcher Parameter ist das? [Texture.XXXX]? Das ist meiner Meinung nach der einzige Parameter, der bei jedem Eintrag anders ist. Und: wie verändere ich den? Ground 2K oder Hex Editor z.B.? Danke schonmal! Gruß, Felix
____________________________________
Felix Proud contributor to the Ultimate GA project. AI Repaints und Flugpläne von mir in einigen Releases von Ultimate GA und bei avsim. |
|
|
|
|
|
#90 |
|
Inventar
![]() Registriert seit: 20.11.2001
Beiträge: 2.379
|
Joachim (Jobia) , Du bist genial !
Nachdem ich die Terrain.cfg gegen deine Nr. 1 ausgetauscht habe ist alles wieder in Ordnung .Auf der reproduzierbaren Strecke Nizza-Genf hatte ich bisher am gleichen Punkt jedesmal einen plötzlichen Absturz ohne Fehlermeldung.Ich bin die Strecke nach dem Austausch 10 x abgeflogen , verschiedene Lfz-Muster - mit und ohne FS-Navigator - alles wieder bestens . Nur , woran lag das Problem ?Erstaunlicherweise auch keine Abstürze nach Verstellung der Jahreszeit auf " Sommer" (Default Terrain). Ich habe allerdings den Eindruck,daß die Wintertexturen mit deiner cfg. Nr. 1 abgeschwächt wurden (kaum Schnee in der Schweiz) Täusche ich mich ? Grüße Rainer ![]()
____________________________________
Einen schönen Tag noch Rainer Duo cum faciunt idem, non est idem (Wenn zwei das Gleiche tun , ist es noch lange nicht dasselbe) |
|
|
|
![]() |
| Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1) | |
|
|