Wenn es mal nicht genau das ist, was es regeln soll.

Vielleicht hat M$ ja den Frameratebegrenzer dazu gedacht, dass der User sich diesen Regler so einstellt, dass der Ablauf flüssiger ist, weil der FS aufgrund der begrenzten Frames nebenbei die Berechnungen o. ä. ausführen kann, wofür er sonst einige Frames gelegentlich auslassen muss, was eben diese Schwankungen und gelegentliches Ruckeln verursacht.

Zuzutrauen wäre es M$, dass sie das in ihrer "Doku" dazu eben etwas schöner verpacken.

Könnte man ev. noch so sehen. Sehr viele der Hilfetexte sind nicht immer eindeutig.


Nur der Satz unten aus der Hilfe ist eigentlich eindeutig:

"Ressourcen, die nicht zum Erzielen einer höheren Bildwiederholrate benötigt werden, stehen so für andere Aufgaben zur Verfügung, beispielsweise die Darstellung von Wolken oder entfernten Szeneriedetails."

Es muß sich demnach doch irgendetwas in der Scenery oder am Himmel tun.


Weiterhin.


Wozu dann diese definitiv nachweisbare 70% Kopplung UPPER_FRAMERATE_LIMIT und LOD_Target_Frames.


Was ist mit dem häufig gehandelten Tipp die 70% Kopplung zu umgehen in dem man UPPER_FRAMERATE_LIMIT direkt in der FS9.CFG auf unendlich setzt die LOD Target auf einen niederigen Wert z.B 15 oder sogar 10.

Bewirkt bei meinen Notebook nur das dieser wenn er mal genug Performance hat, weil man nur blauen Himmel im Steigflug sieht auch mal recht hoch in den Frames geht.

Ich kann aber wiederrum nicht erkennen das die Scenery durch den niedrigen LOD Target 10 länger scharf bleibt bzw. mehr Wolken zu sehen sind.

Wie gesagt ev. hat ja noch jemand anders eine eindeutige Beobachtung das bei ihm definitiv etwas hinsichtlich Detailregelung bei Framevorgaben erkennbar ist.

Wenn nicht gehe ich davon aus das bei mir nichts faul ist, sondern das bei niemanden so eine in der Hilfe erwähnte Funktion nachweisbar ist.



Ev. passte dieser Tipp der in Foren immer wieder erwähnt wird nur für den FS2002. Wie es in Foren so üblich ist wird dann automatisch davon ausgegangen das er auch im FS2004 etwas auslöst.

So taucht er immer wieder auf, löst aber eigentlich nichts aus.


Dadurch das der FS durch die Vielseitigkeit der Scenerien sehr unterschiedlich stark belastet wird, glaubt der Anwender er kann eine Auswirkung erkennen. Dem ist aber ev. überhaupt nicht so. Andere Uhrzeit andere AI Traffic Belastung oder andere Gegend bedeutet andere Landclassverteilung bzw. anderes Mesh, bedeutet wiederrum andere FS Belastung hinsichtlich Details.

Bestes Beispiel das wir öfters etwas glauben zu sehen was nicht funktioniert ist doch z.B das Thema Mesh.


Vor dem FS2004 Patch konnte der FS2004 definitiv keine LOD11 Meshfiles als solche darstellen. Hat es jemand gemerkt?


Nein, ich übrigends auch nicht. Ich hatte nur festgestellt das irgendetwas beim FS2004 beim Mesh anders ist. Aber das er LOD11 nicht kann, habe ich auch nicht gemerkt. Nach dem FS9.1 Patch kann er jeden Höhenpunkt eines LOD11 Mesh optisch darstellen.


LOD11 ist aber die Obergrenze.

LOD12 oder gar LOD13 Meshfiles kann er auch nach dem FS9.1 Patch nicht als solche darstellen. Trotzdem werben immer noch einige Anbieter mit Ihren Supermeshfiles die eine Auflösung 9 Meter oder besser haben.

