Tu as vu que sur le Bell tu as trois fichiers WASM dont un grand de 5 Mo nommé "MiniFFS".
je pense que c'est seulement celui ci qui contient le codage maitre , que faut il comme programme pour le décompiler ?
à la base le JavaScript n'est pas seulement un dérivé du C++ ?

sisi comme l'impératrice ! toujours intéressant  de vous lirent mais pas toujours évident car il faut un certain niveau pour suivre .. Merci a vous

Comme tu peux le remarquer: on est déjà 3 ... attendons le 4 ième (NezHaut ou Bed40). Effectivement, des pré-requis sont nécessaires sinon c'est le Doliprane assuré

Pour le Bell, je ne l'ai pas acheté donc je ne peux rien dire mais ton hypothèse semble correcte.

Tirée de la doc:

the new toolset compiles it into a WebAssembly module (extension " *.wasm"). This module can then be either placed in the modules subfolder of a package to be automatically loaded when the said packaged is mounted, or referenced from an aircraft panel.cfg file if it includes gauges (in a similar manner to the old DLLs).

Par contre je viens de jeter un œil sur le SDK, il a quand même progressé - à noter -
Il y a des exemples basiques notamment sous SDK_MSFS\Samples\Aircraft\GaugeAircraft\Sources\Code (fichers avec extension *.vcxproj). On en trouve d'autres dans Package Installer et SimConnectSamples (rechercher les fichiers avec extension *.sln ce sont des "solutions" dans le jargon Visual Studio). 
Pour la doc, c'est dans /SDK_MSFS/Documentation/html/index.htm#t=Programming_Tools - Onglet WASM WebAssembly

Avec un environnement de type Visual Studio 2019.2 et l'accès au répertoire SDK_MSFS\WASM (c'est là que sont les includes) on peut déjà ouvrir des projets Visual Studio et essayer d'en compiler un.

Quelques discussions sur FSDeveloper mais c'est embryonnaire ... et en anglais "œuf corse":
- https://www.fsdeveloper.com/forum/threa … ost-880310
- https://www.fsdeveloper.com/forum/threa … ost-880168

B21-soaring est le speudo de Wolgang, le développeur bien connu pour ses célèbres planeurs sous FS9, FSX et Prepar3D

+1

Suis là !

J'ai une question bête : le passage par du code WASM pour les modèles de vol, permet de faire ce que l'on veut au niveau physique, ou cela permet seulement un réglage un peu plus fin de la physique existante. En clair, est-ce que cela externalise le modèle de vol, ou c'est toujours le moteur foireux de MSFS qui tourne, avec des paramètres qui permettent de donner "l'illusion" ?

Malheureusement, si cela complexifie la tâche, ça recoupe ce qui a été dit sur un autre post : les bons add-ons MSFS seront rares...

Le code VASM n'est pas ouvert au sens où tu l'entends, c'est un module interdépendant de MSFS qui interagit avec lui.

Je vais essayer de vous présenter cela d'un point de vue algorithmique/informatique.
Le code VASM  fait ce que l'on lui dit de faire c'est-à-dire ce que l'on a programmé pas plus pas moins. Mais pour interagir avec MSFS il faut ce que l'on appelle une interface entre le module VASM et MSFS.
En informatique, pour communiquer il faut des variables ors celles de MSFS sont "disons" connues : ce sont celles définies dans le SDK à moins que tout ne soit pas encore documenté (possible) ou qu'Asobo entreprenne des modifications dans leur modèle de vol pour l'enrichir. En lisant le SDK et en étudiant les avions existant, on peut voir que un bon paquet de variables FSX a disparu donc plus supportées ...
La modification de leur modèle de vol est envisageable : si ils veulent prendre en compte les lois régissant les mouvements des hélicoptères, par exemple, à moins qu'ils n’introduisent un troisième modèle de vol ... Cela risque de rendre complexe leur code

En ce qui concerne le modèle de vol, à ma connaissance il n'y en a que deux:
- l'historique pour reprendre leurs termes soit celui de FSX
et
- le moderne soit-disant basé sur 1000 points de calcul.
Si les variables calculées dans le module VASM ne sont pas gérées par un des modèles de vol de MSFS, elles ne serviront à rien, puisque le module VASM ne saura pas les réinjecter dans le simulateur.

