Was sich hinter dieser Abkürzungsorgie versteckt? Ein Tool, dass die Fiber_Frame_Time_Fraction dynamisch regelt. FFTF ist standardmäßig (auch wenn nicht explizit in der P3D.cfg) mit 0.33 angesetzt. Dieser Wert regelt das Verhältnis inwiefern die PC-Ressourcen für Frames (FPS) oder Texturladen veteilt werden. Setzt man den Wert z.B. auf 0,1, dann hätte man wesentlich bessere Frames, aber bei nicht 100% aktuellen Rechnern auch die gefürchteten “Blurries”, also unscharfe Texturen.
Nun würde man aber am Boden eines großen Airports durchaus gerne mehr Frames haben, auch wenn die Umgebung nicht gestochen Scharf sein sollte, was ja egal ist, da man sie eh nicht sieht. In der Luft wiederum sollten sich die Frames eh wieder erholen und der FFTF Wert könnte sogar nach oben geschoben werden, um die Texturen schnell zu laden.
Hier greift nun das FSPS Tool und kann den FFTF Wert dynamisch regeln. Hierzu gibt es zwei Einstellungsoptionen: entweder auf die Frames bezogen (also niedrige Frames, FFTF nach unten) oder von der Höhe des eigenen Flugzeuges über Grund (also nahe des Boden (Anflug) niedriger FFTF Wert, in größerer Höhe dann mehr)
Das FFTF Dynamic P3D Tool von FSPS gibt es im simMarket, aber nur für P3D 1,2 und 3. Nicht v4!
Man sollte auch hier noch darauf hinweisen, dass es nicht für P3D v4 ist.
Das entspechende Tool für Prepar3d4 gibt es aber direkt bei FSPS
https://www.fspsstore.com/fsps-products/fsps-fftf-dynamic-p3dv4.html
und vermutlich auch irgendwann im Simmarket.
Hallo Philipp,
vielen Dank für Deinen Hinweis – ha, fast wäre ich darauf reingefallen und hätte mir das Teil gekauft ohne zu wissen, dass es gar nicht für den P3Dv4.2 ist.
Sorry, an die Moderatoren: hier wäre tatsächlich ein Hinweis sehr nützlich gewesen – so bleibt jetzt ein kleines “Gschmäckle” – ist nicht böse gemeint, kommt aber so nicht gut!
Also alles auf null, nix wird gekauft!
Danke, das ist in der Tat ein wichtiger Hinweis. Ich habe das tatsächlich auch übersehen. Zum Zeitpunkt der News-Erstellung war der große rote Warnhinweis auf simMarket noch nicht.
…und in dem ganzen Bericht sollte man nicht vergessen, dass FSPS weiterhin – auch bei ihrem neuen Produkt FFTF Dynamic – auf ihrem Online-Zwang bestehen.
” Requirements:
Up and running internet connection for activation and license checking of the product on each application’s start-up. ”
(von FSPS Seite: https://www.fspsstore.com/fsps-products/fsps-fftf-dynamic-p3dv4.html )
Haben sie schon so bei ihrem ” Fiber Accelerator” so gemacht, welchen ich damals für meinen FSX gekauft und diesen wichtigen Hinweis im Kleingedruckten überlesen habe.
(Anm: der Fiber Accelerator machte in etwa das Gleiche wie jetzt FFTF Dynamic. Nur ging dieser über den Ansatz es über die Frame-Rate zu regeln)
Man, habe ich mich damals grün und blau geärgert als ich eines Abends einfach mal ne kurze Runde im Sim drehen wollte, und das – um teures Geld von FSPS erworbene Tool – plötzlich nicht mehr anging, egal was ich auch versuchte. Bis ich dahinter kam, als ich nochmals auf ihre Seite ging, dass man jedes mal ONLINE sein muss, bevor das Tool gestartet werden kann.
Als ich FSPS damals meine Sachlage erklärt habe und ihnen mitteilte, dass ich dieses Tool n i e m a l s gekauft hätte, wenn ich das Kleingedruckte nicht übersehen hätte, haben sie natürlich wirsch und knapp abegelehnt.
FSPS: Für mich niemals wieder!
Herzliche Grüsse an alle 🙂
“FSPS: Für mich niemals wieder!”
Kann ich mich nur anschließen, hatte das auch mal gekauft.
Aber ich schließe mich da aus anderem Grunde an. Damals und heute auch , diese Art Software gehört in die Kategorie “RAM Optimierer” und ist so unnötig wie ein Kropf.
Das Einzige was das optimal regelt ist seine eigene Anzeige mit bunten Bildchen.
Also wer neuere Hardware hat braucht es gleich gar nicht und aus alter macht es auch keine Rakete.
Wer aber fest dran glaubt……..sieht sicher auch ein Ergebnis
Ich kann auch nur von solchen Tools warnen!! Blurries sind vorprogrammiert und die kann man auch auch gratis haben, wenn man möchte …
Da muss ich widersprechen. Dieses Tool hat mit RAM Optimierern oder “wir machen den PC schneller” überhaupt nix zu tun.
Es tut genau das, was auch beschrieben wird. Und das tut es nachweislich und auch gut. Ob es jemand braucht, kann jeder selbst entscheiden, ob der Preis gerechtfertigt ist, soll auch jeder selbst entscheiden.
Aber arbeiten tut es und das auch gut. Ich kann nur sagen, dass es sichtbar regelt und eben genau weil es arbeitet, wie es soll, gibt es eben keine Blurries.
Wer von Euch hat es schon ausprobiert, dass er es bewerten kann?
(wer es wegen dem Onlinezwang nicht kauft, das verstehe ich auch)
Ich habe das Tool (für Prepar3d4.2). Zunächst angenehm: Es läuft neben dem Simulator und kann unabhängig gestartet (oder auch nicht gestartet) werden. Irgendwelche fragwürdigen Einträge, etwa in die exe.xml oder in die prepar3d.cfg, schreibt das Tool nicht, sondern klinkt sich in Echtzeit per .dll in den laufenden Simulator ein.
Zunächst meine Ausgangssituation: Ich nutze einen 30-Hz-Monitor und habe i.d.R. fps auf unbegrenzt, VSync an und TP an, da der Simulator dann schön flüssig läuft – solange man 30 fps halten kann. Diese Einstellung entspricht meines Wissens einem FFTF-Wert von 0,01, egal, was in der prepar3d.cfg steht, der Wert wird bei dieser Konfiguration nicht ausgewertet. Das Tool bietet für verschiedene Konfigurationen zwei Modi, für meine ist es der AGL-Modus (oben im Bild rechts): Ich stelle die FFTP-Werte derzeit zwischen 0,01 am Boden für Leistung und 0.33 bei 5000 ft gegen Blurries ein.
Erwartungsgemäß ändert sich am Boden gar nichts, wer da also auf die doppelten fps hofft, wird enttäuscht. Mit der kleinen Cessna, mit der ich meist fliege, habe ich im Prepar3d4 an sich auch ohne das Tool keine Blurries (da ist der Prepar3d4 deutlich besser als die Vorgängerversionen) und brauchte das Tool gar nicht. Steige ich dagegen in ein schnelleres Flugzeug (etwa die 737 NGX), wurde der Boden beim Landeanflug schon manchmal verschwommen. Und in dieser Situation hilft FFTF Dynamic tatsächlich.
Die anderen Modi (z.B. für feste fps) habe ich noch nicht probiert.
Den AVSIM-Thread von Achiles habe ich von Beginn an verfolgt. Wie das bei AVSIM so ist, enthält er viel Wahres, manches Unsicheres, etlichen Unsinn und auch Streit, der mit dem Thema gar nichts zu tun hat.
Woran machst Du das fest? Hoffentlich nicht an dem was es anzeigt.
Blurries hatte ich in der v4 noch nie auch nicht mit der NGX über Berlin.
Wie gesagt ich hatten den Vorgänger , habe herzhaft gelacht (über mich selbst) und das Geld abgeschrieben.
Der Vergleich mit “RAM Optimieren” war nur dazu gedacht zu verdeutlichen, dass sowas auch Leute kaufen und sehen wie alles flüssiger oder besser läuft.
Gut, man muss nur lange genug an solche Software glauben, um es sich selbst zu bestätigen, dass es tatsächlich wirkt.
FFTF ist in Prepar3D 100% wirkungslos seitdem der Parameter Optimize Parts eingeführt wurde und auf 1 steht. Probiers einfach mal manual aus.
Es gibt ihn auch nicht mehr in der v4. Im Simstarter NG ist er unter den inoffiziellen Tweaks auch nicht mehr drin.
Dieser Hinweis ist ja echt interessant!!! – gibt es dazu auch was zu lesen? Bitte 🙂
Mittlerweile habe ich in P3D v4.2 meinen “Sweet Spot” gefunden – richtige Blurries habe ich auch schon lange nicht mehr.
Für mich war der Hauptansatz die richtige Balance zwischen “TEXTURE_BANDWIDTH_MULT” – “TextueMaxLoad” und “UPPER_FRAMERATE_LIMIT” zu finden (Frames im Sim gelockt).
Habe irgendwann FFTF komplett aus der .CFG gestrichen, weil ich damit keine nennenswerten Ergebnisse erreicht habe – würde also zu dem passen was Rainer oben erwähnt hat.
Ob FFTF im Hintergrund noch über den Default Wert von 0.33 herum werkelt (wie noch in P3D v3) kann ich nicht sagen – auf jeden Fall habe ich dazu im v.4 SDK nix
gefunden.
Beste Grüsse, K.
Ich bin gerade nochmal über Dresden geflogen und habe FFTF auf 0.99 gestellt Frameverlust kaum feststellbar und um überhaupt einen Ansatz von Blurries mit der PMDG zu bekommen bin ich auf 2400 Ft runter und dort mit 320 lang gekachelt. Dann kann man es provozieren. Ob dann das Tool noch hilft? Meine Meinung: Also wenn überhaupt, dann kann man sich einen Standardwert höher 0.33 (ohne nennenswerten Frameverlust) einstellen und wird nie in den Blurriebereich kommen.
P.S
Habe noch nen zweiten Flug gemacht mit 0.00. Irgendwie scheint er schon noch zu wirken, denn da erreiche ich Blurries., aber auch nur mit komplett Null, was man ja noch nie machen sollte.
Und hier noch der Praxistest händisch in JD Dresden, PMDG 737
FFTF=0.01 (1/3)
FFTF=0.99 (dreifach)
Unterschied Nothing bis minimal weder in der Framerate noch in der Varianz.
Das war früher ganz anders. Da sind die Frames entscheidend hoch oder runter gegangen und die Varianz hat sich auch extrem verändert. Wie man also mit der dynamischen Veränderung dieses Parameters entscheidende Ergebnisse erzielen will, wenn schon nicht mal die Extrema was bedeutend verändern , bleibt mir ein Rätsel.
Vielleicht erklärt es mir ja einer.
Mein noch schuldiger Praxistest steht leider unter Moderation. Wahrscheinlich wegen der Bilder , die geprüft werden müssen.
Jedenfalls gibt es in JS EDDC mit GES und der PMDG 737 weder nennenswerte Frameunterschiede Unterschiede mit FFTF=0.01 und FFTF=0.99, noch in der Varianz. Wenn also 1/ 3 (32.4 FPS)und dreifach (31.6 FPS) nichts Wirkliches liefert, wie will man dann dynamisch dazwischen etwas regeln. Vielleicht kann mir das ja mal jemand erklären, am Besten der Entwickler. Ich kann auch gerne nochmal in
3500 ft über Dresden düsen. Bezweifle , dass sich da irgendwas ändert.
In früheren Versionen des Sim war das nämlich deutlich anders.
Mit unbegrenzten Frames ist FFTF immer 0.01 was auch immer Sie in der Datei prepar3d.cfg platzieren.
Sehr gerne eine Quelle dazu …
Dass Du Dich da gleich so reinhängst, Rainer 😉
Ich habe spaßeshalber Deine obigen Bilder in Photoshop übereinandergelegt und sehe Deine Blurries mit 0,01 FFTF. Das dürfte sich sicher wesentlich verschärfen, wenn Du ORBX LOWI anfliegst. Hängt aber auch vom System ab. Wenn Du eine halbwegs moderne GraKa hast, dann reißt die das natürlich gut durch. Habe ich nicht.
Aber alles entspannt: weder ist es ein Wundertool, noch besteht Kaufzwang. Ich war vorher auch glücklich, wollte es nur mal ausprobieren und finde, dass in der ein oder anderen Situation nun bessere Frames sind bei großen Airports, wo es vorher geruckelt hat. Dies ist zweifelsohne durch ein niedriges FFTF zu erreichen. Mit diesem Wert, der mir an großen Flughäfen gute Frames bringt, hätte ich in der Luft dann aber Blurries (habs getestet). Und da greift das Tool dann eben ein.
Alles was recht ist, Rainer, aber wenn schon ein Test, dann richtig (Angaben zu Settings, Auflösung, nVidia Inspector Einstellungen etc.). Könnte ja sein, dass Du extern mit Vsync 1/2 oder gar nVidia Frame Limiter die FPS auf 32 lockst und deshalb keinen Unterschied mehr siehst? 😉 Zudem, sofern Du die Settings nutzt, welche Du auf Deiner Homepage empfiehlst, erstaunt mich nicht, dass Du wenig bis keine Blurries kriegst. Ich nutze bspw. etwas höhere Settings und bei mir ist der Effekt des FFTF absolut deutlich sicht- und spürbar, aber eben auch nur, wenn wie Achilles schreibt, die FPS im P3D nicht auf “unlimited” stehen. Ergo: deine Screenshots beweisen null und gar nichts… Das Tool reizt mich trotzdem nicht, da mein Ziel eine Config ist, die sowohl für slow and low als auch für IFR mit 737 und A32x funktioniert. Das ist aber eine persönliche Meinung.
Leut `s be cool, ihr könnt doch kaufen was ihr wollt und auch glauben was ihr wollt. Deswegen kann man doch hier diskutieren. Selbst wenn es nur gefühlt hilft, dann hilft es aus Sicht des Käufers immer.
@Günter
jpegs über photoshop zu vergleichen ist relativ witzlos, die haben nämlich immer Unschärfen. Und wenn Du sie erst dort überlagern musst siehst Du nichts auf dem Bildschirm im Einzelfall. Aber auch gut.
@Chris
Meine Homepage hat Ausgangsempfehlungen über 3 Bildschirme getestet für Eigenfindung, nicht mehr, wie Du dort lesen kannst
Generell testet man mit keinen Begrenzungen, weil sonst andere Parameter reinpfuschen.
Testbedingungen:
Ich nutze keinen NV Inspektor mehr mit der v 4.2
– System mit 800 GB Content
– Vsync off
– Frames unbegrenzt
– Autogen Vegetation extrem dense
– Autogen Gebäude very dense
– Road Traffic 10%
– Schiffe 25%
-AI 50% Eigenbau native v4 (entspricht 100% allen Verkehrs)
– 4xSSAA,
– GES, Vector , Open LC, JS Dresden ,PMDG 737
– CPU 4.3 Ghz , GraKa Takt 1900 bis 2010 bei 86 Grad max.
Ergebnis. Der Parameter hat keine bis wenig Wirkung, egal welchen Wert. Man muss extrem testen (Niedrigflug und hoher Geschwindigkeit) und zwar so, wie man nie fliegen würde, um was zu provozieren.
Es gibt den Parameter bei LM nicht mehr, auch nicht inoffiziell.
Ich mache es wie Du auch, nämlich eine config für mein System finden. An Blurries habe ich das erste mal wieder gedacht, als ich hier gelesen habe.
Ich persönlich fliege mit Simstartet NG und erstellten config Sets für verschiedene Anwendungsmöglichkeiten. Die Sets reichen von “Low” bis “very Hight” (Eigenbezeichnung) jeweils in den Varianten mit oder ohne EXP=10. Meistens fliege ich mit einem Hightprofil in dem sogar 8xSSAA drin ist. Ich fliege im Alltag über 3 Bildschirme immer mit unbegrenzten Frames und Ruckel- sowie Blurryfrei.
Unterstellt dynamischer FFTF bewirkt etwas, dann höchsten die Korrektur einer vorher nicht optimalen Konfiguration.
Wäre das noch ein ernsthafter Hit, hätte ihn LM schon lange wieder eingebaut.
*Klugscheißer an*
Also wenn Du wirklich sooooo pingelig genau sein willst, dann muss es schon richtig nachprüfbar, indempotent und nachvollziehbar sein. Ich denke da so an deployment mittels ansible (ich mag ja mehr puppet aber das wäre hier wohl zu umständlich) und inspec tests mit kitchen. Dann sind die Testergebnisse bei jedem auch immer wieder gleich. Der Sourcecode seiner Cloudcontainer sollte bei github oder visualstudio online liegen damit jeder helfen kann. Getestet wird dann in einer neutralen und bei jedem Nutzer gleichen Cloudinstanz (im Falle Azure dürfte Standard_NV6 ausreichen für DirectX Computing; wer VBox oder VMware Workstation hat kann auch da GPU’s emulieren). Und voila ist eine in sich geschlossene Testinstanz geschaffen wo keinerlei Auswirkungen von Fremdsoftware auftreten und man erhält vergleichbare Testergebnisse die das Wirken einer Software belegen oder widerlegen. So testest Du heutzutage (zumindest moderne und hippe Firmen in der Softwareentwicklung welche DevOps leben) ob und welche Fehler Deine Software enthält.
*Klugscheißer aus*
😉
https://www.avsim.com/forums/topic/533557-fsps-fftf-dynamic-p3dv4-released/
Wichtiger wäre eigentlich ein Tool, das die visuellen Features (Autogen, LOD…) zurücknimmt, wenn es mit den fps eng wird, und wieder zugibt, wenn wieder Luft im System ist, sodass ein minimaler fps-Wert gehalten wird. Für X-Plane gibt es so etwas – natürlich – schon lange. Das hört auf den schönen Namen “3jFPS”, hat zahllose Einstellungsmöglichkeiten, was man nun zurücknehmen möchte (u.a. auch Antialiasing), und kostet – man höre und staune – keine 24 Euro, sondern 0. Und es funktioniert.
Ja X-Plane hat den Vorteil. dass sich bestimmte Dinge on the Fly beeinflussen lassen. In P3D sind on the Fly Änderungen so gut wie nie möglich. P3D liest nämlich während des Fluges seine cfg nicht neu ein. Manipulierbar sind nur die bekannten Offsets.
Deswegen würde mich mal brennend interessieren (ohne Quelltext) über welchen API Call man P3D überhaupt bewegen will so was on the Fly zu tun. Eine dll ist nämlich nur eine dynamische Library und muss zwingend in die Hauptanwendung durch Aufruf eingebunden werden. Dann müsste aber auch P3D selbst dynamische Änderungsmöglichkeiten für den Zweck bieten.
Die einzige mir bekannte Anwendung ist AS P3Dv4 mit ASCA. Das funktioniert dynamisch weil man z.B. Wolken beim Nachladen smooth einbinden kann und damit auch extern erneuern.
Aber X-Plane schummelt auch. es verzögert nämlich schlicht die Simulation wenn es eng wird.
Bist Du mal die dll’s durchgegangen die der FSX bietet? Gibt ja auch etliche undokumentierte Klassen. Ich war bisher zu faul hier empirisch nachzustochern. Aber selbst wenn schreibst Du Dir eben eine eigene dll die benötigte Werte ausgibt. Alle dll’s im FSX Pfad werden beim Start geladen. Ich denke da so an paar Injections und über die dll kann man den fsx anweisen den Memoffset zu loggen um die ASLR zu umgehen. Mich durstet es reinweg der Analyse wegen das Produkt zu kaufen und dann die Funktionalität nachbauen und Source offenlegen. 😀 Aber Deutschland hat ja die EU Richtlinie 2016/943 noch nicht umgesetzt und so steht revEngineering rechtlich in einer nicht höchstrichterlich geurteilten Grauzone.
richtiger Konfigurationsartikel
https://www.fspsstore.com/blog/news/fftf-dynamic-p3dv4
Ich denke P3D v4 wird immer noch wie der FSX behandelt, nur hat er damit nichts mehr zu tun.
1. LM empfiehlt als Standard keine begrenzten Frames mehr in P3D v4.2, sondern unbegrenzt. Ich fliege nur so und auch ohne Probleme.
Eine Begrenzung ist deshalb bestenfalls extern sinnvoll, wenn ein System mit unbegrenzt nicht klar kommt.
2. P3D betreibt von sich aus Gegenmaßnahmen wenn es kritisch wird. So wird die Refreshrate des Flugzeuges auf 1 Sekunde hochgesetzt, wenn 18 Frames unterschritten werden und automatisch wieder hoch, sobald sich die Situation verbessert hat
3. In P3D kann man im Gegensatz zum FSX auch noch mit 15 Frames starten und landen.
Die Abläufe in P3D sind inzwischen völlig anders als im FSX und dies nicht nur weil es 64 Bit ist.
Hallo Rainer,
Du schreibst:
“LM empfiehlt als Standard keine begrenzten Frames mehr in P3D v4.2, sondern unbegrenzt.”
Das ist mir absolut neu. Gibt es dafür eine Quelle?
Gruß
Patric
Die Quelle ist der Sim selbst. Unlimited ist die Standardeinstellung bei Installation oder nach löschen der Prepar3D.cfg.
Das ist die, entschuldige bitte ich dachte Du wärst auch ein wenig IT Affin?, dööfste (welch eine geile Steigerung) Begründung für einen Standard die ich je gehört habe. Empfehlungen basieren immer auf empirischen Erkenntnissen und sind belegbar und dokumentiert, idealerweise von Tests belegt.
Mir fallen verschiedene Dinge ein, weswegen der Limiter raus ist:
– irgendwer hat irgendwann im Suff die Option eingebaut ohne dass es wem aufgefallen ist
– die arbeiten mit git und haben keine Ahnung und scheiß Branchingflow’s
– das Modul welches die Optionen festlegt initial funktioniert nicht (mehr) richtig
– es gibt bekannte Probleme mit gut zahlenden Kunden welche derartig gehäuft auftreten dass es kosteneffizienter ist diese Option standardmäßig auszubauen weil sie on großen Rechnerverbunden Probleme verursacht beim kleinen privaten Männlein mit seinem i7 aber eher nachteilig wäre
– siehe Punkt oben und zusätzlich gibt LM in einer Doku irgendwo, einem Supporthinweis oder irgendeinem versteckten Großkundenwiki noch die Empfehlung “bei kleinen Installationen externen Limiter nutzen oder idealerweise den ingame Limiter setzen”
….oder, LM hat sich gedacht (was ich persönlich eher glaube):
“Jetzt haben sich bei uns nach den letzten P3D Versionen soooooo vieeeeele Endkunden (auch wir gemeint) wegen zu schlechter Frames beschwert!
Wisst ihr was wir machen: wir schmeissen die Frames gleich auf unlimited, dann läuft im Sim die FFTF automatisch (was tatsächlich so ist) auf dem niedrigst möglichen Wert – nämlich 0.01 – TextureMaxLoad und TBM ist dabei auch gleich ausser Kraft gesetzt und die GRAKA muss (zwangsläufig) gleich von Anbeginn an die höchsten FPS ausspucken – und die CPU natürlich auch am meisten ackern; so kann sich keiner mehr wegen zu weniger Frames von Anbeginn beschweren.
Und Diejenigen, die WIRKLICH feintunen und auf ihr persönliches Set (CPU-GRAKA, etc..) abstimmen wollen, bekommen dafür nachträglich entsprechenden Support und weiterhin die Möglichkeit mittels KnowHow und Feintuning wirkungsvoll in die .CFG zu gehen um mit den wichtigen Werten zu jonglieren um brauchbare Ergebnisse zu erzielen. ” —> denke, das klingt plausibel.
Ich kann es in meinen Testszenarien beliebig oft wiederholen:
Wenn ich ingame die Frames auf unlimited setze und gleichzeitig von aussen begrenze (egal of Vsync ingame on oder off), selbst dann schnellt bei mit die Varianz (für mich noch immer der eigentlich WICHTIGSTE Indikator um einen geschmeidigen – smoothen Sim zu erreichen, da brauch ich gar nicht darauf zu achten wieviele FPS der Zähler ausspuckt) sofort auf durchschnittlich 5-8% Punkte nach oben – im Schnitt dann über 10% bis 14% – je nach Testszenario.
Wenn ich die Werte mit Hirnschmalz aber klug aufeinander abstimme (natürlich in Kombi mit der eigenen Hardware) und INGAME begrenze, dann geht die Varianz sofort runter auf deutlich UNTER 10% (genau: 1,2% – ca.8%) für alle meine Testszenarien (von mittel bis schwer), und auf ca. 10% dann immmer nur für ein paar Sekunden.
Was ich während der Simulation natürlich als deutlich smoother, weicher wahrnehme. Meine Erfahrung: schaltet (vor allem aus psychologischer Sicht) die FPS Anzeige am besten aus; und wenn tuning/tweaking in P3D sein muss, dann am über die Varianz. P3D kann auch mit Frames nur so um die 20 oder knapp darunter überraschend gut umgehen – oft sperrt sich aber der eigene Kopf/Wunsch dagegen, wenn man andauernd auf den Counter guckt.
Wenn jemand natürlich eine sehr potente Hardware zur Verfügung hat, dann hat dies den deutlichen Vorteil, dass man (der User) sich um solche Dinge weniger kümmern muss, weil diese mit ihrer Power mögliche Fehler in den Settings auf Grund der Performance sofort im Keim erstickt.
Ob dies für langfristig eine kluge Herangehensweise ist, sei dahingestellt.
Beste Grüsse an all.
So funktioniert Softwareentwicklung aber nicht. LM Denkt nicht. LM hat Mitarbeiter die denken und jeder seinen Job erfüllt. Es gibt Anforderungen welche festgehalten werden und vom Management sowie Kunden kommen. Daraus werden technische Aufgabenpakete für den Entwickler gebaut. Alle 2 Wochen (zumindest wo ich bei einem EU Rüstprojekt mal Einblicke erhielt) wird aufgeplant welche Aufgaben erledigt werden. Ein Teil dieser Aufgaben betrifft auch P3D. Jeder noch so kleine Änderung an irgendeinem Teil des Sourcecode wird mit dem jeweiligen Issue im Ticketsystem verknüpft und kommentiert was der commit grade macht. Die Entwicklung, Tests etc passieren im Hintergrund automatisch. Für die Betatester sowie Endnutzer werden Versionsstände (welche technisch hashes sind) getaggt und mit einer Version versehen. Wird ein Bug gemeldet wird für diesen ein weiteres Issue geöffnet und irgendwann aufgeplant und abgearbeitet. Das geht dann in einen Hotfixbranch welcher später mit dem Entwicklungsbranch und noch später dem Master welcher der stabilen Version entspricht gemerged.
Das alte Wasserfallmodell was noch in den frühen 2000’er Jahren genutzt wurde, wird selbst von eingefleischten AAA-Spielestudios schon lange nichtmehr betrieben. Test-Driven-Development ist die Devise. Jedes Stück Sourcecode und Funktion wird durch einen Testfall automatisch getestet. IBM’s Rational Function Tester, Ranorex nur um einige Programme zu nennen.
Das, was die Betatester testen sind typische DAU sowie Logikprobleme was Du eben nicht automatisieren kannst. Und selbst wenn sich einer bei LM Gedanken gemacht hätte, glaubst Du nicht, er hätte es in der aktuellen Dokumentation erwähnt? Zum Umsetzen von Aufgaben gehört nämlich auch gleich die Doku wenigstens kommentiert anzupassen. Und die sagt dazu nix. Weder im advanced (https://www.prepar3d.com/SDKv4/prepar3d/getting_help/advanced_configuration.html) noch im regulären Settingsbereich (https://www.prepar3d.com/SDKv4/prepar3d/options/graphics/display.html).
Also nicht so viel glauben, sondern Dinge kritisch hinterfragen insbesondere wenn viele hundert Leute involviert sind im gesamten Konzern.
….quod item esset demonstrandum 🙂 .
LG