Flugberti

Mal eine Gegenposition. Wenn Du ein Schnitzel im Restaurant bestellst, erwartest Du dann auch , stets ein weiteres auf Deinen Teller zu bekommen? Oder gehst Du davon aus, dass "einmal gezahlt" = "einmal Schnitzel geliefert" bedeutet? Ein "All you can eat" wäre von Anfang an kommuniziert und (anders) bepreist. Ein Add-on kostet einmalig einen wirklich nicht allzu hohen Betrag. Wenn daraus eine dauerhafte Pflicht für den Ersteller erwachsen soll, einen komplexen Airport stets und über Jahre aktuell zu halten, dann ist das meines Erachtens ein bisschen viel verlangt. Du zahlst einmal 20, 30 oder 50 Euro - und wie viele Jahre soll dann der Ersteller verpflichtet bleiben, das Add-on zu updaten? Im professionellen Bereich gibt es so etwas. Es nennt sich "Softwarepflege". Da zahlen Kunden dann aber dauerhaft, also fortgesetzt Geld. Ehrlich gesagt gehen ja MSFS und X-Plane mit ihren Marktplätzen und dem vorbereitete DRM in die Richtung. Dann kannst Du dauerhafte Updates verlangen - Dir muss nur klar sein, dass Du dann dauerhaft für eine Add-on vielleicht 5 bis 10 Euro im Monat zahlst.

Hier mal die amtlichen Infos

„Texture usage is 4.74 gb out of 4.71 gb available.“

Bei mir ist's sehr schön realistisch eingeschneit. Ich meine, ich habe das hier: GitHub - hotbso/xa-snow: Show accumulated snow on X-Plane's scenery.

Also, zunächst einmal machen die Bilder, bzw. die Bildquellen selbst ja einen erheblichen Unterschied aus. Nach einigen Experimenten halte ich auch Bing für am besten geeignet, da hier die Farben besonders konsistent über große Räume sind. Es hilft mir nichts, wenn Google hier und da klarer oder aktueller ist, aber bei klarer Sicht alles ein Flickenteppich ist; einen solchen Flickenteppich würde ich auch gar nicht erst versuchen, zu reparieren, denn die Verläufe der Farbgrenzen sind ganz unterschiedlich - teilweise entlang von Kreisgrenzen und nach entlang der Kacheln. Das müsste man alles von Hand machen ... Ich hatte mit Bing lediglich die Sättigung ein bisschen in O4XP runtergedreht. Wie Andre schreibt, geht das quasi automatisch und ist hier im Forum und anderswo beschrieben. Es sind einfach die Befehle, die auch bei TheGimp Farbänderungen durchführen. Ob man das alles braucht, ist aber so eine Sache. Im Verlauf von XP12 hat sich bis hin zu XP12.4 die Rendering-Engine gerade beim Lichteinfluss so stark verbessert, dass ich mir die Zeit eher sparen würde, da an den Bildern etwas zu machen. M.E. stehen hier Aufwand und Nutzen in keinem sinnvollen Verhältnis. Auch müsste man bei jeder Änderung von XP, die die Landschaftsdarstellung verändert, wieder nachjustieren. Klar, für Einige ist XP eher wie eine Modelleisenbahn: Es geht mehr ums Basteln als ums Fliegen. Aber auch Basteln sollten ja sinnvoll bleiben. Interessant ist eher, was man mit dem Wasser macht. Es kommen ja bald gute Brücken und Schiffe. Da würde ich dann eher dazu übergehen, Inlandsgewässer nur mit XP-Wasser darstellen zu lassen und keine Luftbilder einarbeiten zu lassen, auf denen dann statisch Brücken und Schiffe wären. Das ist für mich aktuell der einzige Grund, Luftbilder nach einigen Jahren (mit einem guten Höhenmodell!) neu zu machen.

