mehrere Sceneryen in einen Ordner ?
 

Hallo Simmer,

ich sitze gerade wieder am Flusi-PC und da ist
mir folgender Gedanke gekommen:

Kann man aus verschiedenen Sceneryen die .bgl
Dateien sowie die zugehörigen Texturen in einen
Scenery- bzw. Texture-Ordner zusammen nehmen?

z.B. Balearen. Die bgl`s und Texturen von Ibiza,
Mallorca und Menorca in einen Scenery und einen
Texturenordner.Die bgl`s und Texturen haben alle
unterschiedliche Namen/Bezeichnungen so das sie
sich eigentlich wieder finden sollten.

Ich könnte es ausprobieren, ich habe aber zu
große Angst meinen stabil laufenden Flusi zu
zerschießen.


Danke schon mal für die Antworten, Gruß Oliver

Hallo Oliver,

Geht grundsätzlich schon - aber was versprichst Du Dir davon?

Probleme könnte es mit Texturen geben - schnell hat der Designer mal in diversen Szenerien eine unterschiedliche Textur mit dem selben Namen versehen und dann könnte einiges anders aussehen, als bei getrennter Szenerie.

Ferner verbaust Du Dir die Möglichkeit, einer Szenerie einen höheren Layer zu geben, womit man ja bestimmte Konflikte in den Griff bekommen kann.

Ich rate daher davon ab, weil es sowieso keine Vorteile sondern im schlimmsten Fall nur Probleme gibt.

Gruß
Rolf

Hallo Rolf !

Der Grund dieser Frage liegt darin das ich sehr
viele VFR-Sceneryen habe. Davon sind nun einige
räumlich beisammen. Diese wollte ich nun je nach
Region bündeln. Hintergrund dazu war, das ich mal
gelesen habe der FS2002 oder auch FS2004 soll
maximal so um die 400 Sceneryen verarbeiten
können. Da bin ich nun sehr bald angekommen.
Durch das zusammenfassen könnte man den FS viel-
leicht austricksen?
Das die Dateien durchgehend unterschiedlich be-
zeichnet sein müssen war mir klar. Aber da ich
mich im Design/Programmieren nicht auskenne,
wusste ich nicht, ob die Dateien sich gegenseitig
nach bestimmten vorgegebenen Pfaden in den
Ordnern suchen.
Konflikte kenne ich im Moment nur mit Olbia im
zusammenhang mit Madrid-Baradjas und dem daraus
resultierenden Meshfehler im Bereich von Madrid.

Naja, das war ja nur so ein Gedanke. Mal immer
weiter Sceneryen installieren, der FS wird sich
schon melden wenn er nicht mehr will. :)


Gruß Oliver

Hallo Oliver,

So würde ich das auch sehen - abwarten und Tee trinken. Reagieren kannst Du immer noch.

Schöne Grüße nach Erbach.

Rolf

Hallo,
also ich mach das schon seit den FS98er Zeiten so, daß ich die Szenerien in einen Ordner, getrennt nach Länder, hineinpacke.
Rolf hat zwar recht, daß es mal ein Problem mit unterschiedlichen Texturen geben kann, aber hauptsächlich war das bei den hangar.bmp's so. Wenn ein Hexeditor genommen wird, kann man in einer bgl-Datei (eventuell dekomprimieren) die Bezeichnung in hangaa, hangab usw ändern.
Anschl. benennt man die bmp-Datei einfach um. Das funzt.
Bei Texturen wie grass.bmp, concrete.bmp usw spielt es eigentlich keine große Rolle, welche man sich da zum Gebrauch aussucht.

Bei sehr vielen Dateien in einem Szenerieordner, bei mir mehr als 800, teile ich nach den Himmelsrichtungen auf, also Deutschland_Nord Deutschland_Süd und folgende. So komme ich momentan auf 179 Szenerieordner. Die Anzahl der bgl und der Texturen in den jeweiligen Ordnern ist dem FS Wurst, da er sich die Szenerien allein nach den Koordinaten im Header aussucht.