Da wird der Anwender (ev. auch aus Unwissenheit der Produzenten) veräppelt.



Sehr schön auch immer das Flimmerproblem von Texturen. Habe bei meinen ATI Radeon Treiber folgenden Sachverhalt bewiesbar festgestellt. Je nach Einstellung des Mipmap Detailebene Reglers im Treiber wird ungefragt trilineares Filtern zusätzlich aktiviert. Das ganze schwankt nach Einstellung der Qualitätsstufen und Einstellung der Grafikkartenauflösung.

Es ist in 3D Foren bekannt das bei Treibern nicht nur sehr viel verbessert, sondern auch im Hintergrund auf Kosten der Qualität gemauschelt wird.

Von daher wundert mich diese ganze Diskussion bezüglich Texturflimmern eigentlich auch nicht.


Anwender mit identischen Treibern hätten für mein Beispiel mit dem trilinearen Filtern oben unterschiedliche Flimmerprobleme bei Texturen nur weil Anwender A mit 1024 x 768 Pixeln Anwender B mit 1280 x 1024 Pixeln fliegt. Das ganze dadurch das bei dem einen trilinear gefiltert wird bei dem anderen nicht. Der ein oder andere stellt jetzt bei einem neuen Treiber fest das auf einmal das Flimmern stärker oder schwächer als beim Vorgängertreiber ist.

Die Wahrheit könnte aber auch sein das ev. nur eine vorher nicht beachtete Einstellung des Treibers nach dem aufspielen anders ist.


Ev. auch eine undokumentierte Eigenschaft(Fehler?) wie z.B dieses ungefragte trilineare Filtern.


Das ist nur ein Beispiel was alles mit reinspielen kann, denn auch die Performance fällt durch so etwas ev. verschieden aus.

Jobia,

da spielt auch noch etwas anderes in den Parameter hinein.
Wo eine Begrenzung sich eindeutig und nachweisbar auswirkt ist beim online-Fliegen.

(Jetzt von mir nur an den Auswirkungen überprüft, andere sollen dies anhand des Datentraffics überprüft haben.)
Bei unlimitierten FPS führt dies zu einem ständigen Senden von Datenpacketen. Diese können von den anderen Clients nicht mehr schnell genug verarbeitet werden, mit der Auswirkung, dass die Mitspieler anfangen zu springen. Sobald wir eine Target-Frame von irgendwas bei 20-30 haben, fliegen die Flugzeuge der Mitspieler wieder flüssig. Wobei es reicht, wenn nur ein Spieler den Regler auf unlimitiert stehen hat.

Ansonsten habe ich bewußt auch noch keinen wirklichen Einfluss fest gestellt.

Zu online Fliegen kann ich überhaupt nichts sagen.

Aber dieser Effekt mit dem etwas flüssigeren beim online Flug bei den anderen Mitspielern bei einer Begrenzung der Frames zeigt einen ähnlichen Sachverhalt wie ich ihn bei meinem 3,4GHz habe.

Direkt vergleichen kann man es allerdings nicht.

Aber auf jeden Fall eine Einstellung die auch gegen die üblichen Tipps der unendlichen Frameeinstellung beim FS2004 spricht.



Mich wundert ehrlich das niemand diesen Original Microsoft Hilfe Text in irgendeiner Form direkt bestätigen kann.


Zum einen weil es offensichtlich bestätigt das keiner solche Auswirkungen nachweisen kann, was bedeutet das irgendetwas am FS faul ist.

Zum anderen weil viele mit irgendwelchen auf Tipps basierenden Einstellungen durch die Gegend fliegen wo sich keiner sicher ist das wirklich etwas positives passiert.


Aber Ok das kennen wir ja auch von den Tipps zu den Terrain_Default_Radius und Terrain_Extended_Radius hier arbeitet man ja auch mit Werten über 4 die beim FS2004 definitiv nichts mehr auslösen.

