Tool zum "Aufräumen" der scenery.cfg gesucht
 

Hallo,

ich bin auf der Suche nach einem Tool, das mir ein wenig Ordnung in die scenery.cfg bringt. Ich weiß, dass ich es schon einmal eingesetzt habe, aber ich finde es bei mir auf der Platte nicht mehr. Im Verdacht hab ich derzeit entweder Flusifix oder den Flightsim Manager von Rana, in beiden hab ich die gesuchte Funktion aber (noch) nicht gefunden.

Das Tool, das ich damals eingesetzt habe, hat nichts Außergewöhnliches mit der scenery.cfg gemacht. Es hat lediglich die Layer-Nummern an die Prioritätsnummern angepasst und anschließend die Layer aufsteigend sortiert, so dass sich in der Szenerie-Bibliothek gar nichts geändert hat, lediglich die Datei war aufgeräumt und übersichtlich. Also reine kosmetische Änderungen, keine Reparaturen oder sowas. Weiß zufällig jemand, was ich meine und wo es das Tool gibt?

Das Tool heisst "FSNavDBC" und ist Bestandteil des FSNavigators.

www.fsnavigator.de

Es gibt aber auch den "Scenery Manager" von Hans Hartmann (AVSIM, FLIGHTSIM)

:ms: Ich bring ihn um... das hat er gar nicht verdient. Immer dieser Hans mit dem soooooo schlechten Scenery Manager.... Es gibt nur EIN Tool des Scenery-Managements:

http://www.scenery-manager.com
Downloads momentan nur unter:
http://www.flightxtreme.de/old.htm

(p.s. Bitte meinen Kommentar nicht ernst nehmen. ;) )

Hat schon jemand Hans Hartmann's SCM2004 Scenery Manager erwähnt?? :D :D ;)

Also dieser komische Scenery-Manager von diesem Bazi (Garbers, Andragar, oder unter welchem Namen der sich gerade vor der Polizei versteckt:D ) ist echt furchtbar. Ich kann nur das erstklassige SCM2004 von Hans Hartmann empfehlen - das ist wenigstens richtig programmiert worden und kein Visual Basic-Gefuddel ;)

Was ist ein Scenery manager und warum habe ich immer noch keinen CRJ mit FMC auf meiner Festplatte....?!?!?!?!?!?!?!?!?!? :D

http://www.feelthere.com:D :D :D

:D

Öhm... ich könnte dich auch fragen, wieso ich hier weder Pizza noch Bier habe und warum mein Auto heute morgen nicht blitzblank geputzt und poliert war :D

Weil Du Faul bist!
Du machst nicht am CRJ weiter, gehst nicht einkaufen, und pflegst Deinen neuen BMW nicht!

Aber in Foren rumspammen, das kannste.... :D

Kein Bier daheim zu haben find ich auch total furchtbar. Zumal Bier ja lt. so einem Professor der "Hochschule für Landwirtschaft und Brauerei in Weihenstephan" ein sehr gesundes Getränk ist. Kam zumindest mal im Fernsehen. Öhm, ja, genau. Prost!

@all: danke erstmal für die Tips. Ich glaube, einer der beiden Scenery Manager war es auch, was ich damals benutzt hab. Ich vermute allerdings, dass es dieses (Achtung, Zitat!) "Visual Basic-Gefuddel" von dem "Bazi" war. :D Ich werds nachher einfach mal testen.

PS: die Frage nach dem CRJ mit FMC stelle ich mir auch schon seit einiger Zeit... ;)

An alle die sich Fragen wo ihr CRJ ist... Ich werde Hans jetzt dauerhaft auf ICQ nerven :D

:D

Hallo Thorsten!

Die gleiche Frage wurde erst kürzlich besprochen. Nämlich hier und hier .

Tschüß

Michi:cool:

Und er hat's wieder gemacht! Dieser Saftsack...
So ein funktional minderbemitteltes Tool verbreiten zu wollen.

Und wie ich sehe hab ich einen der Thread noch übersehen.

Na warte Hans, wenn es da irgendwann einmal einen Vergleichstest gibt... Dann kommt raus, was gefuddel ist und was reine lange Weile war. Immerhin hat sich Hans nicht mal getraut für sein Tool Geld zu verlangen. :D