Der FS9, sowie der FS8 können max. 332 Ordner verwalten. Ich habe also noch genug Platz.
Gruß
Dietmar

Hallo Dietmar,

Und warum breche ich mir dann einen ab, damit das möglichst naturgetreu aussieht und ich verschiedene Varianten ( wie in der Realität ) in meiner Szenerie habe ?

Spaß beiseite, die benenne ich natürlich nicht mit dem Namen einer Textur aus dem Standardtexturverzeichnis - was mich interessiert, hast Du keine Prioritätskonflikte mit Szenerien, die sich überschneiden?

Gruß
Rolf

Stimmt was Rolf hier sagt so ein Zusammenpacken ist viel zu gefährlich.

Es kann zwar zunächst vermeintlich störungsfrei laufen, nichts desto trotz sieht man ev. nicht das was man eigentlich sehen sollte.

Denn dem FS nützen hier die Header gar nichts. Addons sind nämlich dafür ausgelegt das ev. andere Addons in dessen Nähe deaktiviert werden müssen.

Wenn man nur an Austrian Airports LOWI und GAP Lowi denke wie schnell käme es dort zu Kollisionen. Oder bei Runwaytexturen für Standardrunwaycode. Da verwenden viele eigene Texturen die aber den original Namen tragen müssen.

Bei zwei Addons die so vorgehen geht das in die Hose.


Klar Du hast recht theoretisch geht das wenn man nur die zusammen packt wo man Kollisionen ausschliessen kann.

Nur ehrlich gesagt um da sicher zu sein muss man quasi jede BGL vom Dateninhalt kennen. Das wäre mir zuviel Arbeit.

Hi,
naja, ich rufe auch nicht dazu auf, es so wie ich zu machen. Wer sich da überhaupt nicht auskennt sollte auch gefälligst die Finger davon lassen.
Also, Prioritätskonflikte habe ich bisher auch nicht festgestellt, muß aber gleich dazusagen, daß ich die Austrian Airports nicht drauf habe. In dem Falle würde ich sicherlich einen neuen Ordner anlegen und eine Prioritätsselektierung vornehmen. Das bezieht sich grundsätzlich auf Szenerien, die einen großen Flächenbereich abdecken, wie die Freeware-Griechenlandszenerie. Bei einzelnen Airports sehe ich da überhaupt keine großen Probleme.

Bei Szenerien, die mit einem Installer daherkommen bin ich äußerst vorsichtig, die werden von mir zuerst auf einen FS9-Dummy umgeleitet.
Dann schau ich nach, was die eigentlich gemacht haben, scenery.cfg etwa verändert? Da ich da keinen Anderen heranlassen möchte habe ich mir ein Programm geschrieben mit dem ich u. a. meine scenery.cfg verwalte, das nach vorhandenen Texturen in beliebig vielen bgls suchen kann, das mir sagt, welche Texturen nicht vorhanden sind, und vieles mehr.
Wer das Programm (geschrieben für den FS2002, läuft aber auch mit dem FS2004) auf eigenes Risiko ausprobieren möchte, kann mir das mitteilen, veröffentlicht habe ich es nicht.

Ebenso habe ich die fs9.cfg gesichert, falls dort drin herumgefuschelt wurde. Die kopiere ich dann wieder zurück.

Die Szeneriedateien befinden sich seit 2001, natürlich mit Erweiterungen auf meinem Rechner. mit dem FS2002 hatte ich überhaupt keinen Absturz, mit dem FS9, dank Jobias Patch, nur noch drei.
Dabei handelte es sich um die alten (FS2000 oder FS98?) Szenerien Schleissheim, Enzheim und Blackpool, da verabschiedete sich der Flusi kommentarlos (die müssen da irgendwie einen ret-Befehl drinnen haben, hihi).

