doppelte Küstenlinien in Slo/Cro
 

hallo,

ich habe, trotz deaktivierter Aroe und abgeschalteten Küstenlinien in UT Europe doppelte Küstenlinien (siehe Anhang). Falls jemand das gleiche Problem hatte oder es hier schon mal gepostet wurde (habe leider nichts gefunden), bitte ich ihn um Hilfe.

mfg Kai

Moin Kai,

trotz Deaktivierung von AROE kann das vorkommen. Denn AROE ändert auch Dateien in der StandardScenerie, und ich kann mir nicht vorstellen, dass die bei Deaktivierung zurück gesetzt werden.

Hi
das habe ich auch festgestellt. Bei blosser Deaktivierung von AROE sind die Kuestenlinien ein Chaos. Ich habe es gluecklicherweise geschafft ohne Probleme AROE wieder von meinem System herunterzuschmeissen.
D.h. wenn du bei der Instal. von Kroatien/Slovenia die AROE angegeben hast, oder eben nicht, aber AROE drauf hast, kann das evtl passieren.
Viel Glueck beim rumtuefteln.

Es werden irgendwo 2 cstl.bgl aktiv sein.

Ob sie nun genau cstl.bgl oder costl.bgl heißen - das kann ich dir nun nicht sagen. aber in der Richtung wird es wohl schon so sein.

Hallo Kai,

Hatte ich auch - bei mir hat's geholfen, ARoE (aktiviert) in der Priorität weiter nach unten zu setzen (jedenfalls unterhalb Slo/Cro).

Fritz

Wenn jemand einen Screenshot mit Koordinaten anhängt (strg +Z), kann ich nachsehen auf meinem System!
Ich habe nur FS 9.1 und kein Addon, außer Slo/Cro installiert. Und AROE und UT habe ich nicht.

In Slo/Cro werden nur FS originale HP und FL Daten ersetzt, also keine HL Daten (Uferlinien).
HL braucht man auch nicht (hat keinen Einfluss auf terrain.cfg offset), da man einfach den Layer 8 excludiert, bzw. die Daten in diesen Layer legt (müsste ich nachsehen)

D.h.:
a) Bei euch ist ein Addon mit Uferlinien (anderer Layer als 8 aktiv) – Grenzgebiet? (Aroe und UT decken den Bereich doch nicht ab, oder?)
b) In Slo/cro stimmt der Exclude nicht

Horst

Ich habe alles neuinstalieren muessen und bin nun sehr froh ARoE endlich los zu sein.

Zwar ein paar Strassen weniger aber dafuer keine doppelten und keine
mitten im Wasser.

Und alle Kuesten sind wieder so wie sie waren.

Keine "Riffs" im Mittelmeer, keine Feuchtbiotope rund um den Flughafen auf La Palma mm.

Die Arbeit hat sich gelohnt!

Janne

P.S.
der zehnte der mir eine Dose Bier schickt bekommt ARoE portofrei
nach Hause geschickt!

@Janne
Hat dies etwas mit der Frage zu tun?
Hast du dieses Addon?

Also wenn der Autor (oder die beiden in Slo/Cro) in diesen Fall ihre eigenen Daten nicht abstimmen können zu AROE, wäre es wirklich traurig.

Horst

hallo Horst,

hier ein Screenshot mit Koordinaten. Soweit ich weiß, deckt Aroe das ab und für UT gab es eine "Osterweiterung".

mfg Kai

Wie immer trägt natürlich AROE die schuld, dass kennen wir ja schon.

Hat man es geschafft sein AROE los zu werden, hat man das Problem natürlich nicht.


Kurios!

Warum?

War es nicht so, dass bei AROE kritisiert wurde, dass hier die Landinformationen im Gegensatz zum Default FS ohne jegliche Uferlinien, Küstenlinie mit Brandung (im VTP Liniencode) auf die Gewässerinformation stösst.

Ein Manko was mich optisch auch etwas stört.


Nur..... wenn AROE überhaupt keine eigenen Küstenlinien in VTP Liniencode mit sich bringt, dann kann es sich hier ja wohl schlecht um eine nun störende AROE VTP Küstenlinie mit Brandung handeln.

Diese doppelte Küstenlinie muss also eine FS Default oder anderweitige Küstenlinie sein.

Ich finde es schon übel, dass man immer AROE alles in die Schuhe schiebt.

Das alle VTP und LWM Codes kritisch sind, speziell wenn sich mehrere Addons daran vergreifen haben wir schon in etlichen Threads erklärt.


Ich möchte nicht wissen bei wie vielen AROE überhaupt nicht der wahre Problemverursacher ist, sondern anderer Addons die vor oder nach AROE installiert wurden.

Viele Gründe dürften nämlich daran liegen, dass der Anwender vorher schon sein Scenerychaos nicht im Griff hatte, welches anderweitige Addons angestellt hatten.

