mehrere Sceneryen in einen Ordner ?

[JOBIA]

Da nicht alle Techniken identische Formate haben kann es leider intern sehr wohl Probleme geben. Nicht alle Designelemente haben dann hinterher die selben Fehler. Da habe ich durchaus negative Effekte erlebt.

Man hat übrigends unte Umständen schon beim Designen selbst Fehler. Hat man z.B Runwaycode dessen Höhe im SCC als dezimalwert mit Nachkommstelle angegeben werden kann so bekommt man schon Fehler bei der Umsetzung in die Fractionalwerte des BGL Codes.


Bei Landclass ist es in der Tat so es spielt die Fläche eine Rolle bzw. auch der Name deshalb halte ich es für kritisch alle LC Files in einen Ordner zu packen. Gerade wenn Addons kleine LCs Files um den Airport haben.

[Horst LOWW]

Hallo Dietmar,
Nicht nur für LC ist die Namensbezeichnung im selben Ordner wichtig, auch für Mesh.
Quelle: Steve Greenwood http://www.fs-traveler.com/priority.shtml
Horst

[r_schon]

Hallo Dietmar,

Schönen Dank für Deine Meinungsäußerung zu
SCASM und XML - Code.

Wie gesagt, ich sehe das Ähnlich wie Du. Vielleicht hast Du - wie angedeutet- Lust, noch detaillierter auf die Fragestellung einzugehen. Auf jeden Fall geht Rad fahren ( hab gelesen, daß man mit dieser Schreibweise nichts falsch machen kann ) immer vor.

Übrigends, ich fahre auch für mein Leben gern auf dem Radl, wenns sein darf auch etwas weiter und ein wenig zügig.

Gruß
Rolf

[Oliver H.]

Hallo Experten,

ich getraue mich fast nicht mehr hier zu schreiben.

Ich habe meine Kopenhagen-Freeware-Scenery von
FSNORDIC nun mal genommen und alles zusammenge-
worfen, zusätzlich die Brücken vom FS8 dazu.
Die Landclass bleiben natürlich für sich.

Vorher als alles (Stadt/Flugplatz/Inseln/Brücken)
getrennte Ordner hatte ruckelte es beim Anflug.
Nun wo alles zusammen in einem Scenery/Texture
Ordner ist, ruckelt es nicht mehr. Frames bleiben
in etwa gleich.

Könnt Ihr einem dummen Flusianer das mit einfachen
Worten erklären wiso das so ist? (Oder ist das nur
in diesem Fall zufällig so)

Verneige mich in Erfurcht,
Gruß Oliver

[r_schon]

Hallo Oliver,

Bumm, das hat gesessen.

Du hast natürlich eine Frage angeschnitten, die geradezu dazu herausfordert, sich der Problematik mal intensiv zu widmen. Und in diesem Ordner treiben sich in der Tat einige Experten herum. Also, nimms bitte nicht übel, wenn mal off topic diskutiert wird.

Ich kann Dir jetzt nicht erklären, warum Deine Szenerie schneller läuft - aber freu Dich drüber. Welche Probleme auftreten können ( nicht aber müssen), das hast Du wohl verinnerlicht. Wenn Du dieses Risiko nicht scheust und durch das Zusammenlegen auch noch eine bessere Performance erhältst, dann ist das sicher o.k. Kann aber sein, daß es
irgendwann mal kracht und Du Dir den Sim dann neu aufbauen mußt.

Gruß
Rolf

P.S.: Ich betrachte mich nicht als Experten, Ehrfurcht ist also nicht erforderlich.

[JOBIA]

Und wie man bei Horst seinem Link sehen kann der LOD Level des Mesh. Das Thema hatten wir auch schon mal vor längerer Zeit im FXP Forum zu Zeiten des Faitman Mesh. Wer da das Lago Mesh hatte musste leider damit kämpfen das dieses oversampled war. Es hatten eine höheren LOD Level als Faitman oder das ATP Mesh. Es drängelte sich vor obwohl es selbst aus minderwertigeren Rohdaten bestand. Da hat man dann leider kaum einfache Möglichkeiten dieses durch Prioritätsvergabe in der Scenerybibliothek zu umgehen. Zumindest sind mir keine einfachen Wege bekannt.