Was ich da so im Forum alles lese (nichts geht mehr, ständige Neuinstallationen, Neuaufsetzen des Betriebssystem, Grafiktreiberprobleme usw.) habe ich bei mir noch nie gehabt.

Gruß
Dietmar

Klar dazu sollte man auch nicht aufrufen.

Aber wie gesagt ich würde es niemanden empfehlen. Kopierst Du mehrere Dateien in einen Ordner reichen allein schon die Namen der Dateien aus um heftiges Chaos in einer Scenery auszulösen.

Hast Du Lust auf einen Versuch so kann ich morgen oder übermorgen mal ein Zip File einer Demoscenery zur Demonstration anhängen.

Kannst dann ja mal überlegen wie Du so etwas abfangen willst.

Hi Jobia,
ich kann mir es ja mal ansehen.
Gruß
Dietmar

Hallo Miteinander,

bevor jetzt mein Landsmann aus Erbach ins Schleudern kommt - Oliver, laß besser die Finger davon, irgendetwas zusammenzukopieren.

Der Dietmar, der kann das sicher machen, denn er kennt sich aus - Otto Normaluser sollte die Finger von Manipulationen lassen - die Fehlerquellen sind ohnehin zahlreich im FS9.

Gruß
Rolf

Wird heute aber nichts mehr. Am Wochenende sind wir weg. Ev. Montag oder Dienstag morgen. Dann hänge ich ein ZIP File an. Soll auch nur zur Demonstration dienen wie gefährlich so etwas werden kann. Und das man halt den kompletten Inhalt der BGL Dateien kennen muss. Und das man im Extremfall sogar BGL Dateien vom Namen her ändern muß um kein Chaos zu veranstalten.

Mir zu aufwendig auf all so was zu achten. Zumal da ja anstatt ev. 20 bis 30 BGLs einer Scenery nachher ev. hunderte zusammenkommen.

Wenn ich da mal an SG1 denke. Ich meine mich recht zu erinnern das es da schon allein 54 Meshfiles waren die aber vom Namen her nicht als solches erkennbar waren. Sie waren in der Scenery mit den Airport BGLs zusammengewürfelt.

Ein schönes Wochenende wünsche ich.
Dietmar

Hallo Dietmar,
Ich bin bei meiner Ordnung im FS9 bei Layer= 563 angelangt.
Hast du bei dir schon überprüft, wie viel Speicherbedarf diese doppelten Texturen benötigen?
Oft haben sie den selben Namen sind aber eine andere Textur, bzw wurden ergänzt.
Textur ist nicht gleich Textur auch wenn sie den selben Namen hat.

Horst

Noch ein Punkt: Momentan stellen einige Designer auf neue Technik um. Es gibt kaum richtige Updates, sondern fast nur komplett neue Versionen, wo es heißt: Bitte alle vorherigen Versionen löschen. Hat man jetzt verschiedene Szenerien zusammengepackt und möchte die neue Version einer Szenerie installieren - muß man händisch die alte Szenerie mühsam aus dem Pool löschen. Und wehe, man vergisst nur eine klitzekleine *.bgl (oder findet sie nicht). Auch dies kann zu bösen Überraschungen führen.

Gruß
Thomas

Tach auch,
also nochmal zur Klarstellung. Ich plädiere nicht für das grundsätzliche und allgemeine Zusammenlegen von Szeneriedateien. Ich wollte nur darauf hinweisen, daß es prinzipiell möglich ist, wenn man einige Punkte strikt beachtet und wenn man auch die nötigen Werkzeuge (Tools) besitzt. Ich bin mir absolut klar darüber, daß das für unerfahrene User in die Hose gehen muß. Ebenso selbverständlich ist es, daß nicht alles in einen einzigen Einzelordner gepackt werden kann.
Ich habe mir das nach Ländern geordnet, nach Ländermeshs und nach Länderlandclasses.
In diesen Länderordnern, man höre und staune, befinden sich FS98-, FS2000-, FS2002- und FS2004-Szenerien. Und da gabs natürlich schon das erste Problem, viele dieser Dateien hatten Einträge für Exclude und Flatten in der scenery.cfg und mehr als 1 Exclude und 10 Flatten sind nicht erlaubt. Also ein VB-Programm geschrieben, welches aus dem Exclude- und Flattentext in der cfg, mittels von SCASM, eine oder mehrere bgl-Dateien generieren kann, die wurden dann mit in diesen Ordner hineinkopiert, das klappte, bis auf eine einzige Ausnahme, auch hervorragend.