Was das Bild betrifft, kann es sich aufgrund der recht langweilig verlaufenden Küstenlinie eigentlich nur um die noch existierende Defaultküstenlinie oder um die eines Addon mit sehr schlechten Daten handeln.

Im Anhang mal diese Stelle bei mir im FS (default LC aktiv)

Bei mir ist AROE installiert (richtig installiert)

Wie man sieht ist hier aber nichts mit AROE.

Man kann bei mir eindeutig die default FS Küste sehen.

Diese default Küstenlinie ist mit der von Kai identisch.

Also dürfte klar sein, was wir bei ihm sehen.

Da Horst schreibt:

"In Slo/Cro werden nur FS originale HP und FL Daten ersetzt, also keine HL Daten (Uferlinien).
HL braucht man auch nicht (hat keinen Einfluss auf terrain.cfg offset), da man einfach den Layer 8 excludiert, bzw. die Daten in diesen Layer legt (müsste ich nachsehen)"

Ich habe SloCro nicht, aber wenn man keine original HL Daten ersetzt, dann bleibt nur die Excludierung per eigenen Excludefile übrig, oder eben, dass die Excludierung des Layers direkt im neuen Küsten/Uferliniencode integriert ist.

Letzteres kann aber nicht der Fall sein, da wir eine neue Küstenliniendefinition sehen ( SloCro / UT ?) und die Default trotzdem noch aktiv ist.

Es muss also ein neuer Küstenlinien /Ufer VTP Code aktiv sein, der entweder kein Exclude für die Default VTP Küste enthält ( Bit nicht gesetzt) oder der durch einen Fehler einen falschen Layer excludiert.

Es kann natürlich sein, dass Slo/Cro auch reinrassige Excludefiles nutzt, dass konnte Horst hier gestern noch nicht genau aussagen.

Sollte das so sein, dann trifft Horst sein Fall b) zu.




"D.h.:
b) In Slo/cro stimmt der Exclude nicht"

Denkbar wäre auch noch ein anderes Addon bei dem man ein Defaultfile hinsichtlich Code geändert hat.

Sprich man hat hier seine Änderung eingearbeitet und Teile des Codes im Defaultzustand belassen.

So habe mal nachgeschaut.

Es handelt sich hierbei tatsächlich um ein Addon File welches ein manipuliertes Defaultküstenlinienfile in den FS einspielt.

Das File trägt den Namen HL952160.bgl und findet sich in der EURW Scenery also Westeuropa.


Dort findet sich zusätzlich zu diesem aktiven manipulierten Defaultfile auch eine Sicherung des original Defaultfiles. Es trägt den Namen HL952160.FSQ


Also eindeutig eine Manipulation der AROE.

Warum dieses File?

Man hat aus dem Defaultfile einen Bereich der Küste bei N42° E15° entfernt.


Also sehr weit weg von unserer hier gezeigten Problemstelle.

An unserer Problemstelle sehen wir also den Defaultküstenverlauf des manipulierten AROE Default Files.

Im Code trägt dieser Küstenlinienverlauf aber auch Layer 8.

Das bedeutet, dass AROE hier keine Schuld trägt, denn auch mit Default Scenery wird man diesen Fehler haben müssen.

Die Frage ist ob andere an exakt der Stelle des zweiten Screenshots das Problem auch haben.

Wenn nicht, was kann also passiert sein.

Entweder Slo/Cro muss default Küsten Files deaktivieren um sie los zu werden.

Dagegen spricht Horst seine Aussage, dass SloCro mit Excludes arbeitet.

Also kommt aus meiner Sicht nur folgendes in Frage.

1)
Es existiert noch ein anderes Addon welches ebenfalls wie AROE eine manipulierte teilweise original Küsten einspielt. Dieses File muss nicht unbedingt einen Defaultnamen haben es muss auch nicht im FS Defaultpfad EURW sein. Dieses File könnte einen anderen Layer nutzen.

2)
Keine Ahnung wie sich SloCro Installiert... nur mit einer Scenery oder mehreren in der Scenery Bibliothek. Ev. ist hier die SloCro bei Dir in der Scenery Bibliothek zu niedrig angemeldet.

3) Wenn SloCro Einzel Excludes nutzen sollte, dass aufgrund eines Fehlers dieses Excludefile nicht installiert wurde.

4) Ein Fehler im Excludebefehl selbst, also das ein falscher Layer excludiert wird schliesse ich aus, denn dann müsste jeder das Prob haben.



Ev. helfen diese Informationen Horst der die Scenery hat und sich mit auskennt zur Fehlereingrenzung weiter.

Dir würde ich einfach mal zum testen empfehlen in der Default EURW Scenery des FS das File HL952160.bgl nach
HL952160.KAI umzubenennen. Dann die zugehörige Scenery.dat zu löschen.

