jetzt muss ich aber den Büchmann aus dem Regal holen, damit ich auch was Passendes in Latein finde..:p
Sic transit gloria munde, das kann ich aus dem Kopf...
Oder: Hic rodos, hic salta.
Oder: Salve Cäsar, die Totgeweihten grüßen Dich (da muss ich schon überlegen, ich weiß es, aber...)

So bändigt man Hamster, wäre auch ein guter Spruch auf Latein...
Nero soll das gesagt haben...:)

Ave, imperator, morituri te salutant.

Mhmm Cäsar hatte einen Hamster.. dachte ich es mir doch.

aber wir werden.. langsam aber sicher OFF TOPIC ;)

Zu Andi

Da haben wir es doch. Wenn Dir .FSQ Dateien fehlen, dann ist es auch nicht verwunderlich wenn Dir Straßen fehlen.

Mich wundert es aber auch nicht, dass Dir .FSQ Dateien gefehlt haben.

Es muss wie gesagt nicht unbedingt die Swiss Prof. sein die Brennstoff liefert.

Die ATP ist genau so zu sehen.

Das hängt aber nicht mit den erwähnten drei Dateien ab die z.B die ATP eigenen Straßen enthalten, sondern ich könnte mir vorstellen, das die ATP selbst ja auch Default Straßen oder LWM Flüsse also HP.... Files der EURW manipuliert, wie das fast alle Straßen und Gewässeraddons machen.

Das bedeutet ein HP oder RD File wurde ev. umbenannt. Der Installer der AROE findet das File nicht was er umbenennen möchte und macht ab diesem Moment Schwierigkeiten.


Der Installer ist hier offensichtlich zu pingelig programmiert.

Das bedeutet im Prinzip immer dann wenn zuvor ein anderes Addon etwas an einer Defaultscenery manipuliert hat und die AROE möchte jetzt das selbe tun, dann gibt es Probleme.

Die Simwings Scenerien manipulieren z.B in Spanien. Also sind hier ebenfalls Probleme zu erwarten.

Wie gesagt ein Problem dieser Technik des FS generell. Wäre der Installer nicht so pingelig und würde seine Sache knall hart durchziehen, gäbe es das Problem in dieser Form zwar nicht, aber die Problematik bliebt.

Ein fiktives Beispiel Nr1:

Ein Addon A möchte eine neue Gewässerscenery mit Seen und Küstenlinie installieren.

Während der Installation hat es das Defaultgewässerfile HP950140.BGL nach HP950140.AUS deaktiviert.

Weiterhin installiert es danach ein neues Gewässerfile mit gleichen Namen HP950140.BGL.

Funktioniert. Das Addon A weis was es gemacht hat. Möchte man es Deinstallieren geht alles rückwärts. Also es wird zunächst die Addon Variante HP950140.BGL gelöscht dann das HP950140.AUS wieder nach HP950140.BGL umbenannt. Prima schon haben wir den original Zustand.


Von diesem Fall gehen wir aber nicht aus. Wir gehen davon aus, das wir momentan die Sicherungskopie HP950140.AUS haben. Die Addon A Variante HP950140.BGL ist aktiv.


Jetzt kommt die AROE möchte sich installieren.

Sie möchte sich ebenfalls an der HP950140.BGL vergreifen und diese deaktivieren.

Prima der Installer der AROE findet die Datei, der Installer legt sich nicht auf die Klappe.

Aber Gefahr er möchte jetzt diese Datei durch umbenennen nach .FSQ deaktivieren.

Das macht er auch. Was er aber nicht bemerkt er deaktiviert nicht die Default Variante sondern die Addon A Variante.

(zur Anmerkung hier wäre der erste Ansatzpunkt wo ein intelligenter Installer ansetzen müsste. Er müsste Checksumme oder Datum heranziehen um zu testen ob es sich wirklich noch um eine original Datei handelt. Wenn nicht dann Fehlermeldung oder auslassen der Datei mit Infobericht und Bereitstellung der entpackten Datei um es später dem Anwender zu überlassen was er machen möchte. Das gilt es halt noch zu überlegen was da dann das beste ist)

Aber der Installer macht diese Prüfung wie vermutlich alle natürlich nicht.

Er zieht sein Sache durch.



Was bedeutet dieses für die AROE.

Nun die AROE wird so arbeiten wie es sein soll.

Ev. Addon A aber nicht ganz korrekt, weil seine HP950140.BGL Gewässer Variante jetzt durch die AROE nach HP950140.FSQ deaktiviert wurde.

Addon A hat bringt nämlich im Gegensatz zur AROE in einem anderen File einen eigenen VTP Küstenstreifen mit Brandungung mit. Da Addon A von Hand erstellt war und nicht diese Genauigkeit wie AROE hat, schwebt jetzt diese schmale Küstenlinie mit Brandung allein im Meer umher.

