[MSFS] Code WASM

Barnstormer · [↑]

Je ne sais pas si je poste dans la bonne rubrique ..
Après la sortie du Bell 47 de Flyinsinde j'aimerai bien discuter de l'orientation des codes de MSFS ,
Flyinside avait bien annoncé que son modèle de vol serait externe au simu mais finalement ils ont admis que leur programmation est en réalité inscrite dans un fichier codé en WASM dans le simu..
Au vu du résultat qui est vraiment excellant (le modèle de vol de leur hélicoptère rivalise avec ceux de DCS !)
il semble que les autres développeurs de pointe comme A2A et PMDG s'orientent vers la même solution.
Qu'est ce que cela veut dire ...
Et bien tout simplement que le corp du simu est loin d'être si mauvais que cela puisqu'ils l'ont prévu pour recevoir des ordres complexes en "WebAssembly" et que celui ci les gère et même de belle manière !
Mais alors pourquoi ne pas avoir utiliser ce système pour les avions de base ??

Par contre comme le disait Didier "Lagaffe" cela ferme la porte au petits devs car coder en WASM n'est vraiment pas à la portée de tout le monde !

Qu’est-que que Wasm ?
C’est un code binaire qui est chargé directement par le navigateur ou le programme. Bien entendu, il ne sera pas lu directement par le processeur de votre ordinateur, mais par une machine virtuelle (comme le bytecode et Java). Et grâce à cette machine virtuelle intermédiaire, vous n’avez plus de soucis de portabilité. Un seul code, une MV / processeur.
A quoi cela sert-il ? On avait déjà la compilation Just-In-time permettant de traduire des scripts à la volée pour qu’ils soient exécutés rapidement par votre ordinateur. L’intérêt est ici qu’il n’y a pas de temps de compilation intermédiaire (bon, y‑a une machine virtuelle quand même), que le code binaire est beaucoup plus petit et qu’il charge donc plus rapidement, et qu’on peut ainsi protéger son code !
Vous avez déjà utilisé un moteur 3D pour le web codé en Javascript ? Souvent, la seule protection consiste à rendre illisible le code en supprimant les blancs inutiles à la compilation et les commentaires… mais le code reste lisible — c’est du javascript. Là, allez lire du WASM. Ca reste possible… tout comme on peut décompiler un programme binaire… mais c’est vraiment pas ragoutant.
WASM est Open Source, sous licence Apache. Vous pouvez aller jeter un oeil à son dépôt Github.
Wasm est conçu sous standard ouvert W3C (comprend des représentants de tous les principaux navigateurs). Tout a été pensé pour qu’il soit plus rapide à analyser et à exécuter que javascript. Ainsi, il est possible de charger des modules WebAssembly dans une application javascript et de partager les fonctionnalités permettant de profiter de la performance de WebAssembly et de la puissance et la flexibilité de JavaScript dans les mêmes applications, même si vous ne savez pas comment écrire du code WebAssembly.
WebAssembly permet aux applications complexes de fonctionner de façon optimale sur tous les navigateurs le supportant :
jeux vidéo 3D
applications peer to peer (jeux, édition collaborative, centralisée et décentralisée)
réalité virtuelle et réalité augmentée ( besoin d’une latence très faible)
applications de musique (streaming, mise en cache)
montage d’images et vidéos
reconnaissance d’images, IA
visualisation et simulation scientifique
interprètes de langues et machines virtuelles
bureau à distance
cryptage

Dernière modification par Barnstormer (02-05-2021 08:31:34)

Lagaffe · [↑]

Bonjour,

J'ai déplacé dans "Technique et optimisation", c'est plus approprié quoique cela pourrait aussi aller dans "Créations ..."