Nach FS Neustart die selbe Stelle noch mal betrachten.

Sollte die Küstenlinie dann weg sein, dann war es vorher ein Excludeproblem.

Ist sie immer noch da, dann existiert noch ein weiteres störendes Addon File im FS welches ebenfalls Defaultküstenlinienfragmente enthält.

Ev. gar UT, wozu ich nichts sagen kann, da ich es nicht habe.


Kannst ja mal schauen ev. gibt es weitere veräterische Sicherungen des Files HL952160.bgl wie z.B HL952160.OFF oder ähnlich die ein Anhaltspunkt wären, dass sich mehrere Addons hier dran vergriffen haben.

UTE ist es auch nicht. In diesem Gebiet sind die Küstenlinien von MS und UTE deckungsgleich. Ich habe die entsprechenden Unterlagen an Jobia gemailt.
SloCro habe ich nicht und AROE nicht mehr u.a. wegen LWM-Fehlern. Damit ist der Verdacht, daß wieder mal AROE schuld ist, zwar verständlich, aber unwahrscheinlich wenn es zwei Küstenlinien gibt.
Also liegt der Fehler bei SloCro oder beim User, der durch mehrere Installationen und Deinstallationen die falschen Sicherheitskopien wieder hergestellt hat. Wenn Dateien in EurW durch AddOns überschrieben werden, ist das sehr wahrscheinlich. Hier ist aber der User verantwortlich und nicht die AddOn-Entwickler.

Ähnliche Fehler werden im großen Maße auch mit AF2.BGL gemacht ("Hilfe, meine Flieger hängen inder Luft"). Das zeigt, das vieler User mit den Addons überfordert werden.

Uwe

Kai ein guter Screenshot jetzt.

Dies sind die normalen MS HL Daten (Uferlinien)

Sie werden bei diesem Addon mit der Datei _X8.bgl (Name nehme ich an: Exclude Layer 8) entfernt.
Siehe Anhang!
Hast du diese Daten in diesem Ordner?
Bei mir funktioniert es ordnungsgemäß.
Das Addon hat hier keinen Fehler!