Ein optisches Problem was wir jetzt natürlich der AROE in die Schuhe schieben.

Das ist aber nicht gerecht. Bei AROE weis man zwar, in welchen Files sich diese Default FS2004 Küstenstreifen mit Brandung aufhalten. Diese hat man auch excludiert. Nur das im FS unter tausenden von Files auch ein Addon File mit Küstenstreifen liegt davon kann man nichts wissen. (zumal ja ein beliebiger Layer durch das Addon verwendet worden sein kann).


Versteht Ihr was ich meine, seht Ihr die Problematik dieser Technik.


Das was da ein Installer leisten müsste ist schlicht und ergreifend fast unmöglich. Selbst wenn er das könnte blieben da immer Konstellationen wo er den Anwender fragen müsste...... Äh Du hast da ein paar kollidierende Files darf ich die deaktivieren oder löschen.

So dann kommen jetzt einige Anwender die mit so einer Frage nichts anfangen können und schon haben haben wir ein Gejammer was ist das denn für ein Scheiss Installer ich weis nicht was ich jetzt machen soll. Kann der das nicht alleine.

Leute Nein er kann es nicht, weil er nicht weis was für euch das beste sein wird. Der eine möchte in SG2 seine Hamburg Scenery erhalten haben, der andere sagt sich soll er ruhig platt machen, dann sind Gewässer und Straßen 100%tig dafür stehen halt ein paar Objekte der Hamburg Scenery falsch.

Wo wäre hier momentan die beste Lösung. Der Installer müsste alles aufzeichnen was er macht und vorfindet. Er müsste den Anwender auf Kollisionen aufmerksam machen. Er muss ihn vor die Wahl stellen was er machen möchte. Damit der Anwender nicht entäuscht ist wäre es ideal wenn er die Installation hier abbricht (sich aber die Stelle merkt wo er ist).

Jetzt generiert er eine Flugsituation lässt den FS an der Problemstelle starten. Der Anwender sieht das Dilemma er bekommt von der Installerroutine eine Abfrage. Gefällt Dir das. Ja oder Nein?

Wenn nein dann zeige ich Dir jetzt mal wie das aussieht wenn ich hier nicht meine AROE Daten einbringe sondern die des Addon A belasse.

Jetzt fährt er mit seiner Installation in der anderen Variante weiter. Er startet wieder den FS und zeigt euch die Situation.

So werdet Ihr dann stundenlang je nach Anzahl der Addons vor dem PC sitzen und die Problemstellen kennenlernen. Prima ist auch gleich ein Supertest für die Scenery.

Hört sich jetzt alles etwas ironisch an. Aber es ist die nackte Wahrheit. Diese Scenerytechnik ist so sensibel hinsichtlich Kollision mit anderen Daten, das diese Variante die einzig logische ist.

Oder aber man vertraut der AROE und sagt die Basisdaten sind so gut dieses soll auch meine Basis werden. Die AROE darf alles was sie stört deaktivieren. Es bliebe jetzt aber immer noch die Problematik das der Installer der AROE alle kollidierenden Fremdaddon Daten unter tausenden von Dateien auf die Schnelle ermitteln muss.


Kommen wir noch mal auf unsere Beispielinstallation zurück:


Addon A hat das Defaultgewässerfile HP950140.BGL nach HP950140.AUS deaktiviert.

Es installiert danach ein neues Gewässerfile mit gleichen Namen HP950140.BGL.

Das Addon A weis was es gemacht hat. Möchte man es Deinstallieren geht alles rückwärts.

Jetzt kommt die AROE und installiert

Sie möchte sich ebenfalls an der HP950140.BGL vergreifen und diese deaktivieren.

Der Installer der AROE findet die Datei, der Installer legt sich nicht auf die Klappe.

Er bemerkt nicht das er eine Addon A Variante HP950140.BGL deaktiviert.

Also deaktiviert er sie nach HP950140.FSQ

Jetzt kommt irgendjemand auf die Idee und möchte Addon A deinstallieren. Der Installer von Addon A ist schlau er weis noch was er gemacht hat.

Er löscht einfach die HP950140.BGL.

und benennt seine HP950140.AUS nach HP950140.BGL um.

Alles klar war das richtig.

Aus der Sicht des Deinstallers von Addon A war das korrekt. Aus der Sicht der AROE natürlich nicht.

Der Deinstaller von Addon A hätte merken müssen das nach ihm seine HP950140.BGL Variante zwischenzeitlich nach HP950140.FSQ gesichert wurde.

Wir sehen wir müssen vom Deinstaller nahezu die selbe Intelligenz verlangen wie von den Installationsroutinen.