Naja, auf AGL bezieht sich das nur teilweise. Eine "height" bezieht sich immer auf die Höhe über Grund, also bei Decision Height sowie Minimum Descent Height. Die ebenfalls im verlinkten Manual erwähnte "Altitude" ist in der Fliegerei immer die Höhe über NN auf Basis des auf Meereshöhe reduzierten Luftdrucks. Die Decision Altitude und Minimum Descent Altitude beziehen sich also auf NN, nicht auf AGL. Der auf Meereshöhe reduzierte Luftdruck wird in der Fliegerei unterhalb von Transition Level (im Sinkflug) und Transition Altitude (Steigflug) benutzt und heißt "QNH". Möglicherweise meint PH1973 das mit dem "hPa-Wert". Um die Verwirrung noch größer zu machen, zeigt der Screenshot eine QNH-Eingabe aber in inHg, nicht in hPa. Das lässt sich aber in der Realität in praktisch allen Maschinen umstellen; bestimmt auch beim Airbus.

Ja, ich kenne mich mit einem Airbus zwar nicht aus, das da steht doch sicherlich die Minimum Descent Altitude oder die Decision Altitude? "Final" bezieht sich doch nicht auf den Flughafen, oder? Wenn wenn, wäre es dann die Höhe beim Airport Reference Point oder bei der Runway Threshold?

Ne, wie XP verschiedene Kerne für verschiedene Aufgaben wie Flugmodel, AI-Flieger, ATC, Laden der Szenerie ... nutzt, ist Kern von XP. Das ist keine Konfigurations-Option einer Szenerie. Natürlich kostet Simheaven mehr Rechenleistung als die Standardszenerie. Wenn Du bei Simheaven (nun?) im Vergleich zur Standardszenerie größere Einbußen verspürst, war bei der Standardszenerie das bisher schlechte Multi-Threading bisher der Flaschenhals bei Dir - deshalb gibt es dort einen Performance-Gewinn. Wenn Du den bei Simheaven nicht hast, ist etwas anderes der Flaschenhals bei Deinem Rechner. Vielleicht das RAM, vielleicht ... XP hilft Dir ja mit der Datenausgabe gut, um den Flaschenhals zu verstehen. Schau Dir das doch einmal. Ist es GPU, CPU, RAM ...?

Klar ist die Darstellung des Wassers im Ausgangspunkt davon abhängig, was bei Openstreetmap.org als Verlauf gezeichnet ist. Schlechte Erfahrungen habe ich damit nicht gemacht. Deine Screenshots sind interessant: Mir erscheint das Wasser da sehr unauffällig. Sprich, ich sehe gar nicht, was mich da stören würde.

Ich habe wirklich noch niemals aus einem Flugzeugcockpit heraus darüber nachgedacht, was Personen außerhalb des Flugzeugs an Kleidung tragen. Aber wenn man einmal darüber nachdenkt, ist vielleicht die Uhrzeit hier der wichtigste Trigger: Stehen da um 3:00 Uhr nachts die selben Personen wie um 12:00 Uhr mittags? Personen bei Nacht oder bei Regen oder Schnee auf vielleicht 10 % auszudünnen wäre vielleicht eine einfachere Lösung. Das Thema mit der Kleidung ist natürlich nicht unberechtigt. Aber ich fürchte, da macht man ein Fass ohne Boden auf: Jahreszeiten, regionale Unterschiede, Wechselwirkung mit dem Wetter… da würde meines Erachtens der Entwicklungsaufwand in eine ganz falsche Richtung fließen. Ein Flugsimulator sollte kein Sims werden.

Ja, das möchte ich auch betonen! Hmkaiser hat hier Großes geleistet! Neulich hatte ich mich in Süddeutschland gewundert, weshalb die Vektorstraßen fehlten und nur die Straßen der Luftbilder sichtbar waren. Tatsächlich waren es aber die Vektorstraßen! Ich hätte nicht gedacht, dass sie optisch so gut werden und wirklich nicht mehr künstlich und aufgesetzt wirken! Früher hatte ich auf Vektorstraßen verzichtet. Aber dank hmkaiser ist es mit Straßen nun besser. Neben Vorteilen wie Brücken und Verkehr ist vor allem jetzt in der dunklen Jahreszeit die Beleuchtung ein echtes Argument. Ich bin für die Arbeit wirklich dankbar!