... und außerdem ... wenn ich bedenke wie viele Robben wegen seinem Tool sterben mussten!!!

Meins war Langeweile... SCM2004 ist in der Abflughalle in EDDG auf dem Notebook entstanden, als ich auf meinen Flieger nach Toulouse gewartet habe:p

Naja, man merkt eben, dass du nicht viel Zeit hattest. ;)

2 Stunden immerhin... Den Rest habe ich dann abends in der Hotelbar programmiert. Nach diversen Bieren :bier: :D

Immerhin muss ich mich im Gegensatz zu dir nicht in der Schweiz verstecken, weil die User meines Programms hinter mir her sind. Und verlaß dich drauf: die jagen dich nicht, weil sie Autogramme wollen;)

Hallo Michi!

Das mag sein, dass die Frage erst kürzlich besprochen wurde. Ich hab die beiden Threads aber trotz intensiver Suche hier im Forum nicht gefunden. Vielleicht, weil die Suchbegriffe, die ich mit dem Problem assoziiert habe und nach denen ich gesucht habe, nicht in den Threads vorkommen? Könnte doch eine Erklärung sein, oder? Und weil ich zu der Frage nichts gefunden habe, hab ich sie gestellt. So einfach ist das.

Tschüß :cool:

So, ich hab die gesuchte Funktion wieder gefunden. Sie war, wie ich ganz zu Beginn vermutet hatte, im FSM von Rana.

Tja, der FSSM von Andragar war es nicht, nach der Installation hab ich gemerkt, dass mir das Tool vollkommen unbekannt war.

Der SCM von Hans tut zwar sortieren, aber leider genau andersrum, als ich es will. Der SCM von Hans gleicht die Layer-Einträge an die Area-Nummern an - und ändert somit die Prioritäts-Reihenfolge in der Szenerie-Bibliothek. Ich wollte aber eine Angleichung der Area-Nummern an die Layer-Einträge, so dass sich die Reihenfolge in der Bibliothek nicht ändert, sondern nur der Aufbau der scenery.cfg.

Wen es interessiert, die Funktion ist im FSM zu finden, wenn man unter "Diagnostic Tools" im Reiter "Scenery" die Funktion "Scan for Errors" ausführt und anschließend die gefundenen Fehler korrigieren lässt.

SCM nummeriert Areas und Layers nach der Reihenfolge der angezeigten Liste durch. Da wird nichts an der Area-Reihenfolge geändert.

Genau das sag ich ja. Für die Reihenfolge in der Scenerie-Bibliothek ist aber nicht die Area relevant, sondern Layer. Kleines Beispiel: ich hatte auf Area 84 den Eintrag der Misty Fjords Scenery, die aber den Layer 53 hatte. Was ich wollte, war die Anpassung der Area an diesen Layer, also von Area 84 auf Area 53. Dein Tool hat aber die Area so belassen, wie sie war und Layer auf 84 gesetzt. Damit hat der Eintrag in der Szenerie-Bibliothek eine höhrer Priorität bekommen. Ich weiß doch schließlich, was ich gestern auf meinem PC gesehen hab, ich saß ja immerhin davor und schlechte Augen hab ich zum Glück noch nicht. Und cfg-Dateien lesen kann ich auch. :hammer:

Moin,

ich bin gerade auf diesen Threat gestoßen, nachdem ich bei Benutzung des SCM2004 auf Eigenschaften gestoßen bin, die ich eigentlich auf keinen Fall haben wollte.
Ich kopier meinen Beitrag aus einem anderen Forum mal hier rein. Offensichtlich stimmen meine Ergebnisse mit der Wirklichkeit überein. Ich frage mich dann nur noch, wozu dieser SCM eigentlich nützlich ist ......

--------------
Kopie :

Moin,

jetzt hab ich dieses SCM2004 nochmal etwas gründlicher beäugt.
Renumber benutzt und neue scenery.cfg mit der alten verglichen.