Deshalb auch gestern meine Aussage das es fast gehupft wie gesprungen ist wie man installiert. Ein Vorteil für Addon X erkauft man sich immer mit einem Nachteil für Addon Y.

Der sichere Betrieb im FS ist eh nur halbwegs gesichert wenn man sich mit der Materie auseinander setzt.

Sprengstoff ist immer in der Sache auch dann wenn man deinstalliert.

Dieses Dilemma kann man hier aber nicht den Addons zuschreiben es ist nun mal die Technik des FS.

Es dürfte auch nicht so einfach sein das Microsoft so etwas umbiegen könnte.

Eigentlich wollte ich jetzt noch Beispiel B schildern. Also wenn jetzt ein Addon eine Defauldatei umbenennt und keine neue Variante mit identischen Namen mitbringt. Dafür kommt jetzt eine Ersatzvariante mit neune Daten zum Einsatz die in der eigenen Scenery untergrebracht ist. Das wäre z.B das Beispiel Austria Prof.

oder abgewandelt auch Switzerland Prof.

Auch da liegt Brennstoff drin. Es verhält sich nur etwas anders.

Aber dafür reicht meine Zeit nicht mehr.

Aber ich denke die Problematik dürfet rübergekommen sein. Auch die Brisanz die dahinter steckt.

Nicht umsonst macht uns Holger Sandmann vor, dass die beste Lösung die Absprache mit anderen Addon Teams ist.

Man muss aber fairer Weise sagen das das Gebiet der AROE sehr groß ist. Auch wird man von vielen Scenerien überhaupt nichts wissen.

Von daher ist meine persönliche Meinung immer noch umso mehr der Anwender weis umso einfacher ist das für ihn selbst auch mal eingreifen zu können.

Eine Frage noch an Weberknecht die ich jetzt nicht richtig verstehe:

"Hier hätte auch eine "Gefahrlose" Deaktivierung der BGL´s durch Umbenennung nicht geholfen.
(Allerdings erforderlich und im Normalfall auch vom Installer durchgeführt !)

Warum ?

Bei Buochs und anderen tollen Freewareairports von Daniel
einfach aufgrund gemalter Bodentexturen die klarerweise bestehen bleiben."

Wie meinst Du das?

Wenn es sich um handgemalte VTP Straßen z.B über das Tool Ground2K handelt, dann wäre das selbstversändlich auch möglich. Aber ev. meinst Du etwas anderes, deshalb frage ich nach.

"Hier hätte auch eine "Gefahrlose" Deaktivierung der BGL´s durch Umbenennung nicht geholfen.
(Allerdings erforderlich und im Normalfall auch vom Installer durchgeführt !)

Warum ?

Wie Du schon geschildert hast gibt es mit dem Installer einige Probleme.
So gab es z.B. für die Schweiz einige Files die deaktiviert werden sollten es aber nicht geschah.
Also sowohl als *.FSQ vorhanden waren aber "auch" noch als BGL-File.
Das ARoE hier keine neuen erzeugt wußte ich aus vorherigen Versuchs- Installationen.
Holt man die Deaktivierung händisch nach ist das Problem
(doppelte Darstellung von Flüssen, Strassen)auch keines mehr.


Bei Buochs und anderen tollen Freewareairports von Daniel
einfach aufgrund gemalter Bodentexturen die klarerweise bestehen bleiben."

Wie meinst Du das?

Hier wunderten sich viele warum doch noch gelegentlich Reste
doppelter Strassen, Flüsse bestehen bleiben.
Sieht ja aus wie Default ist es aber nicht.

Nun. Im Fall Buochs wäre das die LSMUgrd_9.bgl und LSMUrtex.bgl .
Doppelte Strasse wie auch Flusslauf wie auf meinen Bildern zu sehen
sind in diesen Files enthalten.
Bei einigen Airports wurde so die nähere Umgebung korrigiert.
Auf jeden Fall handgemalt und Bestand des Airports.
Durch entfernen der "nunmehr" überflüssigen BGL´s ist alles Bestens.

Bei Bad Ragaz gibt es ein anderes Problemchen..
Der Fluss im Fluss kommt aus der Österreichischen Scenerie.

Quasi eine unverzollte Grenzüberschreitung ;)
Entfernt man die zuständige atstl.bgl aus AP2004 wird dies
zwar behoben mitunter aber auch einige Flüsschen.. :rolleyes:

Was zu ARoE noch fehlen würde wäre ein FlussAddon für Europa
um die kleinen Flüsse zu ersetzen die man deaktivieren mußte :lol:

Dieser Satz von mir war fehlerhaft