Der Ordner ist aktiv bei dir, sonst würde ich nicht die Addon Uferlinien sehen c1coast.bgl (Layer 14 und Texture 1027)
(Siehe auch deinen Screenshot links unten: default liegt unterhalb von Addon Linie (= Layerpriorität)

Wenn du _X8.bgl hast, dann scheint nur Joachims Idee möglich:
"Denkbar wäre auch noch ein anderes Addon bei dem man ein Defaultfile hinsichtlich Code geändert hat." (anderer Layer)

(meine orig HL ist datiert mit 22.05.2003, wie alle anderen)

siehe deinen Beitrag hier:
http://www.wcm.at/forum/showthread.php?threadid=194837
Du hast noch etliche andere Daten aktiv!
Du siehst z.B den Slo/Cro Dubrovnik Airport nicht.

Schreib halt was du gemacht hast, vielleicht hilft es ja jemanden.

Horst

Zu


Danke habe die Mail erhalten. Habe leider die Mail schon von zu Hause aus dem Postfach abgeholt ohne sie zu lesen. Bin jetzt nicht zu Hause und komme daher an die Mail nicht mehr dran.

Weis jetzt also nicht wie die Umsetzung bei UT bezüglich Deiner Aussage


"Küstenlinien von MS und UTE sind hier deckungsgleich) durchgeführt wurde.

Hat man bei UT in FS Defaultpfaden etwas geändert also in der EURW?

Wenn ja hat man ein neues File mit Default oder eigenen Namen eingespielt?



Hat man z.B eines eingespielt, welches im wesentlichen Defaultcode gemischt mit eigenen nun in einem anderen Layer als 8 enthält, dann greift dort natürlich das SloCro Exclude nicht mehr.

Folglich sieht man eine UT Küste die auf Default Daten basiert. Wenn nicht, könnte folgende Variante vorliegen.

UT deaktiviert das FS Defaultfile HL952160.bgl welches natürlich mittlerweile auch eine AROE Variante sein könnte.

Ok egal in EURW wäre jetzt kein Code mehr für diese Küste enthalten.

UT könnte jetzt ein neues File in einer eigenen Scenery unterbringen. Ist die höher als SloCro angemeldet greift ebenfalls das SloCro Exclude nicht.

Nun bin ich ja nicht der einzige der theoretische Fehlermöglichkeiten gepostet hat. Ich denke einige werden bemerken AROE hin oder her, es ist ein ganz heikles Thema bei dem viele Addons zu Problemen beitragen können.

Hätte ich das Problem inkl. Scenerien auf dem eigenen PC hätte sich das mit Sicherheit unterhalb 5 Minuten erledigt.

So ohne SloCro ist es etwas Stocherei.

Ich habe mir überlegt, dass es am sinnvollsten wäre zunächst die Westeuropa Scenery abzumelden. Wenn dann das Problem nach FS Neustart immer noch existiert, wissen wir wenigstens von welcher Scenery das Problem nicht kommt.

Dann könnte Kai seine Scenery.cfg darüber aufklären ob es ein Prio Prob ist, oder ob wir etwas genauer in seine EURW schauen müssen.

Hallo Joachim,

UTE deaktiviert HL952160.bgl durch umbenennen in HL952160.XXX

Eine neue Datei wird dabei nicht in das Eurw Verzeichnis eingespielt, da UTE in seinen eigenen Verzeichnissen bleibt und außer deaktivieren nichts in default FS-Verzeichnissen unternimmt.


Viele Grüße,
Michael

Bin jetzt zu Hause und habe mir Uwe seine Mail angeschaut.

UT geht hier bei dem problematischen File nahezu zu 100% identisch wie AROE vor.

Es wird wie bei AROE auch das VTP FS Default Küstenlinienfile HL952160.bgl überarbeitet und als eigene Version eingespielt.

Es bleibt bei AROE und UT im gezeigten Problembereich alles wie im Defaultfile erhalten. Nur wie bei AROE wird im Bereich N42° E15° etwas vom Code entfernt.

Man könnte quasi das AROE und UT File überlagern. Beide sind von dem was sie noch definieren identisch.

Auch beim UT File bleibt der Layer 8 für diese Küsten erhalten.

Wenn die Priorität stimmt, kann es kein Excludeproblem sein. Es sei denn es mischt sich noch ein drittes Addon ein, welches sich an diesem Default File vergreift.... was wir natürlich nicht hoffen wollen.

Von daher ist hier UT im Prinzip keinen deut besser als AROE.

Wenn ich mir Uwe seinen Screenshot mit dem Pfad dieses UT Files anschaue, dann gibt es zumindest bei ihm einen Unterschied.

UT deaktiviert wie auch AROE das Defaultfile HL952160.bgl durch umbenennen. AROE nennt es HL952160.FSQ und spielt als Ersatz ein eigenes manipuliertes unter Defaultnamen HL952160.bgl in die Default EURW ein.

UT benennt das Defaultfile HL952160.bgl (könnte anstatt dem defaultfile aber auch schon die AROE Variante sein) wenn Uwes Daten dem Standardverfahren von UT entspricht nach HL952160.XXX um.





UT spielt seine HL952160.bgl Ersatz Version übrigens nicht in den Default EURW Pfad ein. Man kopiert seine eigene Version unter Defaultnamen HL952160.bgl in eine eigene Scenery in einen Pfad mit Namen UTEUR4 ein.

Man kann es nehmen wie mal will beide Varianten AROE und UT sind kritisch. UT legt für ein später folgendes Addon welches nicht über einen sehr intelligenten Installer verfügt sogar größere Stolperfallen als AROE.

Ich denke UT profitiert auch davon, dass es erst nach vielen anderen Addons mit solchen Codes installiert wurde.

Egal. Auf jeden Fall ist dieses neue UT File mit Defaultküstencode der stört in einer eigenen Scenery untergebracht.

Bei Uwe ist sie in einem Pfad der den Namen UTEUR4 enthält.

Man müsste jetzt nachschauen mit welchem Namen dieses Pfadfragment in der Scenerybibliothek angemeldet ist. Das kann man über die Scenerybibliothek ermitteln.

oder aber man schaut in die Scenery.cfg.

Sollte nämlich diese UTEUR4 höher als die SloCro angemeldet sein, dann kann der Excludecode von SloCro nicht greifen. Ergo sehen wir eine unpassende Küstenlinie von UT die dem Default FS Verlauf entspricht.

Damit es für Kai nicht kompliziert wird bitte zunächst mal alle UT Scenery/Scenerien in der Scenery Bibliothek deaktivieren.

FS neu starten.

Ist der Bug dann weg, ist es ein UT Prioritätsproblem, welches man schnell in den Griff bekommt.

(Bitte dann mal hier im Forum Deine Scenery.cfg als Textfile anhängen. Kannst es mir auch als Mail schicken.)

Besteht das Problem weiterhin, dann bitte die Westeuropa abmelden.

FS neu starten.

Ist es erst jetzt weg, dann schlummert irgendwo in der Default EURW noch ein drittes störendes File.
Existiert es immer noch, dann gibt es störendes Addonfile auf Defaultbasisdaten, welches sich in einer ganz anderen Addon Scenery versteckt.

Hallo Michael wir haben wohl nahezu zeitgleich geschrieben. Nur das ich nebenher noch Uwes Mail ausgewertet habe.

Aber es schent sich ja zu decken. Unter welchen Pfad Namen findet sich denn bei Dir das UT HL952160.bgl?

Auch unter UTEUR4 ?


Unter welchen Namen ist dieser Pfad in der Scenerybibliothek angemeldet..

Das würde es für Kai einfacher machen, denn dann weis er gleich was er zum testen abschalten muss.

Hat UT noch andere Scenerybibliothekseinträge?

hallo Jobia, Horst und alle anderen,

vielen Dank, wie ihr euch in mein Problem reinkniet! Ganz toll, ehrlich. Dank euerer Posts habe ich das Problem gelöst. Ich habe Slo/Cro jetzt über UT gesetzt und die Küstenlinien sind 1a. Ich werde da wohl nie richtig hinter die Materie steigen. Vor einer Weile, als UTE noch relativ neu war, gab es so ungefähre Richtlinien. Da sollte UT recht weit oben, aber unter den Photoszenerien stehen. Reine Airportszenerien sollten demnach wohl unter UT sein, aber Sachen mit Straßen und Küstenlinien dann wohl darüber, oder? Jobia, ich hänge mal meine Szenerie.cfg an. Vielleicht findest du noch andere Umgereimtheiten. Die Bäume auf dem Vorfeld und den Taxiways sind leider immer noch da, siehe Anhang. Jetzt gehe ich erst mal ins Bett (Nachtschicht die Woche). Nochmals vielen Dank an euch!

mfg Kai

hier die Bäume.

MS hat Airport background polys (Wiese ohne Autogen) mit Layer 7 unter den Flugplätzen.
Evtl. hat man im AddOn vergessen dieses Poly zu verändern.
Einfach ein neues Poly malen. In gleichen Lods ist dann auch das alte Poly gelöscht.
Oder Exclude.BGL basteln, das sind dann aber ein oder mehrere Rechtecke.
Uwe

Hallo Joachim,

ja, es ist UTEUR4


Das sind alle UTE Einträge aus meiner Scenery.cfg. Bei den Namen (Title) bin mir allerdings nicht sicher, es kann sein, daß ich die umbenannt habe:

[Area.021]
Title=Ultimate Terrain - Eastern Europe
Active=TRUE
Layer=21
Local=SCENERY\UTEUREE

[Area.022]
Title=Ultimate Terrain - Europe 1
Active=TRUE
Layer=22
Local=SCENERY\UTEUR1

[Area.023]
Title=Ultimate Terrain - Europe 2
Active=TRUE
Layer=23
Local=SCENERY\UTEUR2

[Area.024]
Title=Ultimate Terrain - Europe 3
Active=TRUE
Layer=24
Local=SCENERY\UTEUR3

[Area.025]
Title=Ultimate Terrain - Europe 4
Active=TRUE
Layer=25
Local=SCENERY\UTEUR4

[Area.026]
Title=Ultimate Terrain - Europe 5
Active=TRUE
Layer=26
Local=SCENERY\UTEUR5

[Area.027]
Title=Ultimate Terrain - Europe 6
Active=TRUE
Layer=27
Local=SCENERY\UTEUR6

[Area.028]
Title=Ultimate Terrain - Europe Lights
Active=TRUE
Layer=28
Local=SCENERY\UTEURLT

[Area.029]
Title=Ultimate Terrain - Europe City Landclass
Active=TRUE
Layer=29
Local=SCENERY\UTEurCity

[Area.030]
Title=Ultimate Terrain - Ind/Comm Landclass
Active=FALSE
Layer=30
Local=SCENERY\UTEURLC


Die Priorität aller UTE Szenerien ist bei mir sehr niedrig, so ziemlich unter allen Addons und auch unterhalb der standard FS-Photoszenerien.


Viele Grüße,
Michael

Kai, du "trickst" dich selber aus, bei den Bäumen!
Und ist kein Fehler des Addons!

Die Reihenfolge der Priorität sollte so sein:
Siehe Anhang!

Die Erklärung dazu:
Bei dir hat, laut deiner angehängten scenery cfg, Coastal (Layer 374), NonCoastal (Layer373) Priorität gegenüber Adriaairports (Layer 332).
Wäre ähnlich, wenn ich bei mir Adriaairports von "Platz"2 auf z.B "Platz" 6 oder 7 "runter" verschiebe.
"Platz" 1 hat immer die höchste Layernummer in deiner scenery.cfg.

Der Airporthintergrund in LDDU ist Fotoszenerie (also auch Landclass), gesteuert durch die Datei LDDUbo_su.bgl, mit Bitmaps und agn (Autogen).
Wenn du die Priorität nicht einhaltest, überschreibt das Noncoastal Landclass file das Airport LC und du siehst das Autogen der Noncoastal.
Und dies ist nicht angepasst und es gibt auch keine aktive Datei (eben Airport LC) die die Vegetation vernichtet.
Denn AF2 vernichtet kein Autogen, sondern AB und dies gibt es nicht.

Oder du hast noch anderes LC in der Gegend. Denke ich aber nicht, da ich ebenfalls nur diese beiden Bäume sehe, wenn ich die Priorität verschiebe.

So sieht es bei mir aus. Keine Bäume
Siehe Anhang2

Also in beiden Fällen (UT und Bäume (LC)) die Priorität beachten.

(Auch bei deinen mesh files (DEM). Globale Files (Abdeckung) sollten hohe Priorität haben, gegenüber anderen kleineren DEM mit dem selben LOD.
Hier ist dies aber kein Problem , da das Slo/Cro file LOD 10 ist.
Ein gutes Werkzeug bei deinen vielen Addons wäre auch Jim Keirs LWMViewer2:
http://www.jimkeir.co.uk/FlightSim/LWMViewer2.html
Um die Übersicht zu behalten ;) )

