Da ich mit Dirk in Kontakt gestanden habe und er die Files durch die neue Ground2K Version schicken wird, würde ich sagen lasst ihm die Zeit. Ev. ist der Fehler dann behoben. Wenn nicht können wir immer noch der Sache genauer auf den Grund gehen. Warum sollen wir im Vorfeld groß suchen wenn es sich ev. erledigt.

Mir ist neulich halt das mit den Polys aufgefallen. Es hat sich nun offensichtlich auch bei Holger bestätigt das komplexe Polys auch andere Fehlereffekte verursachen.

Was mir am Freitag aufgefallen war, war das zyklische Anschwellen der Auslagerungsdatei. Also ca. 5 Minuten nichts dann urplötzlich Aktivität. Da habe ich dann gesehen das in dem moment immer gerade AI Traffic aktiv war.

Nun das hat aber eigentlich nichts mit Dirk seiner Scenery zu tun. Weiter konnte ich aber noch nichts testen da ich Freitag das letzte mal am PC war.

Das mit dem AI-Traffic ist mir auch aufgefallen, ich kann mir überhaupt nichts dazu vorstellen. Wir warten ehrfürchtig auf Dein Wort dazu...

Guten Abend,

die neue Ground2k4 5.32 erzeugt wirklich sehr kompakten Code. Ist wohl - wie schon richtig bemerkt - die neue konkave Polygonstruktur "schuld".

Zum Zeitpunkt meiner letzten Flüsse (Bodensee etc...) gab es gerade die 5.30. Die hatte interessanterweise einen netten Bug, der dann im Bodensee zu schönen Effekten führte: es gab viereckige Landbereiche, wo sie nicht hingehörten: Bug-Alarm.
Eine kurze Mail an Christian mit einer Fehlerbeschreibung führte dann 1 Woche später zur 5.32.

Meine Flüsse sind bisher fast alle mit der 5.1 (oder früher) erstellt. Die 5.32 kam zu kurzzeitig, um den Betatest damit nochmals neu aufzunehmen und trotzdem zum Jahresende den Vollzug melden zu können.

Mittlerweile bin ich für OWL2003 (FS2004-Version) und OWL2004 komplett auf 5.32 umgestiegen und habe keinerlei Probleme damit festgestellt. Kann ich also empfehlen.

Denkt Ihr wirklich, dass möglicherweise "schwierige" Polygone im FS2004 problematisch sind? Würde mich selbstverständlich sehr interessieren, wenn dies nachprüfbar wäre. Werde sowieso mal meine Flüsse komplett neu kompilieren und damit mal die nächsten Wochen probeweise meine Runden drehen. Sehr wahrscheinlich sind die kompakteren bgls ja auch schneller.

Ciao,
Rainer.

Ja Rainer es sieht zunächst danach aus. Speziel betroffen scheinen aber nur VTP2 Polygone zu sein.

Holger hatte mir bestätigt das sich bei ihm durch die Rekompilierung der Fehler mit den Nachtpolys positiv gebessert hat. Es ist nur noch ein File trotz Ground2k neue Version fehlerbehaftet. Der Grund wird zwar wie immer etwas anderes sein aber was soll es wenn die neuen Polys generell weniger Probleme erzeugen geht es wohl in der Regel gut.

Ich habe aus Zeitgründen noch weiter nach dem eigentlichen Fehler gesucht.

Was ich aber für extrem wichtig bei dieser neuen Ground 2K Version halte ist die Kontrolle der Polys am besten über FSUIPC Verlinkung zum FS. Aus Erfahrung mit einem anderen Designtool welches generell keine Polyzerlegung in convexe Polys vornimmt weis ich das Vectorpoints im Code einfach nicht genutzt werden, wenn sich der Bereich zu stark nach innen wölbt.

Daher weis ich nicht wie genau der Christian das ausgetestet hat. Das sollten jetzt ev. die rückmelden die viel mit ground2k programmieren.

Ev. muss er da noch mal wieder ein Schritt zurück gehen bei der Polyzerlegung. Denn ich habe jetzt doch sehr viele nach innen gewölbte Flächen gesehen.

Hallo Joachim,

Sehe gerade, daß Du über unser Update gesprochen hast. Ja, das mit dem Autogen geht jetzt sehr zufriedenstellend - bist ja nicht ganz unschuldig daran:).

Du hast noch Fragen? Mach das erst mal über E- Mail - hast Du das Programm von Christoph schon testen können?

Gruß
Rolf