Zum Thema Performance.

Rolf weis was ich da meine. Ich hatte neulich etwas umgesetzt da konnte man das ganz eindrucksvoll sehen. Ich will da nicht weiter drauf eingehen. Man konnte hier aber sehr eindrucksvoll sehen wie man sehr viel Speicher einsparen konnte auch das Sceneryladen selbst ging sehr schnell. Es gab auch weniger Nachladeeffekte also Ruckler.

Die Grundperformance legte allerdings nicht so zu wie ich es erwartet hatte. Besser war sie aber trotzdem.

Es kann also durchaus sein das Du positive Effekte hast. Allerdings in diesem Maße?

Manchmal lässt man sich auch täuschen dadurch das schon Daten im Speicher sind.

Fakt ist jeder Verwaltungsaufwand belastet den FS.

Nur wie Rolf schon sagt man muss fast jede BGL Datei durchleuchten um einen absolut stabilen Zustand zu haben. Man kann da schnell das reinste Chaos auslösen.

[frenzl]

Tag zusammen,

----P.S.: Ich betrachte mich nicht als Experten, Ehrfurcht ist also nicht erforderlich.----

ich bin auch kein Experte, habe mich auch nur ein klein wenig mit dem Flusi beschäftigt (seit FS2s Zeiten).

An Jobia:
ich seh es genau so, daß ein disassemblieren von bgls u.U. zu Fehlern führen kann. Es macht natürlich auch keinen Sinn gut funktionierende und aussehende Szenerien auseinander zu nehmen um sie dann anschließend wieder zusammenzusetzen. In Einzelfällen kann es sehr wohl angebracht sein, siehe mein obiges posting, man muß dann das Ergebnis natürlich genau kontrollieren. Ich hab das auch für die ganz alten German Airports Düsseldorf, M-Gladbach und Erfurt gemacht; waren die für den FS98 oder FS2000? Weis ich nun nicht mehr, müßte im Keller nach der Box kramen. Die hab ich heut noch für den FS8 und FS9 drauf. Keine Probleme bisher damit, eine einzige Ausnahme: nachts scheinen die RWY-Befeuerungen der FS9-Szenerie mit durch, bei FS8 nicht, das liegt wohl am neuen XML-Code, könnte ich beseitigen, bin aber zu faul dazu.
Habe gerade das Erstellungsdatum von EDLN nachgeschaut, ist 20.04.1999, also waren die für den FS98.

Das mit den LC-Dateien siehe ich selbst als nicht so kritisch an. Die LC- und LIB-Dateien, die ich im scenery\base\scenery Ordner untergebracht habe finden sich dann - und nur die von mir eingebrachten Dateien - in der Textdatei scenery.dat im Wurzelverzeichnis des FS wieder.
Konnte bisher bei mir nichts nachteiliges feststellen.

An Horst LOWW:
danke für den Tip, hab mir das schon angeschaut, erklärt vieles.
Ich könnte mir vorstellen, bei LC ists genauso gelagert. Gut zu wissen.

An Rolf:
FS9 verarbeitet z.Zt. SCASM und XML-Code parallel, jedenfalls den, der für den FS2000 und FS2002 mit SCASM generiert wurde. Auch funzt vieles, welches für den FS98 geschrieben wurde, aber da kanns ein paar Ausnahmen geben. Ich habe bei mir gerade noch eine Datei für den FS5 gefunden, auch die macht keinen Ärger.

An Oliver H.:
also das verblüfft mich denn doch. Wie wäre das denn nun zu erklären?
Ich versuch da mal eine fragliche Deutung, könnte aber total danebenliegen.

1. Wenn sich die Szenerien in vielen Einzelordnern befinden, muß das System diese jeweils öffnen, die Daten, bgls und Texturen auslesen um sie verarbeiten zu können. Das kostet Zeit, aber bei den heutigen Taktgeschwindigkeiten? Kleinvieh macht auch Mist.

2. Die Szenerienamen werden in der scenery.dat, die für jeden Einzelszenerieordner erstellt wird, gespeichert. Viele Ordner, viele scenery.dat.Auch da will nachgeschaut werden,müssen Ordner geöffnet, Daten gelesen, Texturen verarbeitet werden. Das wird auch Zeit kosten. Ist in einem Ordner viel an Szenerie untergebracht, ist zwar die scenery.dat lang, aber sie muß nur einmal geöffnet werden, die Angaben beziehen sich dann jedoch immer auf den gleichen Ordner.