In der neuen wurden Einträge von CanarySim gelöscht, und zwar
- Coast Line
- 1 x La Palma (war doppelt vorhanden, also ok)
- La Gomera
- Tenerife
- Gran Canaria
- El Hierro
Die weiteren Einträge von CanarySim blieben erhalten.

Die neue scenery.cfg enthält also 6 areas weniger.
Aber jetzt kommts:
Die Reihenfolge der Einträge blieb bestehen, es wurde nur neu durchnumeriert, und zwar nicht nur bei den areas, sondern auch bei den Layern, wobei die Layer dieselbe Nummer bekamen wie die areas !!!!
Ergebnis ist ein totales Durcheinander bei den Prioritäten. Ich hab das nach FlusiNeustart noch einmal kontrolliert und bestätigt bekommen.

Mit anderen Worten:
Zumindest nach der Melodie meines Vorgehens ist von einer Benutzung des SCM2004 zu warnen. Andererseits müsste das doch eigentlich bekannt sein, deshalb misstraue ich immer noch ein wenig meiner Vorgehensweise.

----------

Komisch ich dachte dieses Problem hätte sich für den SCM 2004 erledigt.

Denn dieser Sachverhalt war ja nicht neu. Siehe mein Posting vom 02 November 2002.

scenery.cfg - area und layer Nummer


Der Text meines damaligen Posting.


"Also ich komme gerade von Schubi. Er wollte was zur Erstellung eigener Scenerien wissen. Da haben wir was programmiert und die neue BGL Datei einfach in eine meiner bestehenden Scenerien deren Priorität mir bekannt war reinkopiert. Nach Start des FS musste ich feststellen, das der FS diese neue Scenerie nicht darstellt, obwohl er es laut meinem Wissenstand sollte. Darauf habe ich mir mal die Sceneriebibliothek und die dazugehörige Scenery.CFG, wo "Microsoft lässt grüssen natürlich alles in der Nummerierung bezüglich Prioität anders rum ist" angesehen. In der Sceneriebibliothek hat die kleinste Nummer die höchste Priorität wird also vorrangig behandelt. In der Scenery.CFG hat die höchste Nummer die höhere Priorität. Wie gesagt ist beides das gleiche. Die Sceneriebibliothek ist das Menü im FS. Die Scenerie.CFG ist die Datei die im FS optisch schön dargestellt wird wenn man die Bibliothek öffnet. Schubi verkündete mir stolz, das er Dank dem SCM Tool von Hans Hartmann wieder Ordnung in der Scenery.CFG hat.

Denkste!

Optisch schon, ansonsten herrscht Chaos im FS. Sorry Hans Du kannst nichts dafür, dein Programm war ja für den FS 2000 und nicht für den FS2002.

Was der Navigator da macht weis ich nicht. Aber ich vermute mal es könnte ähnlich schlimmes sein, vielleicht sortiert er aber vorrangig nach Layer Numern.


Entgegen dem was hier geschrieben worden ist, hat die Layer Nummer sehr wohl einen Einfluss, sie ist sogar das entscheidende an der Priorität von Scenerien. Was unwichtig ist, ist die Area Nummer.

Die Area Nummer ist quasi nur eine Aufzählung wann eine Scenerie installiert wurde.
Umso höhere die Nummer ist umso neuer ist die Scenerie. Normalerweise laufen Area und Layer Nummer konform, wenn keine Eingiffe durch löschen bzw. durch verschieben von Scenerien erfolgt. Dann hätten wir auch kein Problem mit der Config Datei. Der FS akzeptiert sogar das z.B ein Mesh File wie das Lago Mesh höher als ein Landclassfile positioniert werden kann obwohl es doch eigentlich logisch wäre, das ein Gitternetz (Mesh) niedriger postioniert werden müsste in der Priorität als ein Landclassfile welches doch wie eine Bodentexturtapete auf dem Mesh File liegen sollte. Der FS akzeptiert dieses aber da er die Header der BGL Dateien ausliest und hierraus schon eine sinnvolle Priorität ableitet. Der normale User merkt im Regelfall gar nichts davon. Wie schon erwähnt tritt diese Unordnung erst dann auf wenn ich Scenerien lösche bzw. Scenerien in der Priorität verschiebe. Dieses kann durch einen persönlich sein oder aber auch automatisch durch Installationsroutinen erfolgen.

