Neuzugang im MSFS

Zitat von Der Merowinger

Ich dachte mir: genau das ist doch der Sinn des MSFS: Menschen für die Flugsimulation zu gewinnen! Bitte nicht böse sein: das wäre mit dem P3D nicht ansatzweise gelungen, der hat einfach nicht die Strahlkraft, Einsteiger zu begeistern.

Wo hast Du die Weisheit her...

Du musst doch Geld von MS bekommen...

Aber ist doch schön wenn es Menschen da draußen gibt die sich das antun. Hoffentlich erzählst du Ihm auch wie schön die alten Zeiten waren

Der P3D ist ja auch ein SIMULATOR. Der MSFS ist (Jehova, Jehova)...

Wir, also alle die

• realistische Prozeduren befolgen
• so richtig mit ATC online fliegen
• spezielle Hardware bis hin zum Home Cockpit verwenden
• am PC herumschrauben, um das Bestmögliche rauszuholen

sind doch auch hier wieder in der Minderheit

Zitat von Der Merowinger

Aber wir, also ich zumindest, haben doch nicht mit diesen Maximalansprüchen angefangen.

Da bin ich aber ganz bei Boris , will auch so ein Homecopit im MSFS sehen. Kann ja nicht sein das die Maximalansprüche weniger werden sollten beim MSFS.

Aber ich bin ganz bei Dir, mit dem Alter wird mann entspannter.

Zitat von Der Merowinger

Homecockpit ist im MSFS auch machbar, meine ich.

My home cockpit

Die Site ist - wie auch das Homecockpit selbst noch WIP, aber es gibt eine Idee davon, was auch im MSFS geht...

Imho nicht weniger als z. B. im P3D.

Macht auch Spaß 😁

Sehr schöne Ideen! Sieht Mega aus! Bzgl des Panel Popout Tools komme ich nochmal auf Joe Dich zu, das klappt bei mir nicht oder ich verstehe es nicht richtig. Aber das lieber im Discord.

Klar ist das alles machbar. Aber eben auch wieder nur mit teilweise exzessivem Gebastel.

Aber anders könnt's ja auch jeder...

Zitat von Boris

Klar ist das alles machbar. Aber eben auch wieder nur mit teilweise exzessivem Gebastel.

Aber anders könnt's ja auch jeder...

Ob MS und Asobo nicht wüssten wie mann eine einfache Schnittstelle zum Homecopit und diversen Add-ons von Hardware und Software machen könnte, herrlich hier.

Na ja... Sie bieten das Framework für die ganzen Variablen und Events an.
Und diverse Anbieter zeigen ja, dass damit sehr gut gearbeitet werden kann.

Dass die Implementierungen oft so arg holprig sind, liegt vor allem daran, WIE das genutzt wird, was Asobo / MS zur Verfügung stellt.
Z. B. wenn ein Addon-Dev erst mal entwickelt, und erst hinterher feststellt, dass unstrukturiertes Arbeiten nur semi-cool ist, leiden alle user drunter.

Wird aber z. B. mit einer klaren Systematik gearbeitet, wenn Variablen vergeben werden, hat das auch Bestand.
Bei der Umsetzung des A32nx LINDA modules war genau das unser Hauptproblem. Die FBW-Truppe, die ich sehr schätze, überlässt es allem Anschein nach noch immer allen Contributors, wie die Variablen benannt werden. Das führt dazu, dass home-cockpit builder permanent an ihren Setups rum schrauben müssen, weil sich ständig die Variablen ändern oder Werte gar nicht für HC-Implementierungen als Variable bereitgestellt werden. Das ist Mist der auf Seiten der Addon-Devs gemacht wird, und liegt nicht daran, dass Asobo dafür nix liefern würde.

Wird im Projekt mit klaren naming-conventions gearbeitet, weiß ich schon vor der Implementierung beim Addon-Anbieter, auf welche Werte ich im HC zugreifen kann. Quasi die API des Addon-Devs die er den HC-Integratoren bereitstellt. Wird hier nicht von Anfang an sauber gearbeitet, wird eine HC-Integration einfach .

Diese Flexibilität anzubieten ist imho ein Muss für Asobo / MS, weil sonst die Community komplett kastriert wird und für jede Funktion drauf warten muss, dass MS sie implementieren lässt, bevor es weiter geht.
Auch ist so eine Migration von P3D / FSX nach MSFS erheblich einfacher und günstiger. Wo das nicht passiert ist kennen wir das Geheule. Z. B. vom Wetterradar, der Camera-API etc.
Es ist doch schön, dass die aircraft-devs da deutlich flexibler sind und wir somit schneller wertigere Addons bekommen können. Allerdings halt auch erheblich mehr Schrott Implementierungen.

So schwer ist es doch für uns bastler doch gar nicht. Für HC-builder sind die wichtigsten Typen:

• A-vars = von Asobo vergebene Variablen (in FSUIPC gemappt auf Offsets)
• Z-vars = von Addon-devs vergebene Variablen die sich identisch zu A-Vars verhalten
• L-Vars = von Addon-devs vergebene Variablen
• X-vars aka CalculatorCodes = darüber können von extern im Simulator Änderungen getrigert werden.
  Sie erschlagen auch Änderungen an LVars, triggern von H-Vars/Events / K-Vars etc.

Ich verstehe ehrlich gesagt nicht, warum sich noch immer das Gerücht hält, es gäbe keine brauchbare Schnittstelle. Es gibt viele Schnittstellen die alle was taugen. Was für den einzelnen davon "einfach" ist, muss jeder selbst für sich entscheiden. Ich komme aus der Web-Welt und liebe z. B. den FSUIPC Websocket Server, weil ich dort Calculator-Codes triggern (also alles mögliche schreiben / anschubsen / status ändern kann) und ich auch nahezu alle A- L- und Z-vars, auslesen und auf Änderungen subscriben.

Und ja, wenn ich ein etwas realistischeres HC implementieren will, MUSS ich mich entweder mit dem Flieger, der Systematik dahinter und auch Variablen ausseinander setzen, oder ordentlich Asche auf den Tisch legen und Schlüsselfertig kaufen.

Jede Menge Vars

Was sind H-Vars und K-Vars?

Und gibt's auch Star Vars?

Aber tröste dich, standardisiertes Arbeiten funktioniert schon selten genug innerhalb eines Unternehmens (sofern es aus mehr als 5 Leuten besteht) - wie soll das dann übergreifend gehen?

Zitat von Boris

Aber tröste dich, standardisiertes Arbeiten funktioniert schon selten genug innerhalb eines Unternehmens (sofern es aus mehr als 5 Leuten besteht) - wie soll das dann übergreifend gehen?