Mail ist raus. Das mit dem Prog. sieht aus meiner Sicht vom Ansatz sehr gut aus. Warum der Code nicht funktioniert habe ich nicht checken können. Aber Fehler habe ich auch erkannt. Ansonsten sieht es wie gesagt gut aus. Da kann man was raus machen.

HH-Scenery Speicherpoblem gelöst...???
 

Hallo Leute,

leider habe ich es noch nicht geschafft, die Dateien neu zu kompilieren. Die neue Version verändert die Polygone zum Teil in ihrer Gestalt, so, dass ich alle einzeln kontrollieren muss. Die Hälfte habe ich fertig, der Rest dauert noch ein wenig. Im Zusammenhang mit dem Speicherproblem ist das aber nicht ganz so wichtig, da, wie Joachim schon richtig vermutet hat, das Speicherproblem nicht durch die neu kompilierten Dateien behoben wird.

Es gibt Leute, die dieses Speicherproblem nicht haben. Anscheinend nutzen diese nicht den AI-Traffic des FS. Es sieht so aus, als ob dieser etwas damit zu tun hat, das habe ich aber noch nicht getestet.
Sören, ein Flusifan aus Hamburg-Norderstedt hat sich die Mühe gemacht und viel experimentiert. Das Ergebnis lässt sich sehen. Ich habe seinen Vorschlag noch ein wenig modifiziert und im FS2004 getestet. Der AI-Traffic war eingeschaltet, Hamburg-Finkenwerder, Boberg und GA3 installiert. Das Ergebnis sah so aus:

FS gestartet und einmal im virtuellen Cockpit und in der Aussenansicht in alle Richtungen geschaut, um

13.15 Uhr liegt der Speicher bei 522 MB

Dann von Altona in die Innenstadt geflogen, den Heli dort abgestellt und den FS laufen gelassen, um

14.13 Uhr liegt der Speicher bei 534 MB

Den FS ohne etwas zu machen weiterlaufen lassen und um

15.17 Uhr lag der Speicher bei 536 MB

Dann einen Flug von der Innenstadt, Köhlbrandbrücke, Wedel, Innenstadt, Boberg, Flughafen Hamburg und den Heli dort abgestellt. Um

15.45 Uhr lag der Speicher bei 594 MB.

Dann den FS weiterlaufen lassen und um

16.15 Uhr lag der Speicher bei 592 MB.

Soviel zum Test. Sören’s Idee scheint also zu funktionieren.

Entgegen aller vorherigen Ratschläge sollten die Modifikationen (gilt nur für den FS2004) wie folgt aussehen:

1)
Im Ordner HHGround2004 zum Scenery-Ordner noch einen Textur Ordner erstellen.

2)
Die Dateien asphalt.bmp, asphalt_wi.bmp, Container2.bmp, ContainerN1.bmp, Gewerbe.bmp und HFeld.bmp aus dem FS- Texturhauptordner in den soeben erstellten Textur-Ordner verschieben.

3)
Im ADDON SCENERY-Verzeichnis einen weiteren Ordner „HH-Landclass“ mit Unterverzeichnis Scenery erstellen.

4)
In den Unterordner Scenery die Dateien InselLC_050_012.bgl und LC_050_012.bgl aus dem Ordner HHGround2004/Scenery verschieben.

5)
Den HHLandclass-Ordner anmelden im FS.

Im Ergebnis sollte jetzt der HHGround2004-Ordner ein Scenery- und ein Textur-Verzeichnis haben. In dem Texturverzeichnis sollten die o.a. Bitmaps vorhanden sein und in einem neuen Verzeichnis HHLandclass/Scenery stehen die beiden o.a. Landclass-Files, die aus dem HHGround2004/Scenery-Verzeichnis verschoben wurden (nicht kopieren….sondern verschieben!!!).

So sollte es klappen. Vielleicht hat Joachim ja eine Idee, warum das so funktionieren kann, ich nicht…..

Probiert es mal aus und teilt mit, ob es auch bei Euch klappt.

Viel Glück,

Gruß Dirk
:)

Re: HH-Scenery Speicherpoblem gelöst...???
 

Einspruch lieber Dirk.....
Daran kann es nicht liegen, denn ich nutze voll den AI-Traffic
und ich habe kein Speicherproblem.

Gruss Jürgen

Jürgen
Dein Satz passt so nicht ganz. Denn wenn Du das Problem nicht hast weist Du doch garnicht ob es daran liegt oder eben nicht.