Fakt ist, das die Unordnung keine Probleme im FS auslöst.
Wie oben beschrieben denkt der FS bezüglich Priorität von unterschiedlichen Scenerie Varianten wie Mesh, Landclass, Airports anderen Scenerien mit 3D Objekten mit. Er denkt auch bei Scenerien gleicher Art wie z.B Landclass (Anmerkung diese Dateien werden eigentlich nicht über die Bibliothek gehandelt) mit. Eine kleinere Scenerie wird im Regelfall in der Priorität höher gehandelt als eine flächenmäßig grössere die den gleichen Bereich mit abdeckt. Problematisch wird es aber z.B wenn ich z.B die Austrian Airports nutze hier z.B Innsbruck. Zu einem späteren Zeitpunkt erwerbe ich German Airports 1 auch mit Innsbruck. Da diese Scenerie später installiert wird erhält diese eine höhere Area und Layer Nummer in der Scenery.CFG so das man im FS jetzt den GAP Airport in Innsbruck sieht. Eigentlich gefällt mir aber Innsbruck von Austrian Airports besser. Also ändere ich in der Scenery Bibliothek die Priorität und verschiebe die zu erst installierten Austrian Airports in der Priorität nach oben so das diese Variante zur Anzeige kommt. Was ändert sich jetzt in der Scenery.CFG.

Die Area Nummer nicht da sie ja quasi die Reihenfolge der Installation angibt. (Hier hat sich ja nichts geändert) Aber die Layer Nummer wird gewechselt um die Priorität zu wechseln. Und schon findet eine Abweichung statt. Es ist nicht mehr konform zueinander. Den FS interressiert nur die LAYER Nummer damit er weis war vorrangig darzustellen ist. Wann was installiert oder gelöscht wurde ist für die Darstellung nicht wichtig. Ausserdem machen Flatten und Exclude Befehle für Scenerien nur Sinn (wie von jemand anders hier schon erwähnt) wenn sie an den richtigen Layer Nummern in der CFG stehen. Umso mehr Änderungen und Verschiebungen ich mache umso chaotischer wird es (wie gesagt ohne Folgen, eine schlecht positionierte Scenerie in der Bibliothek ist kritischer).

Tja Hans sein Tool hat halt das Problem, das es wohl vorrangig nach der Area Nummer sortiert( Mag im FS2000 noch richtig gewesen sein im FS2002 nicht mehr)

Werden jetzt aber die Layernummern durch ein Tool entsprechend der Area umsortiert, und dadurch optisch richtig, aber vom Darstellungswunsch abweichend positioniert, kann es passieren das Exclude oder Flatten Befehle unwirksam werden und Scenerien nicht mehr wie gewünscht dargestellt werden, so wie bei Schubi geschehen.

Beim Scenery Mananger kann man aber den alten Zustand einfach wieder herstellen da eine Sicherungskopie Scenery.scm existiert. Diese kann man nach Scenbery.cfg wieder umbennen, wenn man die fehlerhafte zuvor entfernt hat. Also aufpassen man kann hier was falsch machen.

Gruss Joachim"

Kurze Anmerkung bezüglich Landclass Scenerien.

Zu diesem Satz unten hatte mich Rolf Schon (VFR Airfields) mal festgenagelt.

"Er denkt auch bei Scenerien gleicher Art wie z.B Landclass (Anmerkung diese Dateien werden eigentlich nicht über die Bibliothek gehandelt) mit. Eine kleinere Scenerie wird im Regelfall in der Priorität höher gehandelt als eine flächenmäßig grössere die den gleichen Bereich mit abdeckt."

Er hatte hier aber etwas anders gedacht. Hier ging es nur um die damals häufige Addon Landclass Installation in den Pfad wo auch der FS2002 sein Default Landclass abgelegt hat. Dort hat ein kleineres Landclassfile eine höhere Priorität gegenüber dem Default LC File.

Deshalb auch der Vermerk "werden eigentlich nicht über die Bibliothek gehandelt"