Habe ich mittlerweile anhand Testdateien bei ein paar Leuten vor Ort beweisbar kontrolliert.

Werde jetzt mal testen wie es sich bezüglich der Framevorgaben beim ungepatchten FS2004 bzw. beim FS2002 verhält ev. ist dort ja etwas erkennbar.

Übrigends was diesen Thread betrifft.

Wie lange wird es das Forum noch geben

Es war eben 4 Uhr 40. Ich weis nicht wo der Server für das Forum steht.

In Deutschland sollte aber nicht viel Traffic los sein.

Es hat eben auch mal wieder sehr lange gedauert bis mein Text im Forum erschien.

Hallo !

So intensiv hab ich mich mit dem ganzen noch nicht auseinandergesetzt, aber mir is eins aufgefallen. Hier ist immer von einem Framerateregler die Rede. Ich sehe dieses Ding einfach als Begrenzer, und wenn man's als Regler bezeichnet, hat man vielleicht einfach höhere Erwartungen. Meiner Ansicht nach steckt da überhaupt nix anderes dahinter, als große Framesprünge zu vermeiden. Wer schon einmal aus dem Cruise bei 40 fps auf einem Addon Airport gelandet is, wo man vielleicht noch 15 fps kriegt, der weiß, dass es viel besser is, nur 20 bis 25 die ganze Zeit zu haben, weil einem der Einbruch dann einfach nicht so vorkommt. Also ich würde diese Einstellung nicht überbewerten, schon gar nicht so, dass gar irgendwas abgeschaltet würde, nur um mehr fps zu erreichen. Auch die ganzen Erklärungen mit "mehr Rechenzeit für andere Dinge" find ich ziemlich suspekt. Wenn ich mir die CPU Auslastung bei meinem Rechner während des FS anschaue, kann ich über "freie Ressourcen" nur Lachen. Und ich denke mal, mit all den Addons die teilweise laufen, wird es dem überwiegenden Teil von Usern auch nicht anders gehen.
Alles in Allem finde ich die Begrenzung nicht schlecht, solange man keine Wunderdinge erwartet, die sie ja auch gar nicht liefern kann. Wie gesagt, das is meine Meinung als reiner Anwender. Wenn man so will, sehe ich den FS also ziemlich oberflächlich, im Gegensatz zu Jobia und einigen anderen hier.
vg martin

Genau das was Du schreibst ist auch nur das, was bei mir nachweisbar feststellbar ist.

Nichts von dem was Microsoft erwähnt passiert bei mir.


Ich hatte die Frage auch nur ins Forum gestellt weil


A) Microsoft in der Hilfe was anderes schreibt.

B) weil das was ich festgestellt habe sich mit Deinem deckt (nicht mehr und nicht weniger) und irgendwie die Tipps die gehandelt werden in Frage stellt.


Aber lassen wir das, es kommt glaube ich eh nichts bei rum außer das die Funktion so wie beschrieben nicht funktioniert.

Na ja und die meisten Tipps....... sehe ich ja immer wieder, werden eh nicht hinterfragt oder getestet.

Ja, bitte Gnade. ;) Du hast ja ganz recht. Manch einer der Tipps stammt noch aus der FS2002 Umgebung und es ist ja so einfach diese ungefragt weiter zu leiten. Auch andere Tipps - das wird auch nicht nach deiner Doku aussterben. Solange kein Tipp reproduzierbar extrem SCHLECHTERE Ergebnisse erziehlt wird das weiter leben.

Ehrlich gesagt warte ich schon sehnsüchtig auf deine Ergebnisse, so weitgehen wie du diese Regler testest macht es wohl kein anderer. Darum ist deine Arbeit auch so wichtig. Also drann denken wenn die Lust mal wieder fehlt: Es gibt zumindest eine Person, die sehr gerne deine Doku sehen will und auch die Arbeit sieht, die dahinter steckt. :)