Probleme gabs auch mit Texturen gleichlautenden Namens. In den englischsprachigen Foren wurde schon seit Jahren dafür geworben seinen selbserstellten Texturnamen doch seine Namenskürzel voranzustellen, wenn dann immer wieder Texturnamen wie Haus, Tower, Hangar, Concrete usw auftauchen und sich jedesmal ein anderes Bildchen dahinter verbirgt, geht ein Zusammenlegen der Szenerien zuerst mal nicht. Das gleiche Problem haben wir natürlich auch bei Szenerienamensgebungen wie terrain.bgl, sign.bgl usw.
Da hilft dann auch nur umbenennen, bei bgls ist das problemlos (es sei denn, es würde sich um eine Lib-Datei handeln), bei Texturnamen gehts mit einem Hexeditor in der jeweiligen bgl, -noch-.

Auch hier gilt, wer sich da nicht auskennt steht auf verlorenem Posten.

Richtig ist auch, daß bei neuen Szenerieupdates die alten entfernt werden müssen (das ist grundsätzlich immer so), ich denke jedoch, das ist unabhängig davon ob die Szenerie mit altem Code oder mit neuem XML-Code erstellt wurde.

Da ich alle Szenerien auch als ZIP-Dateien gespeichert habe ist es für mich kein Problem, die entsprechen Dateien (bgls und Texturen)
auch wieder zu entfernen. Das mache ich selbverständlich nicht händisch, sondern lasse auch wieder ein VB-Progrämmchen für mich arbeiten.
Dabei könnte es natürlich vorkommen, daß eine oder mehrere Texturen zuviel gelöscht wurden, aber auch das erledigt das Programm dadurch, daß ich anschließend die noch vorhanden bgls im entsprechenden Ordner auf fehlende Texturen durchscanne, fehlt da was, kann ich wieder zurückkopieren.
Dabei ist mir aufgefallen, daß viele Szenerien (Free- wie Payware)
fehlende oder auch einfach falschbenannte Texturnamen aufweisen, man denke da an eine EDLV-Niederrhein-Szenerie einer britischen Firma zurück.

Etwas nachdenklich macht mich das posting von Horst, der 563 Ordner in seiner cfg hat. Wenn das funzt, wäre ein Zusammenlegen von Szenerien auch für mich obsolet. Bei FS2000 und FS2002 konnte man auch mehr als 332 Ordner drin haben, aber nur die ersten 332, von rückwärts in der FS-Anzeige wurden verarbeitet, selber getestet.
Wenn das bei FS2004 anders ist, wäre ich doch sehr überrascht, denn ich habe in div. Foren gelesen, daß die Obergrenze nach wie vor besteht.

Aber möglicherweise könnte da jemand, der damit eine Erfahrung gemacht hat, was dazu sagen.


Also nochmals ganz kurz, wer sich nicht auskennt: Finger weg!
Mein posting sollte auch nur aufzeigen, daß es grundsätzlich möglich ist, nicht mehr, nicht weniger.


Gruß
Dietmar

Hallo Dietmar,

Schon verstanden. Ein Aspekt würde mich mal aus Deiner Sicht etwas ausführlicher interessieren.

Ich " tendiere" auch zu Deiner Ansicht, daß es letztlich alter SCASM Code und moderner XML Code keine gegenseitige Konflikte hervorruft.