Mittlerweile gehen die Addon Designer sinnvoller Weise anders vor.

LC Files werden als Addon Scenerien in der Scenerybibliothek extra verwaltet.

Bringt ein Addon Designer mehrere LC Files in einer Scenery unter regelt er wenn er es weis die sinnvolle Priorität über die alphabetische Reihenfolge.

SCM2004 macht nach meiner Erfahrung nur Sinn, wenn man komplett auf den Flusi eigenen Scenery Manager verzichtet - und zwar konsequent.

Der Flusi-Manager selbst läßt ja die Areas konstant und verändert nur die Layereinträge. Ich zumindest bin da schon nach ein paar Mal Herumschieben von Szenerien nicht mehr durchgestiegen, wo jetzt welche Szenerie steht und welche Layer eigentlich frei sind, wenn ich mal eine Szenerie abschalte.

SCM möchte ich nicht mehr missen, hat mir schon so manche Umsortiererei erleichtert. Dafür ein Dankeschön an Hans!!

Dem möchte ich wiedersprechen. Habe den SCM2004 mal runtergeladen und ihn auf eine Scenery.cfg eines anderen Anwender losgelassen. Nur das verschieben einer Scenery auf eine andere Priorotät bewirkte, dass ein paar Scenerien überhaupt nicht mehr in der Scenery.cfg auftauchen.

Das darf nicht sein.

Denn diese Scenerien hatten keinen funktionellen Fehler hinsichtlich Eintrag in der Scenery.cfg.

Die zu einer einzelnen Scenery gehörenden Einträge waren lediglich hinsichtlich Zeilen vertauscht. Auch fehlte die sonst übliche Leerzeile zwischen zwei Scenerien.

Ok Du sagst man sollte ihn nur auf eine Scenery.cfg loslassen wenn man den FS internen Scenery Manager nicht verwendet.

Nur dazu muss man folgendes sagen. Der FS interne Scenery Manager hätte nicht diese Leerzeile vergessen. Er hätte auch nicht die zu einer Scenery gehörenden Zeilen so vertauscht.

Man sollte wissen, das die zu Addons gehörenden Installer auch so etwas verursachen. Einige tragen neu hinzukommende Addons so ein als wenn man ganz normal anmeldet. Diese Addons werden sich dann in der Scenery Bibliothek immer ganz oben finden. Andere gehen, weil sie z.B wissen, dass es bei dem Addon Typ nötig ist anders vor. Sie installieren die Scenery weiter unten. Das setzt quasi eine etwas aufwendigere Editierung der scenery.cfg voraus.

Das führt dann aber ebenfalls hin und wieder dazu, dass Area und Layer nicht konform laufen, oder das eben auch mal Leerzeilen fehlen bzw. die Zeilen die zu einem Scenery Eintrag gehören die typische Reihenfolge nicht haben.

Wenn der SCM damit nicht klar kommt, dann hat er halt leider ein Problem. Denn er ist dann nur bei einem Default FS störungsfrei zu nutzen.

Nur da wird er nicht benötigt. Denn da gibt es keinen Grund die Scenery.cfg zu editieren.

Bei allen anderen kann aber eben nie gewährleistet werden, dass alle Addon Installer immer 100% sauber arbeiten.

Wir reden hier nicht von funktionell sauber, sondern nur von optisch konform.

Dumdideldei...

http://www.flightxtreme.com/old.htm

ups... hatte ich ja schon erwähnt. ;)

@Jobia: Ich sehe zwar keinen Sinn darin, die Area- von der Layernummer zu trennen, aber da irgendein "Genie" bei Microsoft der Meinung war, das so machen zu müssen, muss ich wohl mit den Konsequenzen leben.

Ich werde es also bei Gelegenheit ändern und eine neue Version rausgeben.

@Alle: Wenn noch irgendjemand irgendwelche Wünsche für neue Features hat, bitte PM oder Email an mich.


Ach ja: Und macht nicht den Fehler und lasst euch vom Bösen dazu verleiten, in Visual Basic geschriebene Bazi-Software einzusetzen *duckundwech*:D

:engel:

Könntest du zu dem SCM noch ein CRJ mit FMC dazupacken? Danke. :aio:

Und vielleicht noch ne Piper Cheyenne? :D

Beides abgelehnt! Sonst noch Wünsche?

*weiter CRJ flieg*

Moin,

ich hab jetzt noch einmal Tests mit SCM durchgeführt (wie gesagt, war neu für mich) und die bisherigen Aussagen bestätigt bekommen.

Versuch mit meiner scenery.cfg, entstanden aus normalen FlusiInstallationen mit anschließenden Verschiebungen wegen Priorität. Totales Durcheinander von Area- und Layer-Numerierungen. Funktioniert aber im Flusi so, wie es soll.
Nach Aufruf von SCM werden die Einträge in der Reihenfolge der Areas gelistet.
Unter No. steht die Layer-Nummer.
Nach Verschieben eines Eintrags oder nach ´Renumber´ wird neu sortiert. Die Layer bekommen die gleiche Nummer wie die Area ! Und damit ist der Aufbau nach Prioritäten im Flusi dahin. Außerdem fehlen bei mir sechs Einträge, und zwar alle, die bei ´Remote=´ einen Eintrag haben und bei ´Local=´ keinen. Ist momentan so bei Scenerien von CanarySim. Ich hab das mal geändert, und dann war´s in dem Punkt ok.

Ich hab dann mal in der .cfg von Hand die Areas neu numeriert, zugeordnet den Layern, und das Ganze in die richtige Reihenfolge gebracht. Ging viel schneller als gedacht. Aber genau das hatte ich eigentlich vom SCM erwartet.
Der SCM stellt eine so ´fertige´ scenery.cfg übersichtlich dar, anschließende Verschiebungen von Prioritäten funktionieren tadellos, selbst das Verschieben von ganzen Blöcken. Das Hinzufügen neuer Scenerien wird auch übersichtlicher. Ein danke an Hans. Aber wie gesagt: Ausgangspunkt muss eine fein sortierte .cfg sein !

Deshalb meine Bitte an Hans, falls er sich wirklich noch einmal an eine Überarbeitung macht:
Nimm mal als Ausgangspunkt meine strubbelige .cfg incl. der fehlenden Einträge bei Local= .

Upps, der Anhang fehlte

Ausgelagerte Sceneries? Das ist mir noch nie untergekommen, aber ich werde es berücksichtigen.

Hast du was dagegen, wenn ich die Layers weiterhin mit den Areas abgleiche, dabei aber in Zukunft die Layers als Sortiergrundlage nehme? Wenn die scenery.cfg so total durcheinander gewürfelt ist, ist das ziemlich unschön.

Das Abgleichen von Areas und Layern ist ok und sogar sehr übersichtlich. Aber es muss beim Sortieren der Layer die Zuordnung zur Scenery bleiben. Unter welcher Area ist eigentlich egal, aber wie Du schon sagst, übersichtlicher sind gleiche Numerierungen von Area und Layer.
Ich häng mal meine von Hand geänderte .cfg an. So sollte das Ergebnis der automatischen Sortierung aussehen.

Edit:
Das sind übrigens keine ausgelagerten Scenerien, die liegen direkt unter dem Flusi bei den anderen. Der Herr CanarySim stellt das bei der Installation nur so dar.

Nun, trotzdem verwendet der Flusi dann den ominösen Flusi-Cache in der CFG um files der Remote Szenerien in den filecache zu verschieben. In dieser Situation völliger Unfug.

Remote Szenerien lohnen dann, wenn man Scenerien z.B. auf CD brennt oder auf langsamen aber großen Speichermedien (z.B. auch im Netzwerk) installiert. Dann kann der Flusi sie (bei bedarf!) auf die lokale Festplatte kopieren.

Kann man übrigens alles in meinem Manual nachlesen. ;)

Hans, ich mache das mit den Area und Layern eigentlich auch so. Allerdings eben bezüglich der Layer und nicht der Area. Der Wechsel deinerseits macht also durchaus Sinn.

Und genau deshalb hab ich das geändert. Die Adresse steht jetzt nur noch unter Local.
Trotzdem sollte man das im SCM berücksichtigen und bei einem eventuellen Eintrag unter Remote nicht die Scenery löschen. Aber das wurde ja schon gesagt.