Man muß auch ehrlich gesagt ganz schön lange testen um das Problem zu erkennen zumindest war es bei mir mit 1GB Ram so. Da bekommt man so schnell keinen Absturz.

Aber kommen wir zum Thema. Habe jetzt Deine Variante noch nicht getestet Dirk ob sich so das Problem beheben lässt.

Ansonsten zu Deinem Text:

"So sollte es klappen. Vielleicht hat Joachim ja eine Idee, warum das so funktionieren kann, ich nicht….. "

Ich habe noch nichts weiter getestet. Ich wollte erst mal Deine Ergebnisse abwarten bezüglich neuer Ground2k Version.
Nachdem das wie ich vermutet habe aber nichts bringt habe ich mir einige Dateien heute mal vorgeknöpft.

Zunächst mal etwas zu Punkt 4) Hat eigentlich nichts mit dem Problem zu tun ist mir aber trotzdem aufgefallen.

Dein Punkt4)

"4)
In den Unterordner Scenery die Dateien InselLC_050_012.bgl und LC_050_012.bgl aus dem Ordner HHGround2004/Scenery verschieben. "

Frage von mir. Weshalb die LC_050_012.bgl überhaupt? Das Landclassfile InselLC_050_012.bgl enthält zusätzlich den Inhalt des Files LC_050_012.bgl.

Daher ist es LC_050_012.bgl unabhängig von der jetzigen Kopieraktion eigentlich überflüssig. Ob es so Auswirkungen hat? In der Regel ist es unüblich innerhalb einer Scenery überlappende LC Files zu haben.
Störungen sollte es aber nicht verursachen sonst wären die Barthfiles eigentlich überhaupt nicht lauffähig. Allerdings sieht es bei ihm so aus das bei überlappenden Bereichen immer Transparenz LC 254 gesetzt ist. Bei deiner Hamburg gibt es reguläre LC die sich überlappen.

Wie gesagt für das Speicherleck dürfte es keine Auswirkungen haben.

"5)
Den HHLandclass-Ordner anmelden im FS.

Im Ergebnis sollte jetzt der HHGround2004-Ordner ein Scenery- und ein Textur-Verzeichnis haben. In dem Texturverzeichnis sollten die o.a. Bitmaps vorhanden sein und in einem neuen Verzeichnis HHLandclass/Scenery stehen die beiden o.a. Landclass-Files, die aus dem HHGround2004/Scenery-Verzeichnis verschoben wurden (nicht kopieren….sondern verschieben!!!)."


Genau hier ist mir etwas aufgefallen. Du arbeitest bei der Ground Scenery mit VTP2 Polys. Das machen andere auch. Du nutzt zum Teil aber eigene Texturen. Eben diese, die Du jetzt bei der Verschiebeaktion erwähntst. Nun muß ich sagen das ich im Prinzip bei meinen CTD Patch ja eigentlich genau das selbe machen mußte um zu verhindern das Autogen auf den Airports rum steht. Nur mein Patch verursacht kein Speicherleck zumindest hat das bisher keiner gemeldet. Mir ist auch nichts aufgefallen. Bei mir sind die Texturen für die Airportpolys auch im Haupttextureordner. Bei mir weicht es aber von Dir ab weil ich über die terrain.cfg arbeite. Es ist daher nicht unbedingt vergleichbar. Nur bei Dir fällt mir etwas auf was anders ist.

Beispiel File "Elbe_5.BGL" Hier wird bei Texturzuweisung 3 (zählweise bei 0 beginnned also im Prinzip die 4 Texturzuweisung)
die Gewerbe.BMP und anschließend die asphalt_Wi.bmp dem selben Poly zugewiesen.

Das kann Absicht gewesen sein, da Du gedacht hast für den Winter mache ich nicht extra eine Gewerbe_WI.BMP sondern nutze einfach die asphalt_wi.bmp für den Winter. Nur wenn ich die Texturen vergleiche muß ich sagen das kann so nicht Absicht gewesen sein das würde optisch nicht aussehen . Außerdem haben beide Texturen verschiedene Formate. Gewerbe 512 x 512 Pixel, asphalt 256 x256 Pixel. Auch würde die Gewerbe.BMP als VTP2 Poly mit 512 x 512 Pixeln überhaupt nicht dargestellt. Der FS würde sie nur als 256 x256 darstellen. Leider wird die Gewerbe.bmp allerdings in keiner anderen BGL zugewiesen so das ich davon ausgehe das diese auch über VTP2 Poly zugewiesen werden sollte. Nur mit der asphalt_Wi.bmp als Wintertextur anstatt einer Gewerbe_Wi.bmp da ist Dir bestimmt ein Versehen unterlaufen.