Make that 2! :cool:

Wir haben ja auch noch einen anderen aktuellen Thread wo diese Parameter erwähnt werden.

Da ich für Gassa sein Problem eh eine den FS extrem belastende Landclasscenery erstellen musste habe ich diese gleich mal zum testen genutzt.

Ich habe sowohl im FS2002 als auch im FS2004 getestet.


Dabei ist mir aufgefallen das bei beiden FS Versionen die 70% Regel gilt, das war eigentlich auch klar. Stelle ich UPPER_FRAMERATE_LIMIT=20 ein erhalte ich bei beiden Versionen LOD_Target_Frames=14, stelle ich UPPER_FRAMERATE_LIMIT=30 ein erhalte ich bei beiden FS Versionen LOD_Target_Frames=21


So weit so gut.

Mache ich aber bei beiden FS Versionen einen sofortigen Wechsel im Displaymenü auf unendlich, dann wird UPPER_FRAMERATE_LIMIT=0 gesetzt.


So wurde die Stellung unendlich ja auch bei den Tipps interpretiert.

Was aber schon mal überhaupt nicht witzig ist das bei beiden FS Versionen dann keinerlei Änderung bei LOD_Target_Frames= erfolgt.

Dieser Wert bleibt auf dem zuletzt eingestellten Wert hängen.

Von daher müsste man eigentlich überhaupt nicht in der FS2002.CFG bzw. in der FS9.CFG rumwursteln.

Man kann es durch gezielte Einstellung auch direkt im Displaymenü einstellen.

Aber das ist alles uninteressant und unwichtig.


Wichtiger sind diese Tipps mit der dazugehörigen Interpretation.


Ich gebe zu ich habe das damals auch geglaubt und meinen FS2002 mit diesen Einstellungen gefahren.

Nach genauer Prüfung und Simulation im FS2002 und FS2004 kann ich aber schon mit ziemlicher Sicherheit sagen das dieses wohl eine der größten Enten sein wird der man beim FS aufgesessen ist.

Kurios weil die Hilfe von Microsoft zwar nicht das aussagt was bei diesem Tipp immer hereininterpretiert wurde, aber immerhin deutet sie einen Regelprozess von Elementen anhand der Frameratevorgabe des Anwenders an.

Den kann ich aber sowohl beim FS2002 und FS2004 bei keinem meiner PCs nachweisen.

Das einzigste was nachweisbar ist, habe ich bereits zuvor erwähnt.

Nämlich das der FS auf die Framevorgabe des Displaymenüs abriegelt insofern er technisch in der Lage ist diese zu erreichen. Auch das er flüssiger mit einer erreichbaren Framevorgabe läuft als wenn man ihn auf unendlich stellt wo es dann zu heftigen Frameschwankungen kommen kann.

Mittlerweile deuten immer mehr Leute an (zum Teil auch über Mail) das sie diese normalerweise erwarteten Regelprozesse anhand der Framevorgabe nicht nachweisbar erkennen können.


Von daher hat sich das für mich mit dem ominösen immer wieder auftauchenden Tipp erledigt. Es löst zumindest bei mir und auch bei anderen Leuten nichts nachweisbares aus.

Zumindest hat bisher noch keiner geantwortet der sagt:

"Ja ich kann eindeutig erkennen das wenn ich die LOD_Target_Frames ganz niedrig ansetze z.B 10 dann bleiben meine Bodentexturen scharf solange die Frames über 10 liegen. Stelle ich sie auf 20, dann werden die Texturen unscharf ab dem Moment wenn der FS die 20 nicht mehr erreicht."

Ich denke das einzige was man erkennen kann, dass ab einer gewissen Belastung je nach Performance des PCs, Texturen unscharf werden. Mit einer Framevorgabe konnte es bisher offensichtlich niemand glaubhaft regeln.