Horst

@ rolfuwe
Hat man nicht und braucht man nicht.
Deshalb passt es (Verblendung) auch sehr schön zu den Slo/cro LC Texturen.
Siehe Anhang3

Anhang 2

Anhang 3

hatte etwas vorgeschrieben ist natürlich nicht ganz aktuell zu den letzten Postings.

hier die beiden Texte.

Sehr schön, dass wir Dir helfen konnten. Wer hätte das gedacht, dass hier UT das Problem ist. Denn zuvor wurde ja geäußert UT kann hier nicht das Problem sein.

UT wird immer sehr gern eine weiße Weste zugeschrieben. Ich denke, dass es des öfteren hin und wieder ein Problem sein wird, welches dann natürlich zuerst ev. einem vorhandenen AROE bzw. dessen früherer Installation zugeschrieben wird.

Nun UT bietet mehr fürs Geld als AROE ganz klar. Auch hat man mit den USA Scenerien genug Erfahrung gesammelt um Fehler hier in Europa erst gar nicht zu begehen. (AROE hat hier in Europa den Vorreiter gespielt. Was an Fehlern passieren konnte, hat sich bei uns dann natürlich gleich eingeprägt)

Auch ist man immer bei UT sehr viel intensiver auf andere bekannte Addons eingegangen.

