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: