Hallo Zusammen,

im Grunde ist das Problem ja schon definiert. Es gibt keine vernünftige Möglichkeit den Wunsch der User nach immer perfekteren Szenerien zu befriedigen ohne MS-Defaults durch Umbenennen zu deaktivieren. in meinen Augen ist dies auch nicht wirklich ein Problem, wenn man hier eine Art Normung durchsetzen könnte.

Lösungsansatz: Der Installer einer Szenerie muss ein Defaultfile umbenennen um es zu deaktivieren. Er findet die Datei und benennt sie um, und zwar mit einer genormten Endung, z.B. "OFF", wie von Jobia vorgeschlagen. Der nächste installer sucht zwecks Deaktivierung nacht der originalen "BGL"-Datei und findet sie nicht. Statt nun mit Fehlermeldung auszusteigen, sucht der Installer nun nach der Datei mit dem Ending "OFF". Findet sie, weis nun das die Datei bereits deaktiviert wurde und installiert sich fröhlich weiter.

Für den Fall, das eine Defaultdatei nicht nur deaktiviert, sonder durch eine gleichnamige AddOn-Datei ersetzt werden soll, einige man sich auf ein Präfix. Beispielsweise ein "NEW" vor dem Dateinamen. Findet nun der Installer eine Datei mit dem Präfix "NEW" so unterbricht er den Installationsvorgang und fragt den User "Sach mal, ich will ne Datei in Deinen Flusi packen, die das schon von einem anderen AddOn gibt, welche soll ich nehmen? Im Idealfalle entscheidet sich nunder User und die Installation wird fortgesetzt. Am hübschesten wäre es wenn die Frage nicht im Sinne von "Soll die durch ein anderes AddOn erstellte Datei NEW1234567.bgl durch die Datei NEW1234567.bgl von PRIMAADDONS esetzt werden?" sonder der User zumindest Infos darüber erhält ob es sich um Landklassen, Küstenlinien, Gewässer oder Spinatdosen handelt.

Macht es so, alle sind happy, oder?

Diese Normierung wird nicht Funktionieren. Es gibt zu viele Scenery-Designer. Selbst "intern" - was auch immer das bei einem Publisher bedeuten mag - schafft man das nicht durchgängig.

Bei FSQ hat man das jetzt mit der Endung FSQ versucht. (AP hat noch andere Endungen.) Nur ist das auch etwas daneben, denn ich will wissen zu welchem Addon diese Backup Datei gehört, nicht zu welchem Publisher.

Die Idee, die Rolf hier aufbrachte, würde mit Metadaten funktionieren. Der Installer kann so jederzeit in dieser Metadatenbank den Installationszustand erfahren und handeln.

Nachteil: Dieser Installer müßte von möglichst vielen Addons benutzt werden. Sonst muss man immer wieder die Metadatenbank neu aufbauen, was ein dekompilieren von bgls beinhaltet um z.b. das Einflußgebiet der bgl heraus zu finden. Dieser Prozess würde eine Ewigkeit dauern.

Besser: Ein Überwachungsprogramm welches die Installationen überwacht und dann direkt nach einer Installation die Metadaten ausliest. Dann kann man über dieses Programm die Änderungen anpassen, ja sogar die Addons wieder deinstallieren. Nachteil: Alle Daten müssten Doppelt vorliegen, damit dieses Programm die Änderungen tatsächlich durchführen kann.

Alles kein einfaches Thema.

Hi Michael,