Das allein dürfte den Fehler aber nicht auslösen sondern eher etwas anderes. Ich tippe mal auf einen Sachverhalt den ich bei meinem Patch beachtet habe. Hier der Auszug aus dem Terrian SDK des FS2002. Ich weis nicht ob Du diesen kennst. Problem ist ja immer das man eigentlich bei Ground2K nicht mehr ins SDK schauen muß. Ev. schenkt das Tool Ground2K diesem Punkt allerdings keine Beachtung.

Der original SDK Auszug:

To take full advantage of Flight Simulator 2002, you will want to create seasonal texture variations. To allow Flight Simulator to determine the correct seasonal texture, the above format has been expanded to allow comma-delimited texture lists to define the seasonal texture names. If you choose to have seasonal textures, all of the following seasons must be included in the following order: winter, hard winter, spring, summer, fall, and night.
An example of a set of seasonal road textures:
char szTextureNameList[] =
"DirtRdWi.bmp,DirtRdHw.bmp,DirtRdSp.bmp,DirtRdSu.b mp,DirtRdFa.bmp,DirtRdNight.bmp\0\x03\x04"\
"MinorRdWi.bmp,MinorRdHw.bmp,MinorRdSp.bmp,MinorRd Su.bmp,MinorRdFa.bmp,MinorRdNight.bmp\x03\x04"\
"MajorRdWi.bmp,MajorRdHw.bmp,MajorRdSp.bmp,MajorRd Su.bmp,MajorRdFa.bmp,MajorRdNight.bmp\x03\x04";

Note: the night texture is used during night regardless of the season.

So nun wirst Du sagen ich möchte ev. gar nicht alle Jahreszeiten. Dann schau Dir mal als Beispiel die Terrain.cfg an. Hier werden alle Jahreszeiten durchdefiniert. Da wo z.B keine Herbst Textur genutzt werden soll wird als Platzhalter einfach die Sommertextur eingesetzt. Das sieht dann z.B so aus.

Textures=rbankNPwi.bmp,rbankNPhw.bmp,rbankNPsu.bmp ,rbankNPsu.bmp,rbankNPsu.bmp

Wie gesagt auch die Reihenfolge ist wichtig zumindest wenn man für jede Jahreszeit eigene Texturen nutzt.

Ich habe es so gemacht und habe zusätzlich gleich die Nachttextur mitgeliefert so war ich 100% SDK konform.

Habe das Speicherleck nicht im FS2002 getestet. Ich schliesse aber nicht aus das sich nur der FS2004 so pingelig verhält. Daher der Bug ev. nur im FS2004.

Diesen Nachsatz \x03\04 aus dem SDK kannst Du erst mal vergessen. Was mir auch noch einfällt ist das normalerweise die Texturen für VTP Polys sei es Landclass bzw. roads usw. im Pfad X:\FS2004\Scenery\World\Texture sitzen. Ev. könntest Du das auch noch checken ob dieses ein Änderung bringt. Ohne FS2004 Terrain SDK kann man ja leider nichts genaues darüber sagen wie es der Herr FS2004 gerne wünscht.

Aber auch mit werden wie immer Geheimnisse bestehen bleiben.

Zunächst mal würde ich aber das mit der Gewerbe.bmp und aphalt.bmp usw. testen. Schlieslich ist im Namen Gewerbe.bmp schon mal generell keine Jahreszeit definiert.

Habe momentan wenig Zeit. Ist auch alles offline geschrieben. Kann es selbst nicht testen da ich momentan kein Zugriff auf den FS habe.

Kannst ja mal ausprobieren anhand dieses Sachverhaltes auf welche BGLs diese Problematik mit eigenen Texturen zutrifft. Ev. funktioniert es bei Bereinigung der BGLs auch wie gehabt, also so das die Texturen im Haupttextureordner bzw. Landclasstextureornder sitzen.

In der Texturliste des ASM Codes ist als Trennzeichen glaube ich anstatt des Kommas das Simikolon zu setzen. Das macht Ground2k aber richtig denke ich. Dazu kann ich jetzt leider nichts genaues sagen ob nun Komma oder Simikolon richtig ist. Da müßte ich auch erst nachsschauen. Habe wie gesagt momentan keinen Zugriff auf meinen PC.

Kannst das ja mal testen.

Gruß Joachim