Genau. Am GNS530 steuert der CDI-Knopf das Signal, das aus dem GNS530 heraus auf das jeweils verbaute, unabhängige HSI oder CDI gelegt wird. Dabei steht HSI für Horizontal Situation Indicator und CDI für Course Deviation Indicator. Die jeweilige Kursabweichungsnadel im Cockpit zeigt mir dann an, um wie viel ich vom eingedrehten Radial (VLOC im GNS als Quelle) oder vom GPS-Kurs (GPS im GNS als Quelle) abweiche. Im Alltag möchte ich einen programmierten Kurs abfliegen; dann soll das GPS als Quelle für die Kursabweichung dienen. Heute fliegt man ja nicht mehr von VOR zu VOR. Nur wenn ich ein VOR/Localizer (VLOC) anfliegen will, wähle ich den anderen Modus. Letzteres macht in der Praxis nur noch Sinn, wenn man einen ILS-Anflug macht. Die GNS430/530 lassen sich auch so konfigurieren, dass sie automatisch umschalten. Es ist also bis hierhin alles nur eine Frage der Anzeige! Was der jeweils verbaute Autopilot daraus macht, hängt von dessen Fähigkeiten ab. Und vom gewählten Modus. Die S-TEC-Serie ist also kein „Navigationsgerät”, sondern verschiedene Autopiloten (S-TEC 30, S-TEC 55). In ganz einfachen Fliegern kann der Autopilot vielleicht nur eine Richtung halten, bessere können auch eine Höhe halten. Allgemein ist es ja so, dass die Ausstattung von Flugzeugen sehr viel unterschiedlicher ist als die von Autos. Häufig werden Dinge nachgerüstet und modernisiert. In XPs Beech Baron ist das jedenfalls auch kein S-TEC 55, sondern ein ziemlich altes Modell. Wenn der Autopilot einen Approach-Mode hat, fliegt er Localizer und Glideslope ab. Solange die Maschine kein Autothrottle hat, muss der Pilot aber weiterhin mit dem oder den Schubhebeln die Leistung so setzen, dass die errechnete Anfluggeschwindigkeit (V-Target) anliegt.

Hallo zusammen, sehe ich das richtig, dass es diese Szenerie nicht mehr gibt? EDBK Bonn-Hangelar für XP12 von HueyPilot - Szenerien - VFR-Flightsimmer - Flusi.info Anderswo vielleicht noch? Und was ist der Grund? Andere Szenerien von Huey gibt es ja noch auf ORG. Beste Grüße, Flugberti

Vier Sätze habe ich verlinkt. Es tut mir leid, wenn Dir das zu viel Durchackerei abverlangt hat. Hier habe ich es von vier auf zwei Sätze reduziert. Im Kern ist das die Aussage: „I had 2 network devices activated in the settings. […]. After removing them I gained back 8-10 FPS.“ Falls Dir das jetzt auch zu kompliziert sein sollte, habe ich jetzt extra noch diese zwei Sätze in DeepL für dich ein kopiert: „Ich hatte in de Netzwerkeinstellungen zwei Netzwerkgeräte aktiviert. […] Nachdem ich sie entfernt hatte, gewann ich 8–10 FPS zurück“

Habe dieses WE meinen neuen Rechner in Betrieb genommen und war doch recht enttäuscht über die Performance. "Kann doch gar nicht sein, dass XP12.3 so ein FPS-Killer ist." Dann bin ich auf diesen Bug gestoßen: https://forums.x-plane.org/forums/topic/335849-123-poor-fps/#findComment-2944522 Die Funktion dann ausgeschaltet, hatte ich tatsächlich deutlich mehr FPS. Hurra! Es ist eine etwas spezielle Funktion, und wohl nicht jeder nutzt das. Aber schaut bei Euch einmal nach!