stimmt, das mit der Durchsetzbarkeit ist ein Problem, aber, anders wird man der Sache nciht Herr werden. Wie du schon geschrieben hast ist der Auffwand das anders zu lösen noch größer, und wenn man sich schon nicht auf eine einfache Dateiendung einigen kann, dann wird man sich auf einen einheitlichen Installer schonmal überhaupt nicht einigen.
Das problem mit Individualisten (was man von Szeneriedesigner wohl durch die Bank behaubten darf:D ) ist halt, das sie sich immer von der Masse abheben müssen.
Trotz allem halte ich meine Idee für durchsetzbar, wenn auch nicht von heute auf morgen. Wenn erstmal die großen komerziellen Schmieden sich auf sowas einigen könnten, wäre der Trend schon fast gesetzt. Die kleineren und die Freiwarehersteller käme fast von selbst hinterher, weil man ansonsten mit gewissen "Must Haves" nicht mehr arbeiten kann.
Es wurden doch gerade im IT bereich immer wieder neue Standarts erfunden, verworfen, akzeptiert oder verändert. Wenn wir keine Standarts nutzen entsteht Chaos und wir sind, zumindest im AddOn Bereich schon ziemlich nahe dran.:(

Hallo Miteinander,

Nochmal zu Jobias Beitrag oben.

Zustimmung zu seiner Verwunderung, daß man sich seitens FSQ darüber beschwert, daß bei einem Fremdaddon Daten umbenannt werden, der AROE - Installer sie nicht findet und im gleichen Atemzug das Selbe macht.

Trotzdem, das ist eigentlich eine Randnotiz.

Das Grundproblem ist jetzt bereits mehrfach benannt worden: besondere Szenerietechnik geht nur mit Umbenennung
von Default Dateien. Das ist ein gesichertes Faktum, genauso wie die damit verbundenen Probleme. Und diese Problemstellung ruft eigentlich nach einer intelligenten Lösung.

Und nun mein Widerspruch zu Jobia. Man darf sich überhaupt nicht auf die Schiene begeben, " hilf Dir Selbst, so hilft Dir Gott " - installier Dir Deine Szenerie händisch anhand der Infos aus dem Handbuch. Das geht m.E. letztendlich in die Hose und ist in höchstem Masse nutzerunfreundlich. Dies könnte allerhöchstens eine Notlösung in einer verfahrenen Situation sein, bis etwas Besseres gefunden wird. Bliebe man bei dieser Lösung stehen, das wäre ein echter Rückschritt.

Es kann doch nicht so schwer sein, ein erkanntes Problem mit Hilfe leidlich intelligenter Technik zu lösen.

Gruß
Rolf

Es wird von vielen hier ein ganz schwerer Fehler gemacht!
Nur ein kleiner Teil unserer User ist im Web, und ein Grossteil aller User ganz sicher nicht in der Lage eine Installation per Hand durchzuführen. Nicht so eine um die es hier geht!

Und ein weiss ich ganz sicher:
Wehe dem der keinen Installer anbietet, der wird die "besten Kritiken" in Test und Reviews haben!

Der folgende Text war vorgeschrieben und hängt praktisch dort an wo ich heute morgen aufgehört habe.

Deshalb ist es nicht unbedingt als Statement für die anderen folgenden Postings zu sehen.



Bisher sind ja mehr oder weniger nur die Probleme des Installers und der fehlerhaften Objektdatei zur Geltung gekommen.

Zu der Sachlage, dass AROE kurioser Weise auch nicht zur ATP kompatibel ist und zu der Äußerung, dass es ein Heinz Rückeshauser wissen müsste. Ich selbst konnte das bisher nicht prüfen ob es ein Kompatibilitätsproblem ist. Ev. liegt es ja auch nur an einem nicht korrekt durchgeführten Installationsvorgang der AROE.


Wenn ich mir das Begleitheft anschaue und die deutschen Texte lese, dann kommt es mir persönlich so vor, als wenn die eigentliche Dokumentation keine deutsche sondern die englische war. Ev. wurde die Dokumentation erst später ins deutsche übersetzt?????

Man kann daher nur mutmaßen ob alles in den Händen von Heinz lag. Wer kann von uns schon wissen wer zu dem kompletten Designteam gehört. Ev. Designer aus einem anders sprachigen Raum????

Vielleicht ist das auch der Grund warum man im Bereich der ATP auf die von einigen Anwendern erwähnten doppelten Straßen trifft???

Nun mal zum Produkt AROE selbst, denn das ist bisher viel zu kurz gekommen.

Ich habe mal als Beispiel zwei Screenshots an identischen Positionen im Raum München erstellt. Einmal die Real Germany 3.

Eine optimal vorbereitete Fotoscenery anhand Orthofotos ist hinsichtlich Genauigkeit eine Art Referenz anhand der man sich sehr gut richten kann.

Den Screenshot der Real Germany3 RG3800.JPG finden wir unten im Anhang.
Leider haben beide Screenshots etwas durch die Komprimierung ins JPG Format gelitten.

Im Anhang unten die selbe Situation unter AROE. Als Basisunterlage dient die Default LC Scenery. So kann man die Straßen besser erkennen.

Hier kann man im Bereich der roten Pfeile auch noch die vorhandenen Default VTP Linienflüsse erkennen. Man sieht die unkorrekte Lage der Microsoftdaten, die hier ausnahmsweise noch harmlos ausfällt. Eigentlich enpfiehlt es sich wie schon von Marc bzw. im Handbuch erwähnt diese zu entfernen. Beim Vergleichsbild der RG3 sieht man sehr schön das diese Linienflüsse real im Luftbild an anderen Stellen zum Teil auch untergehen. Entfernt man diese Defaultlinienflüsse, dann wird dieses etwas größere LWM Gewässer unten allerdings nicht mehr mit Wasser gespeist. Das wirkt dann doch etwas verloren, zumal dieser kleine Fluss etwas weiter oben (hier im Screenshot nicht zu sehen auf Höhe des Airports wieder als AROE LWM Fluss auftaucht).

In der RG3 ist dieser Fluss durchgehend zu erkennen. Allerdings fairer Weise gesagt vermutlich nicht anhand der Gewässeroberfläche sondern eher anhand des Buschwerkes bzw. Ufergürtels was man immer neben den Flüssen hat. Die Navi GPS Daten enthalten in der Regel aber immer die realen Gewässerdaten.

In meinen NAVI Daten ist dieser Fluss zwar auch im kompletten Verlauf in fast konstanter Breite zu erkennen, was wie gesagt aber nicht bedeutet, dass dieses bei jedem NAV Datenlieferant so sein muss. Von daher vermute ich mal das es ein Grenzfall war, der zu tolerieren ist. Ev. sind diese Stellen auch zu schmal um sie in LWM Technik umzusetzen.

Vielleicht reicht man ja so etwas irgendwann mal als VTP Linienfluss zusammen mit VTP Uferlinen als AddPack nach.

Weiterhin muss man natürlich erwähnen, dass die Defaultlandclasscenery eh nicht das passende Umfeld für die AROE ist. Mit einem Landclassaddon fallen diese Unterbrechungen wesentlich weniger auf. Denn dann kommt man optisch auch dem Sachverhalt näher wie man es in der Realität öfters sieht, nämlich das diese Flussteile auch in der Realität zwischen Bewuchs und Feldern untergehen.

Ähnliches kann man z.B sehr schön bei den Straßenverläufen der RG3 sehen. Bei einigen kleineren Straßen speziell denen die zwischen Feldern entlanglaufen, hat man Schwierigkeiten diese in der RG3 zu finden. In der AROE innerhalb der Defaultscenery sind diese eindeutig zu erkennen. Erst bei bei genauer Beobachtung der Feldverläufe bzw. bei Überlagerung der Screenhots der RG3 kann man erkennen, dass sie existieren und ebenfalls wieder 100% passgenau in Form und Breite umgesetzt wurden.



Der Screenshot der AROE AROE800.JPG im Anhang.

Man kann sich jetzt beide Bilder betrachten. Am besten man lädt sie runter und betrachtet sie dort nebeneinander oder untereinander.

Noch besser ist es aber man nimmt ein Fotoprogramm kopiert den Screenshot der AROE in den der RG3 als neues Objekt ein.

Anschliessend regelt man den überlagerten Screenshot der AROE in seiner Transparenz hin und her.

Man wird absolute Deckungsgleichheit der umgesetzten Straßen und Gewässerdaten feststellen.

Von daher kann man schon mal eines sagen, die AROE bringt leider nicht alles an Elementen was man sich sonst noch für die Gewässer wünschen würde. Aber das sollte man tolerieren. Denn es war ursprünglich zum selben Preis als reines Straßenaddon gedacht. Auch eine Anpassung der Objekte war ursprünglich nicht geplant. Wir bekommen die Gewässer und angepasste Objekte quasi geschenkt.

Außerdem verspricht man auch keine anderen Elemente die wir ev. noch gerne hätten.



Ich habe übrigends noch mehr Stellen verglichen. Es passte bisher immer 100%tig.

Wenn man diesen Vergleich wie beschrieben durchführt (unter der Vorraussetzung das nicht irgendwo innerhalb des Addons Fehler schlummern wovon ich nicht ausgehe) wird man erkennen, dass die AROE momentan als Referenz für Europa anzusehen ist. Sie ist der Masstab für alle Scenerien die in dieser Technik noch kommen werden.

Man wird auch bemerken, das die Straßenbreiten sehr exakt entsprechend der Realität umgesetzt worden sind.

Das bedeutet zwar, dass extrem schmale Straßen wie z.B innerhalb des Airports von München schwer erkennbar sind. Aber das muss man tolerieren es ist ein technikbedingtes Problem des FS.

Fazit ist, dass die AROE sehr real umgesetzt wurde und das man die früher im FXP Forum diskutierten Probleme der aufdringlichen Optik von anderen Straßenaddons bzw. anderen Flächenscenerien (die dieses Problem verursachen können)hier definitiv nicht finden wird.

Es ist wie gesagt ein Maßstab für das was noch kommen wird bzw. für das was bisher schon existiert.

Man kann es quasi nicht mehr besser umsetzen. Der Code selbst ist als optimal anzusehen. Da wird nicht mehr viel gehen.

Wenn man das noch toppen will, dann geht das eigentlich nur noch durch zusätzliche Sceneryinformationen die momentan bei der AROE noch fehlen.
Bei Straßen selbst ist da eigentlich nicht mehr viel möglich. Ev. bessere Texturen falls das aufgrund der Auflösungsbeschränkungen des FS überhaupt noch funktioniert. Ev. perfekt angepasstes Vectorautogen also Lichtmasten usw. an Straßen wo man sie auch in der Realität findet. Kleine angedeutete Tunnelportale usw. Das ist aber alles eher als Gymmick und Beiwerk anzusehen




Um auf die Probleme der AROE zurückzukommen.

Im wesentlichen ist es nur dieses Objektproblem. Wie es entstanden ist hatte Guido erwähnt.

Dann der Installer über den auch genug erzählt wurde.

Ein Hauptproblem der AROE wird bleiben, auch wenn der Installer halbwegs vernünftig arbeiten sollte.

Das Problem liegt aber nicht bei der AROE sondern beim FS selbst.


Diese hier erwähnten Scenerytechniken haben nun mal technikbedingt das Problem das keine Kompatibilität zu anderen Addons mit identischer Technik besteht. Im FS2004 hat sich das ganze eigentlich noch verschlimmert.

Das bedeutet wenn ein Addon wie AROE vernünftig arbeiten soll, dann müssen bei einem anderen Addon welches räumlich deckungsgleiche Bereiche hat die Sceneryinformationen gleicher Art deaktiviert werden.

Es sei denn das andere Addon erreicht die selbe Genauigkeit wie die Referenz AROE.

Das wird momentan nicht der Fall sein.

Das dumme daran ist aber das ein anderes Addon ev. eigene 3D Brücken oder andere Elemente mitbringt, die bei AROE fehlen.

Schaltet man bei einem anderen Addon die Straßen ab, dann stehen dessen Brücken vielleicht neben den sehr genauen AROE Straßen. Also muss man wegen des Gesamteindruckes die Brücken auch noch abschalten. Ev. geht das aber nicht, da diese in Scenerydaten untergebracht wurden die auch Airportsceneryanteile haben.

Oder man akzeptiert das Problem einfach.

Kann sein das dieses optisch tolerierbar ist.

Schlimmer dürften wie gesagt doppelte versetzte Straßen sein.

Jetzt könnte jemand sagen, ich habe es drauf und kombiniere beide Daten.

Schön. Für privaten Gebrauch machbar.

Nur das kann man als Addonproduzent eben nicht. Da kann man nicht einfach dahergehen und in anderen lizensierten Addondaten rumwursteln bzw. diese für eigene Zwecke einbauen.

Was für einen Installer bleibt ist eigentlich nur das deaktivieren aller fremden störenden Daten, mehr kann er bestenfalls eigentlich nicht ausrichten.

Das Problem was bleibt könnte der Anwender sein. Der eine möchte das AROE die Oberhand über das Straßensystem erhält. Der andere möchte lieber das die Straßen auch zu den Brücken des Addon X passen.

Von daher haben wir ein Riesenproblem.

Auch ein optimaler Installer wenn es ihn gäbe, kann das nicht automatisch entscheiden.
Es müsste zumindest der Anwender während der Installation über diese Problematik informiert werden.

Damit könnte natürlich manch unwissender Anwender wieder überfordert sein.

Eigentlich kann man erkennen, dass es nur eine vernünftige Lösung gibt.

Die wäre das optimale Komplettpacket was alles berücksichtigt. (das wurde von anderen schon erwähnt)

Das wird es aber vermutlich nicht aus einer Hand geben.

Von daher gibt es eigentlich nur den Weg den Holger einschlägt. Man muß sich notfalls mit anderen Designteams absprechen. Bei dem was ich bisher gesehen habe setzt AROE das Straßensystem aus meiner Sicht optimal um.

Es wäre sinnvoll wenn man dieses wie es auch in der FXP schon angedeutet wurde als Referenz benutzt.

Ob man sich da irgendwie nähern kann, dass kann ich nicht beurteilen. Nicht jeder Designer wird Lust haben ein anderes Produkt zu kaufen.

Für die Anwender wäre die Absprache und Einigung von Designern hinsichtlich dieser besonders kritischen Technik natürlich die beste Lösung.

Die Airportscenerytechnik ist zum Glück nicht nicht so kritisch. Wäre natürlich schön wenn hier ev. auch das ein oder andere an so eine hochgenaue Scenery wie die AROE angepasst wird.

Zu

Rolf und Christoph

"Und nun mein Widerspruch zu Jobia. Man darf sich überhaupt nicht auf die Schiene begeben, " hilf Dir Selbst, so hilft Dir Gott " - installier Dir Deine Szenerie händisch anhand der Infos aus dem Handbuch. Das geht m.E. letztendlich in die Hose und ist in höchstem Masse nutzerunfreundlich. Dies könnte allerhöchstens eine Notlösung in einer verfahrenen Situation sein, bis etwas Besseres gefunden wird. Bliebe man bei dieser Lösung stehen, das wäre ein echter Rückschritt.

Es kann doch nicht so schwer sein, ein erkanntes Problem mit Hilfe leidlich intelligenter Technik zu lösen.

Gruß
Rolf





"Es wird von vielen hier ein ganz schwerer Fehler gemacht!
Nur ein kleiner Teil unserer User ist im Web, und ein Grossteil aller User ganz sicher nicht in der Lage eine Installation per Hand durchzuführen. Nicht so eine um die es hier geht!

Und ein weiss ich ganz sicher:
Wehe dem der keinen Installer anbietet, der wird die "besten Kritiken" in Test und Reviews haben!"

von Christoph



Ich weis, das ich mich nicht als Masstab für irgendwelche Sachverhalte sehen kann. Bei mir scheint die Sicht des normalen Anwenders nicht mehr gegeben zu sein.

Das ist das Problem wenn man zu viel über die Problematik weis.

Selbst wenn man es versucht, dann lässt sich das Wissen was man hat sehr schwer gewollt auslöschen.


Ich habe ja auch nie gesagt oder gefordert: "Ihr bösen Addonproduzenten lasst bloss den Installer weg, da kommt nur Unfug bei raus".

Ich habe nur gesagt dokumentiert eure Scenerien ausreichend und bietet zumindest alternativ die Möglichkeit der manuellen Installation.

Nicht das man die Probleme auch so rausbekommt. Das ist nicht das Thema. Aber ich denke mit einer guten Dokumentation was installiert wird, lässt sich die Prozentzahl der Anwender die Probleme vor Ort erkennen wesentlich steigern.

Das bedeutet mehr Anwender sind in der Lage Probleme vor Ort zu erkennen. Mehr Anwender bedeutet mehr bzw. schnellere Fehlererkennung und damit ev. schnellere Verbreitung des Bekannten Problemes über Foren. Daraus resultiert dann ev. schnellere Beseitigung des Problemes durch die Addon Produzenten.


Denn mal ehrlich wozu machen denn diverse Addon Produzenten Betatests. Wozu geben sie Addons vorher raus.

1) Ganz einfach weil sie mit Sicherheit nicht die Zeit für große Tests haben.

2) Weiterhin weil sie unmöglich alle Addons besitzen können.

3)Weil sie nicht alle möglichen Softwarekonstellationen haben.

4) Weil sie nicht jede verschiedene Hardwarekonstellation simulieren können.

Es mag weitere oder andere Gründe geben.


Es geht hier zwar nicht um Betatests. Aber das ein ev.unter gewissen Konstellationen nicht einwandfrei laufendes neues Addon nach offiziellen Verkaufsstart möglichst schnell störungsfrei läuft, dürfte meiner Meinung nach mit einer guten Installationsdokumentation steigen.