|
AROE verursacht definitiv Speicherleck.
Der Text sollte von den (potentiellen) AROE Besitzern zu Ende gelesen werden.
Mal was zur Entlastung vom ehemaligen Forenmitglied Seemann, der ja für das Forum aufgrund seines Verhaltens gesperrt wurde. Ich gebe zu Seemann konnte durch seine (manchmal auch recht agressive) Art ganz schön nerven. Wenn ich mich recht erinnere, ist das zum Teil bei ihm auch auf gesundheitliche Probleme zurückzuführen. Ich denke er ist von Guido nicht nur wegen der AROE Sache gesperrt worden. Diese wird das Fass nur zum überlaufen gebracht haben. Siehe dieser Thread: AROE rausgeschmissen. Guido hatte bei ihm letzendlich auch bemängelt, dass er der AROE ein Speicherproblem in die Schuhe schiebt obwohl Seemann schon vor erscheinen der AROE bei ihm per Mail von Speicherproblemen auf seinem PC berichtete. Aus Guidos Sicht ist dieses ev. verständlich, dass man Seeman seine Speicherproblematik bei der AROE nicht unbedingt ernst nehmen konnte. Es war leider Pech für Seemanm, dass er offensichtlich mehrere Probleme auf seinem PC hat und durch seine recht rüde Art negativ aufgefallen ist. Denn er hat recht gehabt. Bei ihm ist mit der Installation der AROE zumindest ein weiteres Speicherleck dazugekommen, welches in Europa Probleme bereitet. In einem anderen Thread meldete ein anderer Anwender auch Speicherlecks. Er zählte mehrere Addons auf, die er seit auftreten des Speicherlecks installiert hatte. Man konnte wohl kein Addon ermitteln. AROE tauchte in der Aufzählung allerdings ebenfalls als potentielles Addon auf. Ich erinnere an diesen Thread wo Lutz (Hubs) über Speicherprobleme berichtete. Zu wenig Arbeitsspeicher???? Da es hier im Forum nichts bringt (der Thread wurde wegen der vielen Bilder von Lutz auch kritisiert) haben Lutz und ich uns über Mail kontaktiert. Mittels diverser Tipps und Auszügen meiner Dok. über spezielle Suchverfahren haben wir dann über eine Art Ferndiagnose nach Problemen in seinem FS gesucht. 19 potentielle Störaddons konnte ich ermitteln. Wobei wir nicht weiter gefahndet haben, ob aus allen potentiellen Störaddons wirklich auch Störer werden. Das war nicht nötig, da AROE als eindeutiger Speicherleckverursacher für Lutz seine Flugstrecke ermittelt werden konnte. Der Speicherleckverursacher ist in diesem Fall die AROE Scenerydatei "europe.bgl". Zu finden in einem Pfad, der bei euch ähnlich lauten dürfte: c:\Programme\Microsoft Games\Flight Simulator 9\FSQuality\FSQ-Roads\scenery\europe.bgl Es handelt sich in diesem Fall um eine Landclassdatei, die anhand Ihres Namens (wie so oft) nicht als LC Datei identifizierbar ist. Das Speicherleckproblem ist in diesem Fall wie so oft ein parallel zur Scenery existierender Texturordner. Da ich es immer wieder lese.... der Sachverhalt ist leider einfach nicht aus den Köpfen zu bekommen.... wiederhole ich es nochmal. Es wird immer wieder gesagt: "Eine Landclasscenery darf keinen Texturordner haben, sonst entsteht im FS2004 ein Speicherleck". Diese Aussage ist eindeutig falsch!!!!!!! 1) Eine Fotoscenery wie RG1 usw. wird auch über ein Landclassfile erzeugt. Hier muss ein Texturordner existieren. 2) Man kann bei einem ganz regulären Landclassfile lokal eigene Texturen (andere als die Defaulttexturen verwenden). So einen Fall trifft man z.B bei Misty Fjords oder ATP2005 an. In so einem Fall muss zwingend ein eigener Texturordner existieren. Was man als Designer dabei unbedingt beachten muss, ist das alle Texturen und Informationen die das Landclassfile definiert in diesem lokalen Texturordner vorhanden sein müssen. Beachtet man das nicht entsteht ein Speicherleck. Umso mehr fehlt umso schneller wächst das Speicherleck. Hält man sich an den Sachverhalt unter 2) entsteht auch kein Speicherleck. Wir sehen, hält man sich an die Spielregeln, dann ist ein vorhandener Texturordner kein Problem und auch kein Fehler. Hat ein Anwender z.B so ein lokal produziertes LC File ermittelt und vertritt die allgemein verbreitete Meinung, dass es sich aufgrund des vorhanden Texturordners um ein Speicherleck handelt, könnte dieses dazu führen, dass er dieses LC File entfernt und als Einzelscenery betreibt. Im schlimmsten Fall löscht er ev. den Texturordner. Beides führt dazu, dass die Scenery nicht mehr so arbeitet wie es der Designer vorgesehen hat. Also bitte Vorsicht mit der Aussage ein Texturordner bei einer Landclasscenery ist ein Fehler. Bei dem AROE Landclassfile "europe.bgl" handelt es sich allerdings nicht um eine lokale Landclasscenery in diesem Sinne. |
Das LC File europe.bgl befindet sich quasi getarnt im Scenery Ordner der FSQ-Roads zusammen mit den anderen Straßen und Küsten BGL Files.
Da die AROE eigene lokale Straßentexturen verwendet, existiert zwangsweise auch ein lokaler Texturordner. Im wesentlichen dient er aber nur den lokalen Straßentexturen. Er enthält keine einzige lokale Landclasstextur. Genau hier liegt jetzt das Problem. Aus Sicht des FS bezüglich Landclass verhält sich dieser Texturordner nicht anders wie ein leerer Texturordner. Es entsteht ein Speicherleckbereich der leider fast ganz Europa abdeckt. Das File "europe.bgl" muss daher zwingend aus diesem Scenery Ordner entfernt werden möchte man das Speicherleck verhindern. Ich werde Guido umgehend zwecks eines Patches benachrichtigen. Wer vorher selbst handeln möchte kann dieses "europe.bgl" als einzelne Landclasscenery (natürlich ohne Texturordner) im FS anmelden. (Bitte vor einem offiziellen Patch rückgängig machen, da es sein kann, dass der Patchinstaller Defaultzustände erwartet) Die Frage die sich jetzt manchem stellt ist folgende: Warum gibt es überhaupt ein Landclassfile in der AROE? Warum ist dessen Existenz offensichtlich nicht groß beachtet worden? Was ist bei diesem Landclassfile zu beachten? speziell wenn man vorab handeln möchte (Speicherleckbeseitigung) und es daher als Einzelscenery betreiben möchte. Nun der Grund warum die Existenz wohl untergegangen ist, wird sein, dass es vom Namen nicht als LC File identifizierbar ist und es sich um kein Landclassfile im eigentlichen Sinne handelt. Es soll keine Städte, Ortschaften, Wälder usw. in Europa positionieren. Die Existenz dieses LC Files fällt innerhalb der Länder optisch überhaupt nicht auf. Dieses Landclass File dient einzig dazu Gewässerfehler zu beseitigen. Es enthält daher überwiegend die Transparenz LC Nummer 254. Überall wo LC Nummer 254 definiert ist, bleibt die Erdoberfläche optisch unberührt. Wir finden reguläre LC Informationen die optisch etwas auslösen überwiegend nur an Küsten an. Was ist der Grund dafür? Landclass und Waterclassinformationen sind zunächst immer rechteckig (wie die Landclass und Waterclasstexturen selbst). Immer dort wo Land und Waterclass aufeinander treffen haben wir zunächst rechteckige Übergänge. Landclasstexturen liegen optisch oben, Waterclasstexturen optisch unten. Um diese unnatürlichen Landclassecken zu beseitigen gibt es unsere LWM (LandWaterMask) Polygone. Das sind z.B die neuen Küstendefinitionen die von der AROE geliefert werden. Diese schneiden die überflüssigen Landclasstexturecken auf der realen Meerseite in Form des Küstenverlaufes ab und schmeissen sie optisch quasi in den Müll. Wir sehen jetzt darunter Waterclass also das Meer. Es gibt einen realen Küstenverlauf. Mit diesen LWM Polygonen hat es einige Probleme bei der AROE gegeben, daher klagten einige über rechteckige Küstenverläufe. Es gab unter anderem Kollisionen durch andere Addons die ähnliche Informationen liefern. Dafür gibt es bereits diverse AROE Patches. Aber es kann auch ein anderes Problem für rechteckige Küstenverläufe geben. Das AROE LWM erzeugt in diesem Fall einen korrekten Küstenverlauf allerdings sind andere Grundvorraussetzungen für die korrekte Funktion nicht gegeben. Wir erinnern uns: Im Default FS sind Straßen und Küsten extrem ungenau platziert. Damit ein LWM Poly überhaupt eine Küstenlinie erzeugen kann, muss sich in der Regel unterhalb einer LWM Polyfläche auch eine über Landclassnummer definierte Landmasse befinden. Ein Bild der korrekten Funktion des LWM Küstenpoly mit "europe.bgl" der AROE zeigt uns dieser Sceenhot an der englischen Küste. |
Bei dem Defaultlandclassfile des FS2004 "worldlc.bgl" ist das mit der Landmasse in Bezug zu den realen AROE Küsten jetzt nicht mehr der Fall, denn dieses Default LC File wurde gezielt für die falschen Defaultküsten erzeugt. Diese haben wie bekannt in der Regel einen ganz anderen Verlauf.
Deshalb ist dieses Speicherleck verursachende LC File "europe.bgl" der AROE unbedingt nötig. Ein LWM Poly verpufft an manchen Stellen ohne dieses Landclassfile "europe.bgl" quasi wirkungslos im Meer. Wo die Landmasse per Landclassdefinition fehlt kann man auch keine Landmasse anhand des realen Küstenverlaufes mittels LWM Poly abschneiden. Diesen Zustand zeigt uns der folgende Screenshot. |
Hier ist nur das Default worldlc.bgl des FS2004 aktiv. Ich habe den realen Küstenverlauf der AROE zusätzlich in diesen Screenshot hellgrün eingefügt. Wir sehen auf der Landmassenseite fehlen im Default worldlc.bgl LC Nummern die Landtexturen definieren. Das Default worldlc.bgl definiert LC Nummern die Waterclass aktivieren. Folglich sehen wir, dass allein das Fehlen der "europe.bgl" eckige Küstenverläufe produziert.
Um dieses zu verhindern, liefert AROE jetzt mit diesem Landclassfile "europe.bgl" nur die im Default FS fälschlicherweise fehlenden Landmassen nach. Daher enthält das "europe.bgl" der AROE eigentlich nur LC Definitionen in Küstennähe. Dieses ist der einzige Grund für das LC File. Aus diesem Grunde wächst das Speicherleck in Küstennähe auch am schnellsten an. Übrigends umso höher die erreichten Frames umso schneller wächst das Speicherleck. Die Schuld für die eckigen Küstenverläufe liegt in diesem Fall nicht an den Küstendefinitionen der AROE also deren LWM Polys sondern es sind definitiv Landclassprobleme. Dieser Sachverhalt ist extrem wichtig. Denn es kann durchaus sein, dass ein anderes Landclassaddon ähnlich dem Default worldlc.bgl an der Küste ebenfalls unkorrekte LC Definitionen liefert. Es kommt ebenfalls zu rechteckigen Küstenverläufen. Was ist jetzt zu beachten. Hinsichtlich Priorität können Landclass Addonfiles untereinander über die Position in der Scenerybibliothek geregelt werden. Möchte man das Speicherleck bei AROE beseitigen muss man die "europe.bgl" als Einzelscenery betreiben. Man sollte diese Einzelscenery unmittelbar unter den AROE Eintrag positionieren. Weiterhin sollte man dann vorsichtig mit anderen LC Addons sein, die sich an europäischen Küsten abspielen und oberhalb der AROE in der Scenerybibliothek angemeldet sind. Ältere LC Addons wie z.B FS Landclass zu FS2002 Zeiten definieren auch diese Gewässer LCs im FS. Diese können aus Gründen der Kompatibilität zum Default FS genau so unpasssend gesetzt sein. Diese Problematik gilt natürlich nicht nur für ältere FS Landclassprodukte sondern kann durchaus auch auf aktuelle LC Files von neueren Addons zutreffen. Haben solche LC Addons eine höhere Priorität wie das "europe.bgl" der AROE kann es durchaus passieren, dass eine durch die "europe.bgl" nachgelieferte Landmasse jetzt durch ein anderes höher positioniertes LC Addon wieder aufgehoben und in Wassermasse rückverwandelt werden. Da wird der Anwender bei dem durch so ein Landclassproblem eckige Küstenverläufe enstehen, vergeblich einen Patch fordern. Das AROE Team wird das Problem nicht feststellen können. Bei exakt identischen Addons kann schon allein die Prioritätsvergabe der Addons in der Scenerybibliothek ein Problem verhindern oder auftreten lassen. Fakt ist, dass man eckige Küstenverläufe verursacht durch Landclass nicht der AROE zuschieben kann. Die Küsten sind (dort wo keine LWM Patches benötigt werden) sehr genau. Wenn es durch Addon Landclass Probleme gibt, dann sind diese der Ungenauigkeit des auslösenden Addon zuzuschieben. Wer also wegen des Speicherlecks vorzeitig das "eurpope.bgl" als Einzelscenery betreibt bzw. auf einen offiziellen Patch wartet, sollte diesen Sachverhalt immer im Auge behalten, wenn er auf eckige Küstenverläufe trifft. Das eckige Küstenproblem kann durch LWM Poly bzw. Landclassinformationen eines anderen Addons verursacht werden. |
Nicht vergessen möchte ich das sich dadurch im ungünstigsten Fall ev. auch so mancher Inselbereich ev. mit Wasser füllen kann.
Manche Probleme treten zwar erst im Zuge der AROE auf. Sie sind aber definitiv des öfteren auch auf andere ungenaue Addons rückführbar. |
Dir und Lutz größten Dank!
|
Hi Jobia,
danke für deine Erläuterungen. Bei mir ist aber seit der Installation von AROE kein Speicherleck aufgetreten. Vielleicht liegts daran das die Auslagerungsdatei auf einer zweiten Festplatte liegt?? Aber gut zu wissen, dass eines existiert und man weiß wie man es beseitigen kann. |
Ich hatte auch Probleme mit dem Speicher, die ich auf AROE zurückführen konnte, hab aber angenommen das einfach zu viel Speicher benötigt wird bei den Mengen an Straßen. Dazu kam ja das ich auch keien Auslagerungsdatei hatte. Ich hatte dann eine festgelegt und es lief. So kam mir eigentlich nicht die Idee das es an einer versteckten Landclass liegen könnte. Umso besser zu wissen das es doch eine war.;)
Wan wird Seemann wieder freigeschalten? |
Vielen Dank Joachim für diese überaus präzise Information.
|
Vielen Dank Joachim für Deine (wie immer) sehr ausführlischen Informationen.
Es ist auch unglaublich wieviel Zeit in diesen Recherchen steckt !! Also nochmals VIELEN DANK ! Gruss Andreas |
Zitat:
Weiterhin wieviele fehlende Texturen in diesem aktiven Bereich geladen werden müssen. Hätte man ein 300km x 300km großen Bereich in dem nur eine LC Nummer aktiv ist dann werden nur maximal 7 Texturen benötigt. Das bedeutet im günstigsten Fall (ganz vereinfachtes Beispiel ich will es nicht kompliziert machen) nur eine Speicherlast durch 7 Texturen. Da läuft der Speicher extrem langsam voll. Man wird es nicht bemerken. Weiterhin hängt es mit den erreichten Frames zusammen. Sind die Frames hoch werden auch die Texturen häufiger neu aufgefrischt (siehe Thematik unscharfe Bodentexturen und schärfere Texturen bei Framevorgabe unendlich) Werden die 7 Texturen in unserem Beispiel öfter aufgefrischt dann wird bei jedem Auffrischungsvorgang eine neue Speicherlast erzeugt. Hat ein LC File extrem hohe Landclass und damit auch Texturvielfalt dann erzeugt jede der vielen Texturen eine Speicherlast. Da die AROE nur wenig LC Informationen innerhalb der Landmasse liefert, tritt bei Inlandsflügen das Speicherleck kaum in Erscheinung. Fliegt man aber im Küstenbereich zum Beispiel nach Mallorca oder ähnliches dann tritt es schon stärker auf. Wer dann noch hohe Frameraten hat bei dem verstärkt sich das ganze noch mal. Auch hängt es davon ab in welchem Bereich die AROE wieviel Landmasse nachliefern musste um Gewässerprobleme zu beseitigen. Es gibt also regional unterschiedlich stark anwachsende Speicherprobleme. Wie man sieht ist im FS alles nicht so einfach. Ohne Lutz hätte ich der AROE auch kein Speicherleck zugeschrieben. |
Hallo Zusammen
Auch ich möchte mich auf diesem Wege nochmals öffentlich bei Joachim bedanken,denn es ist nicht selbstverständlich, soviel Zeit in ein Problem des Anderen zu investieren (ich weiß wovon ich spreche).Also nochmals herzlichen Dank Joachim und hoffentlich macht unser Beispiel Schule. Servus Hubert |
Zeitlich war das nicht so schlimm. Klar es gab einiges an Techniken zu erklären um zu Ergebnissen zu kommen. Aber im Großen und ganzen war es nicht so schlimm, da ich vieles aus der Dok entnehmen konnte. Leider habe ich dort wegen anderer Gründe schon seit Wochen nicht mehr dran gearbeitet.
Schlimmer war die Zeitverschwendung die wir aus den anderen Dir bekannten Gründen hatten. Ohne dieses ich nenne es nicht beim Namen (ist nicht böse gemeint) wären wir sehr viel früher zu einem Ergebnis gekommen. |
Da hast Du Recht
|
Hallo Joachim,
tolle Dokumentation und Recherche von Dir (wie immer :)). Auch wenn ich die ARoE selber nicht habe (ich warte lieber auf Ultimate Terrain Europe) so wird das sicher vielen hier weiterhelfen. Viele Grüße, Michael Grüterich http://www.grueterich-software.de/avatar.jpg |
Zitat:
Das erste Bild zeigt die Speicherlast des Fluges in GByte per handschriftlicher Zahlen eingetragen. Lutz sein Flug ging von München nach Mallorca wie man sehen kann. Fängt bei 960MB an und endet bei über 1,6GB. Mallorca ist aber kein extrem langer Flug. Man kann sich ausmalen wo das endet wenn man zurück fliegt. Oder einen PC hat der sehr hohe Frames liefert. Der Zustand der Default AROE als Screenshot |
Hier wie es aussieht wenn man den Fehler der AROE beseitigt. Wir befinden uns beim gezeigten Bild bereits kurz vor der Landebahn auf Mallorca. (Lutz seine Bilder enthielten zusätzlich noch die Screenshots aus dem FS wo er sich gerade befand, dass kann man sich hier schenken)
Wir sehen wir liegen bei knapp 1GB. Wenn man bedenkt das der Flug bei 960MB begonnen wurde dann ist das nicht viel zusätzliche Speicherlast. Diese Speicherlast ist normal, da ja während des Fluges ständig neue Scenerydaten von z.B Addons dazukommen. Nicht alles fliegt aus dem Speicher wieder raus. Wir müssen uns daran erinnern, dass mit dem AROE Fehler die Speicherlast bei exakt dem selben Flug um ca. 600MB höher lag. Nicht unerheblich wie ich finde. Lutz verbraucht mit korrigierten Fehler über ein Drittel weniger Speicher. Wie gesagt umso höhere Frames ein PC erreicht, umso schneller kann das Speicherleck wachsen. Bei einem anderen wäre es ev. schon auf 2GB oder mehr angestiegen. Bei einem lahmen PC ev. nur auf 1,3GB. Der Screenshot nach Bereinigung |
@JOBIA: Eigentlich fehlt unter Deinen Artikeln nur noch ein
Q. E. D. :D Gratulation und vielen Dank! |
Eine super Leistung sich so hinter eine Sache zu klemmen um das Problem zu lösen.
Aber, sollte man dass normalerweise nicht vom Hersteller erwarten?? Gruß Olli |
Zitat:
|
Naja, Du hörst aber sicher auch auf das was Dir Anwender sagen...:rolleyes:
|
Wenn irgendjemand diesen Thread eröffnet hätte...aber an diesen Ausführungen von einem bekannten Texturenpapst kommt wohl niemand, der mit den AROE zu tun hat, so leicht vorbei.
|
Zitat:
Edit: das Ganze ist natürlich eine Einstellungssache zu der Software, die man selbst entwickelt hat. Es gibt leider auch Entwickler, die so überzeugt sind von Ihrer Software, dass sie kein Feedback annehmen. Wir (in unserem Entwicklerteam bei mir auf der Arbeit) haben dafür einen sehr schönen Begriff: "My-Baby-Syndrom". |
Wie sieht es denn eigentlich mit der Ultimate Terrain Reihe aus, denn die nutzen ja auch Landclasses? Könnte dort nicht auch ein Speicherproblem auftreten?
Gruß Thomas |
Re: AROE verursacht definitiv Speicherleck.
Hallo,
Zitat:
Wäre es auch möglich die Liste der anderen potentiellen Störenfriede zu veröffentlichen? Dann könnten vielleicht noch mehrere solcher Fälle gefunden werden, die uns vPiloten den Spaß verderben! Am schönsten wäre eine zentrale Anlaufstelle, wo für jedes erdenkliche Addon geprüfte Fehler aufgelistet werden und wie man diese umgeht... |
Zitat:
Ultimate Terrain benutzt zwar auch eigene Texturen, legt diese aber schlauerweise im World/Scenery/Texture Ordner ab. UT hat also keinen eigenen Texturen Ordner, somit sollte solch ein Problem auch gar nicht erst auftreten. Darüberhinaus kann man UT über ein eigenes kleines Programm seinen Wünschen entsprechend anpassen und mit einem Mausklick sogar komplett abschalten um wieder die FS-Standardszenerie zu nutzen. Bei dem Produkt waren echte Profis am Werk die sich vorher genau Gedanken gemacht haben wie man's machen sollte und wie nicht... ;) Viele Grüße, Michael Grüterich http://www.grueterich-software.de/avatar.jpg |
Hallo,
Quote: „Bei dem Produkt waren echte Profis am Werk die sich vorher genau Gedanken gemacht haben wie man's machen sollte und wie nicht... Soll man lachen oder weinen! Ich habe weder AROE noch UT, aber nach dem 5. Service Pack werde ich überlegen! Und zu: http://www.wcm.at/forum/showthread.p...47#post1653147 Man kann aus Topo Karten kein Landclass machen! Horst |
Zitat:
Das bleibt Dir überlassen ;). Nein, jetzt mal ernsthaft: Auf jeden Fall ist ein externes Programm mit welchem man Teile eines solch' komplexen Szenerie Add-Ons mit einem simplen Mausklick deaktivieren, oder die gesamte Szenerie gleich komplett ausschalten kann, ungemein hilfreich wenn es darum geht Fehler zu suchen bzw. einzukreisen. Das ist sehr anwenderfreundlich und hier haben die Authoren mitgedacht, das wollte ich damit ausdrücken. Zitat:
Viele Grüße, Michael Grüterich |
Hi,
vorerst mein Kompliment an "Jobia" er trägt viel bei, durch seine intensiven Recherchen uns die Sachverhalte näher zu bringen. Auch ich habe mit AROE meine liebe Not, was ich ursprünglich nicht bemerkte und Fehler woanders suchte. Wie auch immer bin ich froh, dass an einer Problembehebung gearbeitet wird, seitens FSQuality. Um ähnlichen Problemen vorzubeugen, könnte ich mir vorstellen, dass bevor ein neues Produkt herauskommt, ein paar Fachleute von unserem Forum, gratis ein neues AddOn bekommen um dieses zu testen. Nach erfolgten Test und deren Behebung, würde man sich viel Ärger ersparen, sowie ellenlange durch schon Monate ärgerliche Postings. Das müßte ja im Sinne des Herstellers sein, weil solche negativen Beiträge, sich nicht gerade umsatzfördernd auswirken können. |
Hi !
Ich habe hier vor einiger Zeit einen Thread aufgemacht, in dem ich mich über die miese Performance der Straßen beklagt habe, und dabei die Symptome folgendermaßen beschrieben: bei kurzen VFR Flügen alles in Ordnung, wenn man aber einen Airliner nimmt, kommt der FS nach einiger Zeit nicht mehr mit dem Texturenladen nach, die Bodentexturen (und damit die Straßen) werden immer gröber aufgelöst, auch sinkt generell die Framerate. Ich habe dann danach gefragt, ob es möglich ist, die Roads einfach in der Szeneriebibliothek zu deaktivieren, und habe das dann auch ausprobiert. Resultat: es gab überhaupt keine einzige Straße mehr, auch nicht die default. Also hab ich die Roads ziemlich enttäuscht ganz normal deinstalliert und mich über das ausgegebene Geld geärgert. Ich bin natürlich als "Normaler Anwender" gar nicht auf die Idee gekommen, dass ein komerzielles Produkt mit automatischem Installer ein Speicherloch verursachen könnte, also hab ich auch nicht mal einen Blick in den Task-Manager geworfen. Ich muss schon zugeben, dieser Thread von Jobia hat mich ziemlich überrascht, was es alles gibt :D Auf diesem Weg möchte ich auch eigentlich niemanden kritisieren, sondern mich einfach bedanken, dass es User gibt, die für "normale User", die einfach nur ein Produkt, für das sie immerhin Geld ausgegeben haben, benutzen möchten, und nicht sich Gedanken machen, wo die Fehler liegen könnten, auf Fehlersuche gehen. Mir ist schon klar, dass man mit (kleineren) Bugs durchaus zu rechnen hat, aber ein Speicherloch würde ich als grobes Problem bezeichnen, das ich eigentlich nur aus (von mir :) ) falsch installierten Freeware-Szenerien kenne. Nun, ich bin ganz froh, die Straßen werden, sobald der Patch da ist, eine zweite Chance bekommen. Es wäre nämlich schade gewesen, um so ein tolles Produkt. vg martin |
Hi Martin,
habe gerade in der Scenerybibliothek, bevor ich Deinen Beitrag las, die Areo nur deaktiviert. Deshalb bin ich froh, dass Du darüber schriebst,dass auch die Defaultstrassen deaktiviert werden, also bleibt einem nur die Deinstallation. |
Zitat:
|
Moin,
was mich eigentlich bei so etwas auch immer ein wenig stört: Warum nutzt man nicht gegebene Namenskonventionen, die sich auch bei anderen Designern eingebürgert haben? Also z.B. Landclass- oder Waterclass-Dateien mit lc bzw. wc zu bezeichnen? europe.bgl würde ich ganz sicher für viele Dinge hernehmen, aber für Wasserklassen aufgrund der nötigen Änderungen an den Küsten? Naja... Sicherlich kann man durch Hex-Begutachtung der Fileheader auch erkennen, was wofür schlußendlich steht. Aber dann wäre der Fehler vielleicht viel früher aufgefallen. Hinterher ist man aber sowieso schlauer. Es stehen ja sowieso noch einige Patches der ARoE an. Stichwort: Scenery Germany. Schon lange versprochen. Ciao, Rainer. |
Auch von mir vielen dank für den erneut sehr wertvollen Beitrag.
Ohne Dich wären wir alle ein Stück ärmer. Das denke ich schon lange und habe nun die Gelegenheit genutzt, es auch zu sagen. |
Hallo Freunde!
Einmal ein paar Tage nicht aktiv und nun sehe ich diesen Beitrag von Jobia! Als fast nur passiver Forumianer muss ich mich nun melden und diesbezüglich in tiefster Ehrfucht meine Gratulationen vor allem an Jobia und allen anderen pauschal aussprechen... Ich habe selbst unzählige Stunden, Nächte mit den AROE experimentiert um "mein" Speicherproblem lösen zu können. Habe FS neuinstalliert, praktisch alle Szenierien deaktiviert, einzelne *.BGLs deaktiviert und bin immer wieder bei den AROE, besonders in Verbindung mit dem MyWorld-LCs hängen geblieben. Schließlich auch die "Einengung", dass im Küstenbereich die Probleme größer werden und z.B. von Wien nach Rhodos alles ok ist. Und nun DIE Bestätigung und (was meiner Meinung nach viel wichtiger ist), die exakten Begründungen und Erklärungen - nochmals vielen, vielen Dank! Ich war diesbezüglich auch mit Guido in Kontakt und bekam jedesmal, auch wenn es nicht notwendig gewesen wäre, ein Feedback, das sollte hier auch löblich erwähnt werden. Ich bin mir sicher, dass ohne ein solches Produkt, auch wenn sich dabei jene Probleme ergeben, keine allzu positiven Weiterentwicklungen des FS ergeben könnten, denn nur "das Bessere ist der Feind des Guten". Und in diesem Sinn sollten wir weiter hoffen können, dass ich der FS schön langsam aber bestimmt in Richtung bessere "World-LC", ca. 38m Mesh, exakte Küsten, Eisenbahnen etc. weiterbewegt. Kurz so "schön" z.B. die Swiss prof. ist - mir würde ein weltweiter AROE-Standard mit deren Küsten, erweiterten Flüssen, Eisenbahnen oder die Austria prof. schon fast mehr als genügen (Bin übrigens selbst Geograf..). Ich könnte mir den FS in Eu ohne den AROE nicht mehr vorstellen. Sei es als IFR-Flieger oder wenn ich mit der Cessna meine Joggingstrecken um meinen Standort nahe LOXZ "nachfliege". Bin von der optischen (Breite, Farbe) wie auch geogratischen Umsetzung immer wieder begeistert. Ich hatte übrigens ein Konkurrenzprodukt die USA betreffend für 2(!) Tage am Rechner. ...etwas Landschaft wollte ich schon auch noch sehen, nicht nur "Roads"; grauenvoll! Dass der FS ein entsprechend komplexes Programm ist (ich habe inzwischen über 40 GB nur an Szeneriedaten) und damit zumindest die Prioritäteneinstellung zusammen mit den Typen Mesh, LC etc. in der Szeneriebibliothek einigermassen beherrscht werden sollten, dürfte für alle jene, die "richtig fliegen" keinen zusätzlichen Aufwand darstellen. Dies wollte ich in diesem Zusammenhang auch einmal "vorsichtig" loswerden - bitte nicht schlagen! Happy Landings, Gerhard |
Hallo Gerhard,
Dich schlagen will ja niemand, außerdem weiß niemand, wie stark Du bist;) .:D |
Servus Helmut!
...wäre bei meiner Statur aber leicht möglich, hi - könnte höchstens versuchen davonzulaufen. Spass ohne: Du hast das natürlich verstanden, wie ich das gemeint habe, denn teilweise kann man sich über unqualifizierte Kritiken schon ärgern. @alle dazu ein Beispiel: Ich kaufte mir kürzlich eine recht nette Schottland Szenerie. Aufgrund meiner "krankhaften" Panik bei allen Installern also HDD Ghosten und Scotsflight installiert. -> Katastrophe aufgrund installierter AROE die Küsten und Strassen betreffend. Da die falschen Default-Küsten von den Designern nur "Auge mal Pi", also nicht GPS-genau korrigiert wurden, gibt es natürlich Chaos. Sicherheitshalber habe ich eine nackte FS9.1 Version zum checken und dort natürlich optisch alles bestens - fällt keinem auf, wenn irgendwo eine Bucht zu viel oder zu wenig ist. Nach Rücksicherung gings ans Eingemachte: Durch recht sinnvolle Dateinamen kann man relativ leicht die überbreiten Straßen und Küsten entfernen, sodass die AROE und deren Küstenstreifen übrigbleiben. Dabei kann es aber vorkommen, dass auch einige Szenerien gelöscht werden sollten, damit diese dann nicht im Wasser oder so stehen. Mir ist ein fehlender Hafenteil z.B. in Edinburgh lieber, als eine doppelte Küste oder unschöne Straßen im "Forth". Sollte ich nun auf AROE oder auf Scotflight angefressen sein? Beide Probleme gäbe es nicht, wenn Küsten und Straßen bereits in der Defaultversion jene Genauigkeiten erreicht hätten. Also die irgendwo angesprochenen Standards - zumindest kontinentweit - wären sicher kein Fehler... Viel Spass, Gerhard |
Moin zusammen!
Als erstes: Zitat:
Erst Gestern Abend schrieb ich in einem anderem Thread,dass seine berufung eigentlich eher in Redmond bei MS in der Abtl.FS liegt;) Ich habe die AROE bis jetzt immer noch nicht,obwohl mir "the lord of Terrain"(Jobia) diese bedenkenlos empfohlen hat.Da ich wirklich sehr viel Add ons installiert habe und Gott sei dank bis jetzt alles einwandfrei läuft,trotz auch einiger sogenannter Problem Add ons,ist mir das Risiko einer AROE install nach wie vor immer noch zu gross. Hinzu kommen nachwie vor die fehleneden Strände etc.! Mal schauen wie es weiter geht mit AROE denn das Potenzial ist ja def. vorhanden.Zu gegebener Zeit werde ich dann wohl auch Kunde werden... Zu: Zitat:
Auch wenn Horst nicht weiss ob er lachen o.weinen soll aufgrund der Top Desighner,muss man folgendes bedenken. Heinz lt.Joachim einen Lupenreinen Code bzgl. der Strassen abgeliefert. Joachim hat seine Doku vor allem für Desighner entwickelt um genau solche Probleme in Zukunft selbst zu finden und sie im vorraus gleich ausschliessen zu können. Desweiteren gibt es m.E keinen User in der gesammten Scene der ein so tiefgreifendes Wissen über das MSFS Terrain verfügt. Es gibt zwar noch ein paar User(Mr.Stock,Fumey,Ludowise etc.) Jedoch sind diese Weltweit allein durch die ihre englische Dokumentation fast jedem ein Begriff.Joachim hat es derzeit schwer sich dort zu etablieren(vielleicht wiil er dies auch gar nicht?).Die Doku liegt derzeit nur in kleinen Auszügen vor.Wenn sie dann kplt releast wird ist sie auf Deutsch,dass ist zwar sehr schön,nüzt aber einem nicht Deutsch verstehenden Desighner gar nichts.Bleibt im interesse der ges.community zu hoffen,dass diese evtl.später von geeigneter Stelle übersezt wird.:rolleyes: Wunschdenken;) Zum Schluss bleibt mir zu schreiben: "Es ist nicht alles Seemansgarn was hier geschrieben wird. Oftmals sind es gerade die "geistigen Tiefflieger"(bzw.Psychisch Kranken)die es letzt endlich doch draufhaben.Aber auf Grund ihrer Art nicht für voll genommen werden. Es geht sogar soweit,dass sie ausgeschlossen werden. Sollte man diesen Status wieder deaktivieren? Wenn seine rüde Art nicht wäre............................ In diesem Sinne viel Spaß ohne Speicherleck:D |
Werde morgen oder ev. heute noch etwas dazu schreiben. Jetzt fehlt mir etwas die Zeit.
|
Zu
"Sicherlich kann man durch Hex-Begutachtung der Fileheader auch erkennen, was wofür schlußendlich steht. Aber dann wäre der Fehler vielleicht viel früher aufgefallen." Ich arbeite generell schon seit fast 3 Jahren über solche Headererkennungsverfahren. Allerdings keine Einzelbetrachtung das wäre unsinnig. Durch diese Headererkennung haben wir letzendlich auch die 19 Störaddons bei Lutz ermittelt. Die Verfahren sind übrigends auch in meiner Dok beschrieben. Natürlich erfolgt das alles über Scan Verfahren (die gewünschten Pfade werden nach Code abgesucht, ein öffnen jedes verdächtigen Files z.B mit SDK Tools wie TMF Viewer wäre viel zu zeitaufwendig) und würde Tage dauern, wenn man nicht weis nach was man sucht. Ich scanne generell meinen FS über solche Verfahren nach LC/WC,LWM,VTP,Mesh,AFCAD Code und ähnlichem ab (wenn ich der Meinung bin es ist nötig). Denn das die Namen von BGL Scenerydateien Informationen Preis geben, kann man nicht erwarten schon garnicht bei LWM oder VTP Code. Speziell bei Mesh wird man sogar reingelegt, da z.B die Area16N Flattencodes aus dem Designtool SCC immer automatischen DEM im Namen eingetragen bekommen (es sei denn der Designer benennt sie um). Der Anwender könnte meinen es handelt sich um ein Digital Elevated Mesh. Denn dieses wird in der Fachsprache oft mit DEM abgekürzt. Ich verwende allerdings zwecks Scanvorgang eigene erstellte Routinen, die eine spezielle Programmiersprache auf dem PC voraussetzen. Da ich diese aus lizenzrechtlichen Gründen nicht weitergeben darf, musste ich nach anderen Lösungen für normale Anwender suchen. Durch ein Tippgeber bin ich auf ein Tool gestossen, welches mir von früher bekannt war. Nur ich wusste damals nicht, dass es diese Möglichkeit bietet. Bei Lutz haben wir weiterhin Treeinformationen erstellt, die er mir dann geschickt hat, so konnte ich über weitere Verfahren ermitteln wo LC Files einen parallelen Texturordner haben. So kommen wir dann zu 19 potentiellen Störaddons. Es muss dann natürlich eine Feinselektion erfolgen. Handelt es sich um ein lokales LC File wo alle Texturen fehlen oder fehlen nur teilweise welche. Oder ist alles vorhanden, denn dann ist es kein Störaddon mehr. Die AROE ist aber wie gesagt ein Störaddon. Fraglich ist halt ob es zuvor wirklich aufgefallen wäre? Denn ich habe ja die Möglichkeit des Abscannens gehabt. Es ist mir auf dem Desktop PC wo AROE drauf ist, trotzdem nicht in den Sinn gekommen die AROE nach Landclass abzuscannen. In der Regel macht man das nämlich nur, wenn man mit irgendetwas Probleme hat oder der Meinung ist man müsste sich generell mal eine Übersicht verschaffen. Da ich für längere Flüge aber keine Zeit habe, ist mir bei AROE wie vermutlich bei vielen anderen hinsichtlich Speicherleck nichts aufgefallen. Diese generelle Übersicht habe ich mir wie gesagt bei Lutz verschafft, weil wir nicht wussten wo wir anfangen sollten. Mittlerweile zeigt es sich jetzt doch das es wohl sinnvoll sein könnte seinen FS nach bestimmten Code abzuscannen. Das habe ich auch bei Lutz seinem Default Base Scenery Pfad gesehen. Hier verteckt sich doch eine immense Masse an LC Addon BGL Dateien die nicht annähernd mit halbwegs sinnvoller Priorität arbeiten. |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 02:33 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag