WCM Forum - Einzelnen Beitrag anzeigen

JOBIA · 19.02.2004, 05:32

Wenn ich Möglichkeiten sehe werde ich das bekannt geben. Momentan sehe ich da aber keine große Chance. Wenn wir ehrlich sind hat der FS momentan ja offensichtlich selbst Problem zu entscheiden was er denn nun anzeigen möchte oder soll. Siehe auch vertauschte Area16N Flattenpriorität. Das ganze Thema was du für wünschenswert hälst, welches aus meiner Sicht natürlich allen bei der Fehlersuche helfen würde ist mit Sicherheit auch nicht so einfach zu realisieren. Als Beispiel Area16N Flatten. Als ich diesen Bug entdeckt hatte habe ich zu Demonstrationszwecken in die Doku (die damals zu dem Flackerproblem des FS2002 auf meiner Homepage lag) ein Tesfile veröffentlich welches drei überlappende Area16N Flattenpolys enthielt alle mit unterschiedlichen Höhen. Hier konnte man den Bug genau erkennen. Speziell wenn man in der Scenerybiblothek die Priorität der Polys vertautschte. Fakt ist aber auch alle drei waren gleichzeitig aktiv.

Es würde uns also nichts nutzen wenn wird den Speicher auslesen könnten und hier erkennen würden die Dateien X bis Y sind geladen.

Nein wir müssten eine punktuelle Auswertung machen. Also was befindet sich exakt unter dem Refpoint des Flugzeuges. Nun ist es aber so das ich bei den VFR Airfields Vol 1 für den FS2004 unter anderem insofern mitgearbeitet habe um hier nach Möglichkeiten zu suchen einen möglichst geringen Autogenverlust im Bereich um die Scenerien zu erreichen. Quasi das Optimum herauszuholen.

Dabei mußte ich aber feststellen das es nicht immer der Refpoint des Flugzeuges allein ist der hier als Steuerbasis für eine Anzeige von Scenerydefinitionen dient.

Es sind auch die verschiedenen Sichtbedingungen. Daher dürfte das ganze Thema nicht einfach sein. Die vernünftigste Eingriffstelle wäre daher eigentlich bei der Information die zur Grafikkarte geht bzw. kurz davor. Jetzt müßte man rausfinden aus welchen Sceneryinformation sich diese Grafikinformation aufbaut.

Das dürfte nicht ganz einfach sein und würde meine Kenntnisse übersteigen. Ich denke dazu müßte man genaueste Kenntnisse der Programmierung des FS haben. Nur den Quellcode des FS wird uns bestimmt keiner in die Hand drücken.

Ev. helfen natürlich bereits weniger Informationen.

Zum Thema SDK gebe ich Dir recht. Zum einen waren schon sehr oft Fehler drin enthalten. Zum anderen hat es zum Thema Landclass schon im FS2002 so gut wie keine Informationen gegeben von daher sehe ich es fast so wie es Holger geschildert hat. Es wird vermutlich auch beim FS2004 nicht viel kommen. Deshalb interessiert mich ja auch gerade dieser Satz den ich oben aus der FlightXpress zitiert habe.

Bisher war es wie gesagt dürftig was im FS2002 SDK Stand. Danach hätte man allenfalls Grundtabellen erstellen können. (die übrigends für den FS2004 zum Teil nicht mehr gelten würden).

Diese ganzen Sonderformen wie bei verschiedenen Steigung wurden bisher immer unterschlagen in den Informationen.

19.02.2004, 05:32	#108
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	Wenn ich Möglichkeiten sehe werde ich das bekannt geben. Momentan sehe ich da aber keine große Chance. Wenn wir ehrlich sind hat der FS momentan ja offensichtlich selbst Problem zu entscheiden was er denn nun anzeigen möchte oder soll. Siehe auch vertauschte Area16N Flattenpriorität. Das ganze Thema was du für wünschenswert hälst, welches aus meiner Sicht natürlich allen bei der Fehlersuche helfen würde ist mit Sicherheit auch nicht so einfach zu realisieren. Als Beispiel Area16N Flatten. Als ich diesen Bug entdeckt hatte habe ich zu Demonstrationszwecken in die Doku (die damals zu dem Flackerproblem des FS2002 auf meiner Homepage lag) ein Tesfile veröffentlich welches drei überlappende Area16N Flattenpolys enthielt alle mit unterschiedlichen Höhen. Hier konnte man den Bug genau erkennen. Speziell wenn man in der Scenerybiblothek die Priorität der Polys vertautschte. Fakt ist aber auch alle drei waren gleichzeitig aktiv. Es würde uns also nichts nutzen wenn wird den Speicher auslesen könnten und hier erkennen würden die Dateien X bis Y sind geladen. Nein wir müssten eine punktuelle Auswertung machen. Also was befindet sich exakt unter dem Refpoint des Flugzeuges. Nun ist es aber so das ich bei den VFR Airfields Vol 1 für den FS2004 unter anderem insofern mitgearbeitet habe um hier nach Möglichkeiten zu suchen einen möglichst geringen Autogenverlust im Bereich um die Scenerien zu erreichen. Quasi das Optimum herauszuholen. Dabei mußte ich aber feststellen das es nicht immer der Refpoint des Flugzeuges allein ist der hier als Steuerbasis für eine Anzeige von Scenerydefinitionen dient. Es sind auch die verschiedenen Sichtbedingungen. Daher dürfte das ganze Thema nicht einfach sein. Die vernünftigste Eingriffstelle wäre daher eigentlich bei der Information die zur Grafikkarte geht bzw. kurz davor. Jetzt müßte man rausfinden aus welchen Sceneryinformation sich diese Grafikinformation aufbaut. Das dürfte nicht ganz einfach sein und würde meine Kenntnisse übersteigen. Ich denke dazu müßte man genaueste Kenntnisse der Programmierung des FS haben. Nur den Quellcode des FS wird uns bestimmt keiner in die Hand drücken. Ev. helfen natürlich bereits weniger Informationen. Zum Thema SDK gebe ich Dir recht. Zum einen waren schon sehr oft Fehler drin enthalten. Zum anderen hat es zum Thema Landclass schon im FS2002 so gut wie keine Informationen gegeben von daher sehe ich es fast so wie es Holger geschildert hat. Es wird vermutlich auch beim FS2004 nicht viel kommen. Deshalb interessiert mich ja auch gerade dieser Satz den ich oben aus der FlightXpress zitiert habe. Bisher war es wie gesagt dürftig was im FS2002 SDK Stand. Danach hätte man allenfalls Grundtabellen erstellen können. (die übrigends für den FS2004 zum Teil nicht mehr gelten würden). Diese ganzen Sonderformen wie bei verschiedenen Steigung wurden bisher immer unterschlagen in den Informationen.