Alles Vorteile von UT.

Der Straßencode (ich kann hinsichtlich UT nur Bilder beurteilen) gefällt mir bei AROE dennoch besser.

Bei AROE hat man sich so manches Eigentor geschossen. z.B da man rigoros alles was in den NAVTEQ Rohdaten als Meer Gewässer definiert ist auch in FS Gewässer umgesetzt hat. Ist für die Fahrzeugnavigation natürlich nicht störend. Im FS allerdings schon, da man hiermit nun so manche Insel die nicht zum AROE Bereich gehört platt gemacht hat. Man hat schlicht und ergreifend seine Daten vor Veröffentlichung nicht ausreichend kontrolliert.

Dann hatte der Installer Probleme auf manipulierte Defaultfiles zu reagieren. Sehr viele Addon Installer werden allerdings solche Probleme haben. Da diese Scenerien kleinflächiger sind fällt dieses nicht sofort auf.

Bezüglich Installer hatte Guido (FSQuality) damals gesagt, dass wäre ja auch nicht fair, wenn andere Addons einfach Defaultdaten durch umbenennen deaktivieren. Logisch das der AROE Installer dann Probleme hat wenn er diese vorausgesetzten Defaultdaten nicht findet und nun darüber stolpert. Böse andere Addons.

Nur hierbei muss man sich natürlich immer an die eigene Nase fassen. Denn AROE geht exakt genau so vor, es benennt auch Defaultdaten um, die später andere Addon Installer ev. voraussetzen. Hier erzeugt AROE genau wie viele andere Addons das Problem, welches man anderen nicht zugesteht.

Trotzdem bleibt für mich AROE ein gutes Addon, welches man leider nur dann vernünftig in den Griff bekommt, wenn man sich mit der FS Technik auskennt.


An alle AROE Kritisierer.

Unabhängig von den oben genannten AROE Problemen sehen wir hier wie kritisch diese Scenerytechniken sind, ich erwähnte das früher schon.

Wir sehen hier nämlich das UT nicht unbedingt besser ist. Dieser Thread ist ein schönes Beispiel, dass es exakt die selben Probleme verursacht, wenn es auf Code gleichen Types stösst.

Alles ist eine Frage der Installationsreihenfolge bzw. wie der Anwender seine Addons in der Scenerybibliothek anmeldet hat.

Liegt da eine ungünstige Konstellation vor, hat man sofort ein Problem.