Donc pour résumer, les éditeurs ne font pas un modèle de vol à part mais ils compensent/complémentent/amendent dans une certaine mesure les calculs faits par de modèle de vol historique ou moderne, sans plus.
Maintenant l'éditeur a le loisir de reprendre les équations utilisées par MSFS et de les rendre plus conforme à la réalité, dans la mesure où cela est réalisable mais au final il leur faudra injecter les résultats de leurs calculs annexes dans des variables existantes et gérées par MSFS pour pouvoir avoir une interaction avec le simulateur.
Si leurs calculs débouchent sur des variables qui ne peuvent pas s'interfacer, cela ne servira à rien du tout.

Est-ce plus clair, formalisé comme de cette façon ?

Il faut voir le modèle de vol comme une boite avec des entrées-sorties, celles-ci sont concrétisées par des variables. Le module VASM est une boite annexe qui se sert en entrée des variables de MSFS, qui réalise des calculs en parallèle et qui réinjecte dans la boite noire le fruit de ses calculs compte-tenu des variables disponibles.

D'autre part, il faut voir cela comme un module qui va faire des calculs en parallèle donc cela va augmenter la charge de travail car votre PC devra :
- faire les calculs du modèle de vol moderne ou historique
- faire les calculs supplémentaires
- injecter ses propres résultats en lieu et place de ceux calculés par MSFS
A termes, c'est quand même une surcharge, donc il faudra que les éditeurs la minimise donc il ne faut pas s'attendre à des miracles.

Avoir un modèle de vol à part nécessiterait de :
- "arrêter" les calculs du modèle MSFS
- faire ses propres calculs
- ré-injecter ses résultats dans le simulateur.

Maintenant le pourquoi du VASM se comprend si on considère que ce simulateur doit tourner sur PC et sur XBox ...

Très intéressante cette conversation!!

Barnstormer a écrit:

Donc en gros le module WASM permet plus de calcul en les "prémâchant" pour ensuite les réinjecter dans le langage de base du simu ?
Donc plus les calculs seront importants et plus la charge de l'ordi augmentera.

Et ça reste limité par les variables que le modèle de vol accepte de prendre en compte.

Par contre il y a quelque chose que je ne comprends pas bien , le "FlyInside Heli Manager" du Bell 47 s'il ne contient pas le modèle de vol ni même le module WASM dialogue quand même avec lui et même en direct,
car grâce à lui on peux modifier à la volée les paramètres de complexité du modèle de vol lui même (et même de beaucoup) !
Il y a donc bien une interaction entre un module externe et le MDV interne !?

Dernière modification par Barnstormer (02-05-2021 19:28:30)

Plus exactement, je pense (car je n'ai pas l'hélico), qu'il a plusieurs modules dont les fonctions sont:
- un module d'interaction utilisateur/paramètres/licence (GUI = graphic User Interface) => positionnement des paramètres
- un module WASM pour calculer le speudo modèle de vol
- un module qui fait le pont (bridge) entre le module WASM et le module d'interaction utilisateur => lecture des params. et transmission au module WASM

Squirrel a écrit:

Hello,

D'après la doc de SimConnect, il est tout à fait possible de tout externaliser, et en C++ s'il vous plaît !

Les variables pour définir arbitrairement la position, vitesse, accélération et attitude de l'appareil sont encore éditables. Il n'y a donc pas d'obstacle technique pour totalement externaliser le modèle de vol à mon sens. Même pas besoin "d'arrêter" les calculs du modèle de vol de MSFS, puisqu'on écrase les données qu'il pourrait produire. L'intérêt serait de gagner en performance, en ne faisant pas deux fois le même boulot, mais rien d'obligatoire dans l'absolu.

Ça oblige à refaire l'intégralité du modèle de vol, mais entre ça et faire un code qui va corriger le modèle de vol existant... La deuxième solution permet de "facilement" rajouter quelques effets, mais je doute qu'on puisse vraiment aller plus loin. Sans compter le risque de devoir tout refaire à chaque mise à jour, qui est loin d'être négligeable.

Si c'est le cas, je me serait attendu à ce que Majestic porte son Dash plus rapidement ??? Ils n'ont presque rien à faire à part une conversion "standard", puisque tout, des systèmes au modèle de vol est déjà totalement externalisé.