Das war es erst mal, Gruß
Dietmar

[frenzl]

Hi,
ich will da noch kurz was zu den LC nachtragen.

Die paar CTDs die ich im letzten 3/4 Jahr hatte, 4 Stück:
Schleissheim, Straßburg, Blackpool alles FS98 bgls
Griechenland Iraklion, auch eine bgl, wurde aber nach einer Woche von den Entwicklern gepatcht.

Ich hatte nach Jobias Patch keinen CTD mehr, habe damals aber noch folgendes durchgeführt, weils mir sehr merkwürdig vorkam:

In der Scenery\World\Texturen sind Textur-BMP, die innerhalb einer Ordnungsnummer (z.B. 024xxxxx.bgl) sowohl bis zur Endziffer 5 als auch bis zur Endzimmer 7 vorkamen. Ich fands eigenartig und dachte, da hat wohl MS was vergessen.
Wo es also nur bis zur Ziffer 5 ging habe ich die Texturen mit der Endung 4 und 5 kopiert, sie anschließend in die Endungen 6 und 7 umbenannt und in das Worl\Texture Verzeichnis hineinkopiert.
Seitdem, (Zufall vielleicht?), hatte ich da, wo ich geflogen bin keien CTD mehr. Die Bildchen sind jetzt zwar doppelt vorhanden, nachteiliges konnte ich nicht feststellen.

Gruß
Dietmar

[JOBIA]

Zufall:

Siehe meinen Beitrag von gestern.


http://www.wcm.at/forum/showthread.p...5&pagenumber=1

Der Einfachheit halber der wichtige Auszug.

"Ein anderes kurioses Beispiel.

Derjenige der sich mit Landclasstexturen auskennt der weis das großflächige LC Landschaften aus einem Texturset zusammengebaut werden können.

Da gibt es Textursets pro Jahreszeit mit 1 Textur oder mit 5 Texturen oder eben mit 7 Texturen. Manchmal verzichtet Microsoft oft auf bestimmte bzw. fast alle der 5 Jahreszeiten hw,wi,sp,su,fa dann wird z.B Sommer für Herbst oder z.B Frühling mitgenutzt. Das ist normal.

Was aber nicht normal ist ich streue es hier mal in den Raum ist das der Texturset 040b2suX.bmp für fast alle Jahreszeiten ein offizieller Texturset mit 7 Texturen ist.

Kurios ist nämlich das er für Winter wi auf einmal nur aus 5 Texturen besteht."

Ich habe noch mal ins neue SDK geschaut offiziell ist der 40er Satz ein 5er Von der Theorie her dürfte nichts crashen. Mit anderen Worten Microsoft hat geschlafen und sich aus versehen zuviel Arbeit gemacht. Nur dieses Phänomen taucht sehr oft im FS auf. So oft können die eigentlich nicht geschlafen haben.

Meine CTD Theorie war damals übrigends das der FS crasht weil Texturzuweisungen nicht existieren. Er läuft qausi ins leere.

Ich muß mal nachschauen ob er die Texturen die irgendwo zuviel sind also Texturnummer mit 6 oder 7 überhaupt lädt.



kurioser ist aber auch das diverse Steuermasken der Terrainengine fehlen.

Irgendwie sieht es verdammt danach aus als wenn der FS2004 mit der heissen Nadel gestrickt wurde.

[frenzl]

Hi,
interessant der Beitrag.
Irgendwas läuft da nicht beim FS9 zusammen. Habe das auch z.B. für die 40er nachgelesen. Merkwürdig ist da doch, daß die Maskentexturen? xxxxxm1x.bgl (32x2048 Pixel) dort 7x vorkommen und dann jeweils mal 7 oder 5 (Saison- oder Kontinent-) Texturen vorhanden sind. Hab mir mal das Texturverzeichnis von der Original-CD heruntergeladen und auf die Schnelle festgestellt, das ich Änderungen bei 024, 036, 040 und 048 vorgenommen habe, ist möglicherweise nicht vollständig.

Dietmar