Thomas ( Röhl) hat, wenn ich das richtig verstehe, da seine Bedenken - auch schon an anderer Stelle geäußert.Andere tun dies auch.

Da wir hier ja im Designer Forum sind, meine ich, man könnte diese Frage auch in diesem Ordner aufgreifen und diskutieren.

Gibt es konkrete Anhalte/ Belege, daß sich hier nichts stört oder bibt es Beweise für das Gegenteil?

Gruß
Rolf

Hallo Rolf,
will mich heute nur mal kurz dazu äußern, vielleicht nächste Woche mehr.

Also ich denke, daß zur Zeit die bgl-Graphic-Engine für den FS9 sowohl alten SCASM- als auch neuen XML- Code verarbeiten kann. Da ich das, wie bereits beschrieben, alles 'zusammengemixt' habe, wobei ich gar nicht ausschließen möchte, daß da auch noch ganz alte FS5-bgls mit dabei sind, bin ich der Meinung, daß da -bis auf ganz wenige Ausnahmen- keine Probleme momentan auftreten. Ob das bei dem zukünftigen FS10 und den Nachfolgern auch so bleiben wird, wage ich mal zu bezweifeln. Man kennt doch MS, diese innovative Firma, die Anderen auch gerne etwas, in immer kürzeren Abständen natürlich, zukommen lassen möchte.
(Am besten alles wieder neukaufen, hi, beim Umstieg von FS4 auf FS5 konnte man dann auch alles in die Tonne werfen.)

Bei den paar bgls, wo es bei mir nicht funzte, gehe ich davon aus, daß da ein Szenerie-Designprogramm verwendet wurde, daß noch uralten SCA-Code generierte, den man eigentlich nicht mehr verwenden sollte, nachzulesen in der SCASM-Doku von Manfred Moldenhauer.

Zu dem neuen XML-Code will ich vorerst nur so viel sagen, daß die bis jetzt dafür (als freeware) erhältlichen Szeneriedisassembler bzw -analyzer zwar einen XML-Code generieren, wenn man aber versucht diesen sofort wieder mittels BGLC für den FS9 in eine bgl zu kompilieren dieser aussteigt und abbricht. Da ist also noch einiges im Unklaren, naja schreiben die ja auch in ihren Dokumentationen.

Schönen Sonntag
Dietmar

Das Du Dich auskennst merke ich auch z.B daran.
"kann man in einer bgl-Datei (eventuell dekomprimieren) die Bezeichnung in hangaa, hangab usw ändern.


Das mit dem komprimieren haben einige Teams nämlich auch noch länger eingesetzt. Ich vermute aber weniger um hier Platz zu sparen sondern eher um eine Datei hier unleserlich zu machen. Denn ab dem FS2002 hat das fast kein Designteam mehr genutzt die Kompression des FS2000 Tools. Einige wenige haben dieses aber konsequent weiter genutzt.

Einige Analyzetools sind am Anfang über so etwas gestolpert hatte wohl keiner mit gerechnet das dieses noch zum Einsatz kam.

Du hast das Thema Analyse von BGL Code angesprochen auch das hier Fehler bei XML Dateien passieren. Das trifft genau so auf andere Dekompiler zu. Hier gibt es beim dekompileren sehr viele Rundungsfehler. Auch bei SCASM basierenden Code konnte ich das sehr oft feststellen. Da passt beim rekokmpilieren doch es öfteren hinterher nichts mehr 100%. Da kann es sehr schnell zu Fehlern in der Scenery kommen. Verschobene Taxiwaylinien usw.

Man sollte sich also auch im BGL Code selbst auskennen. Zumindest derjenige der solche Tools einfach so benutzt ohne sich weitere Gedanken zu machen.


Zu
"Ich habe mir das nach Ländern geordnet, nach Ländermeshs und nach Länderlandclasses".

Interessefragen