UT hat wie gesagt einen entscheidenden Vorteil, es kam nachdem fast alle anderen Flächen Addons auf den Markt waren.

Und wie wir sehen, sobald jemand mit Straßen oder Küsten Problemen hat, weiterhin Besitzer von AROE oder sogar noch UT ist, dann ist immer sofort AROE der Bösewicht der für das Chaos zuständig ist.

Möchte nicht wissen wie oft AROE ungerechter Weise für Probleme angeklagt wurde.

Aber egal, es ist kaputt geredet. Dadurch, dass man von sich aus bei AROE nicht ausreichend versucht hat nachträglich Kompatibilität zu anderen Addons herzustellen, ist der AROE Zug eh abgefahren.


Gott sei Dank sieht es danach aus, dass der FSX auch in Europa ein so gutes Straßen und Gewässernetz per Default mit sich bringt, dass solche Addons wie AROE, UT, Terrain Sceneryanteile der SG Serie dort überflüssig sein könnten.

Wer weis, könnte sogar sein, dass auch das erweiterte Landclass/Waterclassystem und das Mesh des FSX so gut ist, dass man nicht mehr solche Daten als Addon benötigt.

Dann wären mit einem Schlag solche Probleme verschwunden. Hoffen wir darauf.

Was Deine Probleme mit den Bäumen auf Taxiways usw. betrifft.

Ich hatte vor ein paar Monaten exakt so ein Problem und dessen Verursachung bei einem anderen Forenteilnehmer aufgelöst.

Hier war ein österreichischer Default Airport betroffen. Der Anwender nutze zusätzlich eines der beiden Austrian Airports Addon Produkte.

Was sollte man zu diesem Problem wissen.

Fast immer handelt es sich bei diesen störenden Bewuchs um Autogenbewuchs. Hin und wieder finden sich gar Autogengebäude auf Taxiways.

Das Problem was man sieht hängt davon ab, was über das aktive Landclassfile dort definiert wird.

Prinzipiell wäre jeder Default Airport von dem Problem betroffen wenn unter ihm eine Landclass aktiv ist die Autogen definiert, da man im FS2004 auf spezielle Autogen Excludefiles verzichtet hat.

Wie wird ohne spezielle Excludefiles verhindert, dass man Autogen sieht.

Nun indem man ein spezielles VTP Rasenpolygon erzeugt. Im FS2002 eines welches eine Landclass zuweist für Rasen, welcher kein Autogen enthält.

Im FS2004 eines mit einer MaskClassMap Funktion. Die benötigte Autogenexcludierung erfolgt über die zugehörige MaskClassMap Funktionszeile in der terrain.cfg.

Hört sich alles etwas kompliziert an, ist auch nicht so wichtig.

Wichtig ist, dass man weis, dass in der Regel nur dieses """"Default VTP Rasen / MaskClassMap Poly"""" dafür sorgt, dass Autogen excludiert wird.

Wir hören die Bezeichnung VTP (Vector Terrain Polygon) dieses VTP hatten wir auch schon bei Deiner Problemküste. Die ist nämlich auch in VTP Technik.

Diese VTP Geschichte verwaltet der FS optisch in einem Schichtensystem (Layer) Eine Schicht in einem höheren Layer kann eine in einem niederen Layer optisch überdecken.

Im Prinzip so als wenn man Klarsichtfolien (unsere Schichten) mit gezeichneten Küstenlinien, Straßen, Eisenbahnen übereinanderlegt.


Möchte man so eine Schicht optisch entfernen, dann muss man deren Schichtnummer kennen. Die Entfernung erfolgt über einen VTP Layer Exclude.

Genau so ein VTP Layer Exclude kann jetzt das Autogen Problem auslösen.

Beispiel des oben erwähnten Thread.

Der Anwender hatte dort in Österreich nur eine der beiden AA Versionen in Betrieb. In beiden AA Versionen schlummert allerdings ein Bug. Man hat in beiden Versionen AA1 und AA2 VTP Layerexcludes für alle AA Airports untergebracht. Man exludiert quasi auch die VTP Rasenpolys der AA Version die der Anwender ev. überhaupt nicht besitzt. Man raubt dann österreichischen Default Airports seine
VTP Rasenpolys. Da diese natürlich zusätzlich für das Excludieren des Autogen zuständig sind, taucht jetzt durch das fehlen Autogen auf.

Was könnte jetzt bei Dir in Frage kommen.

Fall 1. Die SloCro ist nicht korrekt installiert, ev. hat die SLOCRO ein VTP Exclude was Autogen im Airport sichtbar macht, aber im Gegenzug mit einem eigenen Exclude für Autogenvernichtung sorgt. Dieses eigene Exclude könnte fehlen, denn bei anderen funktioniert sie. (dieser Fall ist eher unwahrscheinlich)