L'origine du choix WASM semble être un effet de mode. OK, pour le soit-disant aspect de sécurité mais cela rompt avec l'usage des DLLs que pas mal de monde maîtrisait.
Dans les dernières années en Entreprise, j'ai bien vu que le C ou le C++ n'attirait plus les jeunes, ils ne juraient que par Java.
La philosophie derrière le codage des gauges en HTML, JavaScript et CSS est une autre preuve de cet effet de mode.
Ors la plupart des embauchés chez Asobo, sont des gens relativement jeunes donc enclins à utiliser des technos apprises à l'école et sont peu friands des langages qui ont plus de 10 ans.

Je suis entrain de voir comment décompiler un code Wasm pour regarder les algorithmes utilisés mais ce n'est pas une mince affaire.
Que ce soit à la mode, j'en convient. Que cela soit plus efficace, je demande à voir car il bride l'utilisation des données par le programmeur: celui-ci ne peut décider de placer son fichier de données n'importe où, il faut l'inclure dans la VM (machine virtuelle) VASM. C'est moins facile à utiliser.
Là, où avec une DLL on utilisait un fichier ascii pour y stocker l'environnement utilisateur, il faudra programmer :
- la création du fichier
- les écritures
- les fermetures de fichiers et les sauvegardes sur disque.
Cela complique le code . Je n'ai pas décortiqué le SDK sur ces points mais vu son état cela risque d'être un vrai parcours du combattant.

Mais je ne m’illusionne pas, cette discussion ne risque pas d'intéresser grand monde, 3 ou 4 tout au plus.
[EDIT]
Disons qu'elle sera lu par certains d'entre nous, intéressés par la technique et que peut-être ... elle pourra susciter des vocations de développeur, qui sait .

Barnstormer · [↑]

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++ ?

Henry · [↑]

Lagaffe a écrit :

Mais je ne m’illusionne pas, cette discussion ne risque pas d'intéresser grand monde, 3 ou 4 tout au plus.

Bonjour

Normal, ça nécessite des connaissances nettement au dessus de la moyenne de celles du simmer "moyen".
Pour moi, c'est a peu près aussi clair que si c'était du mandarin.
Mais je lis quand même, pour essayer de comprendre au moins de quoi il s'agit.

Continuez, ne vous arrêtez pas en si bon chemin.

laser · [↑]

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

Taiaut57 · [↑]

Pareil, je suis vos conversations techniques avec beaucoup d’intérêt..
Tonio

Lagaffe · [↑]

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/threads/how-do-i-actually-produce-a-msfs-wasm-module-install-it-get-it-loaded-and-debug-it.449526/#post-880310
- https://www.fsdeveloper.com/forum/threads/wasm-setting-simvars.452135/#post-880168

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

Altamira · [↑]

Henry a écrit :

Lagaffe a écrit :
Mais je ne m’illusionne pas, cette discussion ne risque pas d'intéresser grand monde, 3 ou 4 tout au plus.
Bonjour
Normal, ça nécessite des connaissances nettement au dessus de la moyenne de celles du simmer "moyen".
Pour moi, c'est a peu près aussi clair que si c'était du mandarin.
Mais je lis quand même, pour essayer de comprendre au moins de quoi il s'agit.
Continuez, ne vous arrêtez pas en si bon chemin.

Je suis exactement dans le même état d'esprit qu'Henry.. Je lis et suis tous les posts techniques, créations avec beaucoup d'intérêt même si je suis souvent largement dépassé par leur contenu.

hugues11 · [↑]

+1

Panzer! · [↑]

+2 !

NezHaut · [↑]

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...

Barnstormer · [↑]