Soll das heissen Du hast z.B alle LCs von deutschen Scenerien in einen Ordner für deutsche Landclass zusammengepackt?


Wenn Du das machst, nimmst Du dann noch irgendwelche Korrekturen an den LC Files vor?

Ev. erübrigt sich ja dann ein Demofile.

Hi,

---Das trifft genau so auf andere Dekompiler zu. Hier gibt es beim dekompileren sehr viele Rundungsfehler. Auch bei SCASM basierenden Code konnte ich das sehr oft feststellen.---

Zu SCASM-Code:
ich bezieh mich jetzt mal auf den bglanalyze von Takuja Murakami und will da mal kurz meine Erfahrung schildern.
Es kann ja sein, daß da (kleine?) Rundungsfehler auftreten, aber ich denke, wenn sich das auf Latitude- und Longitudewerte einer Szenerie erstreckt, es dann aber für alle extrahierten Werte zutrifft, sodaß möglicherweise eine Verschiebung vielleicht um 1m Nord oder Ost auftritt. Das könnte mich aber nicht weiter stören.
Da gab es doch diese Spengler DDR-Military-Szenerie, die ich als besonders gelungen bezeichnen möchte (konnte mich selber auf vielen, auch jetzt noch vorhanden, aber stillgelegten Plätzen davon überzeugen), die aber leider in der letzten vorliegenden Form einfach nicht mehr zu FS2002 und FS2004 passten.
Also mittels bglanalyze zuerst aus den vielen Szenerien alle roads
herausextrahiert (bglanalyze erzeugt eine SCA-Datei mit allen Objekten); alle Objekte, die keine Strassen waren, wurden gelöscht.
Anschließend habe ich alle diese Roads-SCAs zu einer einzigen DDR-SCA-Textdatei zusammengemerged und mit Falko Dienstbachs SCM2VTP.exe zu einer DDR-Road.bgl, die nun VTP-Strassen enthielt, kompiliert.
Sieht super aus und passt auch zu den vorhandenen Strassen im FS9.

Anschließend aus den SCAs die Wälder, Felder, Städte, Seen und die viel zu grün geratenen Grassflächen entfernt. Nun blieb nur noch der reine Airport (runways, Gebäude usw) bestehen. Mit SCASM nun neue bgls kompiliert, auch das war ein voller Erfolg.
Etwas Probleme sind da mit dem Mesh vorhanden, waren aber auch schon vorher da, ich benutze Nanucq Faithmains Mesh, könnte man beseitigen, fällt aber auch gar nicht so sehr auf.

Bei diesem Tun ist mir kein einziger Fehler vorgekommen, weder mit den Tools, noch bei der Szeneriedarstellung im FS2002 und FS2004 (fahre beide noch parallel).

Zu den landclasses:
ich habe mir seinerzeit für den FS2000 Burkhard Renks landclasses Deutschland, Frankreich, Benelux, Dänemark, Britanien, Italien und den Balkan gekauft. D, F, NL, B, L und DK habe ich zu einer Europa-LC mittels den tmf-Tools kompiliert. Die anderen blieben eigenständig.