"Da haben wir es doch. Wenn Dir .FSQ Dateien fehlen, dann ist es auch nicht verwunderlich wenn Dir Straßen fehlen."

Muss natürlich heissen nicht verwunderlich wenn doppelte Straßen existieren.

Zu Weberknecht muss jetzt weg lese das aber später noch mal genau

Bitte sag/schreib Mani

(für Manfred ,
aber da es bei uns bei BushPilots zwei STück Manfred gibt
und Verwechslungen auszuschließen kurz Mani)

Sonst schreib ich auch Jobia äh Jobi ;)

Hallo Jobia!

Deine Erklärung warum der Installer manche Datien nicht ersetzt hat, ist mir schon klar. Unklar bleibt mir allerdings, warum bei drei Installationen unter derselben Voraussetzung der Installer zwei mal die Dateien nicht umbenannt hat, einmal aber schon!

Wie gesagt: ich habe auch keine Probleme mehr mit den ARoE bis auf die von Mani angesprochenen Eingriffe durch Daniel´s Flugplätze. Die lassen sich aber sicherlich noch beheben.

Für mich ist und bleibt ARoE eines der wichtigsten und besten Addons für den FS9.1!

Vielen Dank für Deine Hilfe (immer wieder, nicht nur hier)!!!!

Viele Grüße
Andi

Eingriffe sind das keine was Daniels Flugplätze machen ;)

Und ohne ARoE hätte niemand diese Darstellungsmethode/Lösung
der harmonischen Scenerieanpassung bemerkt.

Jetzt betrachtet nicht die beste Lösung aber toll gemacht.

Und wer konnte schon ahnen das die Umstellung auf Realdaten
so rasch passieren würde.

Trotzdem "endlich" !
Eine bessere Norm für alle als Realdaten gibt es wohl nicht.
ARoE hat da glücklicherweise einen Stein ins Rollen gebracht.

Zu Andi


Drei Installationen unter selben Vorraussetzungen mit verschiedenen Ergebnissen, dass ist in der Tat nicht normal.




Was ich zu meinen LOG Files sagen muss, die basieren auf Cleensweep.

Offensichtlich ist dieses LOG File nicht komplett. Cleensweep scheint Probleme zu haben wenn irgendwelche Dateien nicht kopiert sondern während des Installationsvorganges editiert werden.

Wie gesagt ich finde mehr deaktivierte .FSQ Dateien in z.B der EURW Scenery als im LOG File gelistet sind.

Die Schweiz ist bei mnir im Prinzip komplett durch die AROE deaktiviert worden. Im LOG File fehlen ein paar .FSQ Files für die Schweiz.





Zu Mani


"Nun. Im Fall Buochs wäre das die LSMUgrd_9.bgl und LSMUrtex.bgl .
Doppelte Strasse wie auch Flusslauf wie auf meinen Bildern zu sehen
sind in diesen Files enthalten.
Bei einigen Airports wurde so die nähere Umgebung korrigiert.
Auf jeden Fall handgemalt und Bestand des Airports.
Durch entfernen der "nunmehr" überflüssigen BGL´s ist alles Bestens".



bin ich anhand Deiner ersten Schreibweise zunächst davon ausgegangen, dass Du das so gemeint hast diese Daten lassen sich generell nicht deaktivieren.


Du meintest (das wird aus obigen Satz jetzt auch klarer) die allgemeine Problematik bei Addons. Der Installer bzw. das AROE Team kennt diese Daten nicht und kann sie folglich auch nicht deaktivieren.




Zu dieser Geschichte.


"So gab es z.B. für die Schweiz einige Files die deaktiviert werden sollten es aber nicht geschah.
Also sowohl als *.FSQ vorhanden waren aber "auch" noch als BGL-File."

Auch ich habe ein paar Files wo das zunächst so aussieht. Es existiert ein gesichertes File mit Endung .FSQ aber dennoch ein identisches File mit Endung .BGL


Genau diesen Effekt meinst Du. Ob es ein Fehler ist muss ich mal schauen. Aber bei mir ist es so.

Das File welches zunächst wie ein unkorrekt vorhandenes Defaultfile aussieht, hat bei mir zwar die selbe Datengröße wie das wahre Defaultfile trägt bei mir aber ein aktuelleres Datum.

Es sind aber ein paar Bytes anders von daher muss es nicht unbedingt ein Fehler sein.

So könnte man z.B bei einem LWM Gewässerfile mittels ein paar geänderter Bytes aus einem Fluss Landmasse machen. Das File hätte exakt die selbe Größe hat aber eine ganz andere Funktion.

Von daher kann dieses was Du jetzt ev. als Fehler erkennst sogar korrekt sein.

Um dazu genaueres zu sagen, muss ich mir die Files anschauen.