Voila la question la plus importante merci Tim , il semble que le code WASM soit suffisamment ouvert pour créer des commandes et réactions complexes et que le moteur du simu soit prévu pour en tenir compte ..
Il y aurait donc un moteur physique à deux vitesses : Le premier assez basique pour les avions natifs (puisque ceci après vérification n'utilisent pas de codage WASM) et un deuxième prévu pour les appareils plus complexes ..
Le fameux moteur moderne que l'on nous a vendu ne serait il pas plutôt celui ci sur base WASM , l'autre n'étant qu'une extrapolation du vieux code ou "un entre deux" plutôt !?

Dernière modification par Barnstormer (02-05-2021 13:38:57)

Lagaffe · [↑]

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.

NezHaut · [↑]

Lagaffe a écrit :

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

Parfaitement, merci beaucoup !

Le module permet d'effectuer n'importe quels calculs puisqu'indépendant, en revanche les résultats doivent correspondre à ce que le moteur de MSFS attend (sur le type de variables utilisées).

Donc de mon point de vue, plus une optimisation qu'un modèle externe comme je l'entendais : calculs aérodynamiques totalement externalisés avec envoi en temps réel de la position de l'appareil dans le monde visuel de MSFS.

Lagaffe · [↑]

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 ...

NezHaut · [↑]

C'est ce que Majestic notamment fait, en utilisant un pseudo mode transposition pour stopper les calculs de FS.

Priscalan · [↑]

Très intéressante cette conversation!!

Barnstormer · [↑]

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.

Dernière modification par Barnstormer (02-05-2021 18:00:16)

NezHaut · [↑]

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.

Altamira · [↑]

NezHaut a écrit :

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.

C'est aussi ce que j'ai compris

Barnstormer · [↑]

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 18:28:30)

Squirrel · [↑]

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.

Lagaffe · [↑]

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

Barnstormer · [↑]

De toute façon le codage WASM se fait bien en C++ non ?
Dans le cas donné par Squirrel le module (fichier) WASM agirait donc comme un injecteur de données et rien de plus !?

Dernière modification par Barnstormer (02-05-2021 18:45:55)

NezHaut · [↑]

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é.

#1 [↑][↓] 02-05-2021 08:26:24

[MSFS] Code WASM

#2 [↑][↓] 02-05-2021 08:47:58

Re : [MSFS] Code WASM

#3 [↑][↓] 02-05-2021 09:25:55

Re : [MSFS] Code WASM

#4 [↑][↓] 02-05-2021 09:55:18

Re : [MSFS] Code WASM

#5 [↑][↓] 02-05-2021 10:05:07

Re : [MSFS] Code WASM

#6 [↑][↓] 02-05-2021 10:19:37

Re : [MSFS] Code WASM

#7 [↑][↓] 02-05-2021 10:25:17

Re : [MSFS] Code WASM

#8 [↑][↓] 02-05-2021 10:51:11

Re : [MSFS] Code WASM

#9 [↑][↓] 02-05-2021 11:15:43

Re : [MSFS] Code WASM

#10 [↑][↓] 02-05-2021 12:42:57

Re : [MSFS] Code WASM

#11 [↑][↓] 02-05-2021 13:24:20

Re : [MSFS] Code WASM

#12 [↑][↓] 02-05-2021 13:33:56

Re : [MSFS] Code WASM

#13 [↑][↓] 02-05-2021 15:50:21

Re : [MSFS] Code WASM

#14 [↑][↓] 02-05-2021 15:58:18

Re : [MSFS] Code WASM

#15 [↑][↓] 02-05-2021 16:14:55

Re : [MSFS] Code WASM

#16 [↑][↓] 02-05-2021 16:20:50

Re : [MSFS] Code WASM

#17 [↑][↓] 02-05-2021 17:07:06

Re : [MSFS] Code WASM

#18 [↑][↓] 02-05-2021 17:59:04

Re : [MSFS] Code WASM

#19 [↑][↓] 02-05-2021 18:03:48

Re : [MSFS] Code WASM

#20 [↑][↓] 02-05-2021 18:12:45

Re : [MSFS] Code WASM

#21 [↑][↓] 02-05-2021 18:26:18

Re : [MSFS] Code WASM

#22 [↑][↓] 02-05-2021 18:32:55

Re : [MSFS] Code WASM

#23 [↑][↓] 02-05-2021 18:39:17

Re : [MSFS] Code WASM

#24 [↑][↓] 02-05-2021 18:43:12

Re : [MSFS] Code WASM

#25 [↑][↓] 02-05-2021 18:54:11

Re : [MSFS] Code WASM

Pied de page des forums