Fall 2. Die SloCro hat keine eigene Excludes für die Rasenflächen. Sie nutzt die eigentliche Excludefunktion der Default Rasenpolys einfach mit aus. Es existiert also zunächst kein Autogenproblem. Aber ev. excludiert ein anderes Addon mittels VTP Exclude genau die Schicht der Default Rasenflächen. Schon bekommt SloCro ein Autogenproblem.

Dieses andere Addon könnte z.B UT sein.

Kontrolliere bitte mal ob diese gestrige Fehlerbeseitigung der Küstenlinie durch Änderung der Priorität von SloCro gegenüber UT nicht ev. sogar Dein Rasenproblem beseitigt hat.

Sollte das Problem immer noch existieren könnte noch etwas sein.

Sehr viele Addons die sowohl Airports als auch Terrain enthalten splitten Ihre Scenery in mehrere Einzelscenerien auf die auch einzeln in der Scenerybibliothek angemeldet sind.

Z.B eine Objektscenery, eine Landclasscenery und eine Terrainscenery.

Denkbar wäre es, dass auch SloCro so vorgeht. Sollte also eine SloCro Terrain Scenery oder ähnlich unterhalb von UT stehen, könnte dieses das Problem sein. Verschiebe bitte daher die ev. weiteren vorhandenen SloCro Scenerien mal zum testen über alle UT Einträge in der Scenerybibliothek.


Dann bitte testen.

Klappt es immer noch nicht, dann bitte mal UT komplett deaktivieren zum testen.

Bleibt das Problem dennoch bestehen, kann natürlich irgendein anderes Pay oder Freeware Addon dieser Gegend dieses VTP Exclude enthalten.


Was es sonst noch an Fehlerquellen gibt, können wir später noch behandeln. Schauen wir erst mal was passiert, wenn Du wie oben vorgehst.



Ich könnte hier natürlich noch wesentlich bessere Hilfestellungen geben um solche Probleme bei Dir vor Ort durch dich selbst einzugrenzen.

Solche Informationen, wie man extrem effizient solchen Code ermittelt (dafür gibt es nämlich bisher keine Tools) wird man im Zuge meiner Doku erhalten.

Aber genau wie ich es bisher bei den Terrain Steuerparametern der FS9.CFG in den letzten zwei Jahren gehalten habe, möchte ich mich dazu vor Veröffentlichung nicht näher äußern. Ich denke wir bekommen es auch so in den Griff. Dauert halt nur länger.



Muss mir das was jetzt zwischendurch geschrieben wurde erst mal später durchlesen.

Die Vorteile von UTE gegenüber AROE kann ich aus eigener Erfahrung bestätigen.
ABER es wird nach meinem Erkenntnisstand weder vom Versandhandel geliefert noch ist es im Mediamarkt zu sehen.
Was machen die, die kein DSL haben und die, die nicht mit Kreditkarte zahlen wollen/können?
Wenn es dann neben dem FSX im Regal liegt, ist es evtl. (???) zu spät.
Uwe

hallo Jobia,

ja, du hattest Recht. Die Platzierung der "Einzelszenerien" von Slo/Cro war nicht korrekt. Das ist ist mir erst durch Horst's Screenshot seiner library aufgefallen (danke dir Horst!). Dort waren 7 Einzelanmeldungen für die Szenerie zu sehen; bei mir nur 4. Die anderen 3 habe ich dann tatsächlich weiter oben gefunden; ich hatte die vorher völlig übersehen. Wie gesagt, ich hatte versucht, nach einer vorher definierten Reihenfolge meine Szenerien anzulegen: Photo, -Landklasse, -Szenerien und Airports, -Mesh. Da hatte ich das dementsprechend auseinandergerissen. Es war also meine eigene Dummheit. UTE und die anderen UTs (USA etc.),habe ich jetzt recht weit unten, exakt eine Position über Aroe gesetzt. Ich denke, da sitzt es richtig. Meine Überlegung ist (wie bei deinen Klarsichtfolien Jobia, ein sehr guter Vergleich), da das ja Straßen-und Küstenaddons sind, das die zum Tragen kommen, wenn die Szenerien, die darüber liegen, für diese Objekte nichts mit sich bringen. Dann ist praktisch deren Folienbereich leer und du kannst dann bis auf UT oder Aroe (falls UT auch hier leer ist) "durchblicken". Sollte auch da nichts sein, blickst du eben bis auf die Standardszenerie herunter, die auch einen entsprechend niedrigen Layer hat. Ich hoffe, das ich das jetzt richtig verstanden habe.
@Horst: vielen Dank für deinen LWM- Link. Das sieht sehr gut aus und ich werde mir heute abend in der Pause das Manual mal durchlesen.

euch allen vielen Dank, wie würde ich manchmal ohne Forum dastehen:-)

mfg Kai