Das war ja eigentlich das, was ich, als ursprünglicher Initiator des Threads, gesucht habe. Bei meinem Hinweis, dass der SCM genau das eben nicht tut, kam von Hans diese Aussage:

Da wurde mein Hinweis von Hans mit der zitierten Aussage abgetan, jetzt stellt sich heraus, dass ich doch richtig gelegen habe. :rolleyes:

Wie auch immer, ich habe das Tool, das ich gesucht habe, gefunden. Wie bereits erwähnt, tut eine Funktion des FSM von Rana genau eben das, nämlich die Layer als Sortiergrundlage verwenden.

Zu

"Außerdem fehlen bei mir sechs Einträge, und zwar alle, die bei ´Remote=´ einen Eintrag haben und bei ´Local=´ keinen. Ist momentan so bei Scenerien von CanarySim. Ich hab das mal geändert, und dann war´s in dem Punkt ok."


Ja exakt.

Unter anderem diese Scenerien der mir geschickten Anwender Scenery.cfg haben nachher auch bei der Überarbeitung mit SCM bei mir gefehlt.

Eigentlich ein Problem des Installers dieser Scenerien. Trotzdem ist es so funktionsfähig gewesen.

Man muss halt immer auch mit dummen Installern rechnen.

Ihr wisst ja ich bin ein Feind von Installern, akzeptiere natürlich auch, dass man nicht jeden auf eine Handinstallation loslassen kann, obwohl dieses dem Anwender etwas mehr Überblick und Wissen bringen würde.



Zu
Ok es sieht für einen Anwender in der Tat chaotisch aus.

Aber nur wenn man in die Scenery.cfg schaut. In der Scenery Bibliothek ist es ja optisch OK.

Ich sehe darin aber trotzdem einen positiven Sinn, den man nicht sofort erkennt.

Layer ist die Anzeigepriorität (natürlich nur bei den Techniken wo der FS keine Priobugs hat)

Wenn man das weis ist das schon mal OK.

Area ist die Installationsreihenfolge der Scenerien / Addons.

Für mich ist das insofern interessant, da sich diese wenn nicht ein externes Tool dran rumfummelt hinsichtlich Nummerierung nicht ändert.

Warum ist das interessant?


Weil man speziel bei Flächenscenerien wie AROE oder UT oder eben auch was kleineres wie Scenery Germany sehen kann in welcher Reihenfolge was installiert wurde.

Ihr wisst ja das solche und andere Addons Defaultdateien umbenennen oder sogar unter identischen Namen als neue Dateien einspielen, dass kann zu großen Probleme führen, denn das kann jetzt mehrfach passieren.

Eine Defaultdatei wird durch eine Addon Datei gleichen Namens überschrieben. Das nächste Addon versucht das selbe. Aber es überschreibt keine Defaultscenery mehr sondern bereits eine Addon Datei.

Über die Area Nummer und eine nicht manuell nachträglich editierte Scenerys .cfg (außer über dass FS Bibliotheksmenü selbst) kann ich also mit ein bischen Ahnung von Scenerien erkennen, wo es hier bei Installation von Addons zu Problemen gekommen sein kann.

Übrigens ev. wäre das sogar für den ein oder anderen Installer eines Flächen Addons interessant, da man so Probleme erkennen kann.


Wer weis, ev. war das ja sogar einer der Gründe warum man die Area Nummer als fortlaufende Installationsreihenfolge beim FS2002 unabhängig von der eigentlichen Prio über die Layernummer eingerichtet hat.

Denn die kritischen Scenerytechniken sind mit dem FS2002 gekommen.

Könnte ja mal für Diagnosezwecke gedacht gewesen sein, wenn der FS mal eine Meldung nach Hause schicken will.

Vermutlich aber war es Historie.

Zu FS2000 Zeiten war mein Wissen noch äußerst minimal, da können andere bestimmt mehr zu sagen, ob es da definitiv anders gewesen ist. Ich meine ja, ist aber schon zu lange her das ungeliebte Kind FS2000.