Diese sind bei mir im FS9-Ordner Scenery\BASE\Scenery als LC-Grundgerüst untergebracht. Alle anderen LCs für D sind, wie schon richtig vermutet im LC_Deutschland-Ordner untergebracht,hat natürlich höhere Priorität als FS9\Scenery\BASE\Scenery.
Allerdings natürlich nicht Frank Barths D-LCs, denn bei mir ergäbe das keinen Sinn, weil schon B. Renks Dateien vorhanden.
[Würde man die als Grundgerüst benutzen, sollte man sie im oben genannten Ornder unterbringen]
Aber selbverständlich all die LCs, die nur nur einen kleineren Arealbereich, z.B. um einen Airport herum, oder eine bestimmte Stadt usw abdecken. Kann man sich mit TMFViewer angucken. Aber auch große Arealbereich können darin untergebracht werden, das Einlesen des FS9 dauert dann eben nur länger.
Eine Besonderheit dabei ist mir aber auch noch aufgefallen. Wenn sich 2 LCs im Darstellungsgebiet überschneiden und sich im gleichen Szenerieordner befinden, was wird dann dargestellt???
Ich hatte mal so ein Problem und glaube herausgefunden zu haben, daß es die letzte LC-bgl ist, die der FS9 für die gewünschten Koordinaten einliest. Das würde bedeuten, daß der FS nach Namen sortiert (axxxxx.bgl, bxxxx.bgl usw). Das hab ich gemacht, hab eine LC-bgl mit Z beginnen lassen und die Darstellung war perfekt, Zufall oder was? (Diesen Trick habe ich auch bei meinen veröffentlichten Freewareszenerien vom Niederrhein und von EDLV angewandt und keine Beanstandung der Darstellung im FS als Rückmeldung erhalten.)

Das sind übrigens die einzigen Korrekturen, die ich bisher vorgenommen habe, das Umbenennen von LC-BGL-Namen; was Darstellungspriorität haben soll, bekommt einfach im Namen V-Z vorangestellt.


Gruß und einen schönen sonnigen Tag,
ich gehe jetzt radfahren (schreibt mans nun groß, klein, getrennt oder zusammen oder sonst irgenwie anders?)

Dietmar

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.

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

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

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

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.:)

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.

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

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

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.

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

Sorry, ist natürlich xxxxm1x.bmp.
Dietmar

Zu

"Merkwürdig ist da doch, daß die Maskentexturen? xxxxxm1x.bgl (32x2048 Pixel)"


Leider nicht korrekt Deine Aussage die in dem Satz enthalten ist.

Das war ein Thema welches ich in meiner Landclassdoku auch erschlagen wollte die komplette Funktion der Terrainengine damit es bei Landclass ein realistisch wirkende Erdoberfläche gibt.
Ich habe mich aber entschlossen das Thema nur noch anzureissen.


Deine Aussage oben habe ich zunächst auch immer so gesehen. Zumal die Masken in einem Fotoprogramm wie 8Bit Graustufen aussehen. Zunächst eine harte Nuss. Ich habe damals im FS2002 immer gedacht es muß eine Art Komprimierung sein das es wie 8BiT Graustufen aussieht. (8 Bit war aus meiner Sicht unlogisch und das ist es auch) Auch das Format 32x 2048 passt irgendwie nicht zu den Landclass Texturen.

Erst die neuen Masken des FS2004 bzw. ein integriertes Byte welches dem Imagetool sagt zeig mir mal die Maske auch als Maske an hat mir die Erleuchtung gebracht.

Für meine Landclassdoku habe ich um den Beweis der Funktion der Terrainengine erbringen zu können alle Steuermasken des FS2004 umprogrammiert. Mit anderen Worten ich kenne das Format und kann auch selbst neue Steuermasken programmieren.

Damit habe ich unmittelbaren Einfluss auf die Landclassterrainengine.

Eigentlich ist dieses zwingend erforderlich wenn man Tauschtexturen alla FS Scene anbietet. Denn sobald es sich um strukturierte Texturen handelt wie Felder Orte usw. muss man auch die Steuerung diesen Strukturen anpassen. Es sei denn man toleriert optische Fehler.

Einen Ausriss wird es in der LC Doku geben. Aber nur das Prinzip der Terrain Engine.

Für mehr habe ich momentan keine Lust mehr.

Zu der Thematik

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

über die wir hier und auch in dem oben genannten Thread gesprochen haben bitte einfach in dem anderen Thread weiterlesen.

Moin Oliver,

z.B. aus diesem Grund hat Michael Garbers (hier im Forum unter dem Andragar bekannt) einen sogennanten Scenery Manager programmiert mit dem man unter anderem dieses Problem in den Griff bekommt.

Schau einfach mal hier !!!!!!