[MSFS] Code WASM

Barnstormer · [↑]

NezHaut a écrit :

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

Il faut quand même tout recoder en WEBASSEMBLY cela ne doit pas être simple.
Et puis dans la doc du SDK ils écrivent encore noir sur blanc que leur système WASM a encore de grosses limitations !

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

NezHaut · [↑]

Barnstormer a écrit :

NezHaut a écrit :
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é.
Il faut quand même tout recoder en WEBASSEMBLY cela ne doit pas être simple.
Et puis dans la doc du SDK ils écrivent encore noir sur blanc que leur système WASM a encore de grosses limitations !

Je rebondissais sur la remarque de Squirrel :

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.

Si c'est vrai, le passage par les modules WASM n'est pas nécessaire. Ou j'ai compris de travers ?
Or, tout externaliser et passer par un mode "transposition" en injectant simplement l'avion dans le visuel de FSX / P3D c'est déjà ce que fait Majestic. En théorie, il leur suffirait donc de convertir le modèle 3D, gauge, et le tour est joué ? Le modèle de vol et les systèmes sont déjà en C++ à l'extérieur du simu, avec injection de la position, vitesses, etc... via simmconnect. Cette partie n'a pas à être touchée ?

Dernière modification par NezHaut (02-05-2021 19:25:46)

Barnstormer · [↑]

Si c'est vrai, le passage par les modules WASM n'est pas nécessaire.

Si, il semble que pour des raisons de stratégie et de sécurité cela soit obligatoire :

Will C++ code be allowed to access any system API directly?
No, C++ code, compiled to Web-Assembly modules, will be running in a sandboxed environment for security, portability and stability reasons. Its access will be restricted to the APIs provided by the platform. We expect the list of APIs provided to evolve depending on community feedback.

Dernière modification par Barnstormer (02-05-2021 20:31:58)

Lagaffe · [↑]

Un code extérieur ne peut interagir (écrire la valeur de variables intrinsèques au simu) que si il s'agit d'un module VASM chargé dans le système de fichiers virtuel. C'est un principe d'Asobo pour assurer la sécurité du code. Le code VASM est effectivement en C++ et compilé en Web Assembly.

C'est aussi pour cela qu'une DLL (extérieur au système de fichiers virtuels) ne pourra pas être utilisé.

Vous vous méprenez sur les termes "tout externaliser".
On peut réaliser certains calculs dans un module VASM qui ira lire et écrire des fichiers dans le système de fichiers virtuel (pour le suivi de la maintenance d'un avion par exemple) et ensuite écraser un certains nombre de variable dont le modèle de vol dépend. Et encore toutes les variables ne sont pas modifiables (voir le SDK) ce qui à mon sens interdit de TOUT externaliser.

Pour ce qui est d'arrêter le vol par un artifice de transposition dans FSX c'est peut-être faisable pour ce qui est de MSFS, seul Asobo sait répondre et peut éventuellement diffuser l'information à ses partenaires. Nous, pauvres pékin on pourra toujours rêver donc c'est inatteignable pour les freeware.

Le modèle de vol et les systèmes sont déjà en C++ à l'extérieur du simu, avec injection de la position, vitesses, etc... via simconnect. Cette partie n'a pas à être touchée ?

Encore faut-il recoder ces codes de manière à respecter le Web Assembly, et l'injection via SimConnect doit se faire via un module VASM (exemple dans le SDK). Donc oui, cette partie devra être reprise, testée et validée donc pas mal de boulot.
De plus je le répète: toutes les variables de FSX n'ont pas été reconduites (ne sont pas supportées) et certaines ne peuvent pas être surchargées donc c'est une limitation/frein au portage. Pour l'instant, seuls certains éditeurs ayant un rapport privilégié avec Asobo peuvent avoir connaissance de l'étendue des possibilités, sachant qu'il s'agit d'un "terrain mouvant" et susceptible d'être modifié par les updates (volontairement ou non).

NezHaut · [↑]

Ok, merci des précisions.
Ma confusion venait de l'injection "directe" via simmconnect suggérée par Squirrel.

Squirrel · [↑]

Je vous renvoie vers cette page de la doc. Les dll sont retirées, mais il reste deux façons d’interagir avec le simu : des modules "internes" (modules WebAssembly) et avec un processus externe (une application classique en .exe). Il est même recommandé d'utiliser une appli externe plutôt qu'un module interne pour des questions de stabilité et de facilité de développement. Je n'ai pas testé la chose, mais je ne vois pas pourquoi la doc s'étendrait autant sur le sujet si ce n'était pas utilisable.

Pour moi le fait que toutes les variables ne soit pas modifiables n'est pas un problème à partir du moment où la simulation externe est complète (modèle de vol, simulation de tous les systèmes, etc.). Tout ce qu'il faut, c'est pouvoir placer l'appareil et lire les données du terrain pour gérer les collisions. Je n'invente rien en disant cela, c'est ce qui se fait sur des simulateurs professionnels construits pour l'entraînement des équipages.

Par contre, si j'ai bien suivi (corrige-moi Didier si je raconte des bêtises), les variables locales ont disparu. C'est à mon sens un énorme frein pour lier un modèle 3D à du code personnalisé.

Barnstormer · [↑]

Intéressant donc d'après la doc le module WASM est (ou peut être) un script permettant de lancer SimConnect en interne :

WebAssembly modules can use SimConnect internally

Et effectivement on a :

The recommended method of writing an add-on is to build it out-of-process as an application (an .exe file) rather than in-process (a WASM module).

Mais si le script WASM ne contient pas la variable "simconnect.h" il s'exécutera sans lancer SimConnect , donc le WASM n'est pas forcement lié à SimConnect, c'est ce que je comprends mais je me trompe peut être ?

It is only required to inlcude "simconnect.h".

Dernière modification par Barnstormer (02-05-2021 21:56:23)

Lagaffe · [↑]

Pour répondre à Squirrel, non les variables locales n'ont pas disparues, du moins via des gauges en XML.
Sur le Ménestrel en cours, j'utilise plusieurs variables locales pour la gestion de la verrière ouverte ou fermée.

Après je ne pense pas que l'on puisse stoker leur valeur dans un fichier comme sur FSX, car pour cela il faudrait passe par un module WASM et je ne sais pas si ces modules peuvent gérer ce type de variables.

Attention Branstormer sur les mots utilisés, un module VASM est un programme C++ compilé donc un binaire ors un script est un fichier ascii interprétable car exécutable par un autre programme, c'est différent.

Il ne faut pas isoler des bribes du SDK (c'est réducteur) mais lire la totalité et prendre de la hauteur pour comprendre la philosophie d'ensemble.

Nirgal76 · [↑]

Est-ce que le passage de paramètres "custom" entre le module WASM et le core du simu se fait à une vitesse suffisante pour interagir en temps réel sur les réactions de l'avion sans latence ? (et pas à la vitesse d'un glass cockpit !)

Dernière modification par Nirgal76 (03-05-2021 08:36:54)

Barnstormer · [↑]

Je pensais qu'un script était juste une succession de lignes de code compilés ?

Lagaffe · [↑]

Un script est un ensemble de lignes de codes qui sont éditables la plupart du temps sous NotePad et qui sont ensuite interprétés par un moteur.

Exemples: scripts bash pour l'administration des postes Linux/Unix
hello.bash

#!/bin/bash. echo "Hello World"

Il lui faut l'interpréteur BASH installé sur le poste pour pouvoir exécuter cette ligne

ou Python qui lui peut être compilé le cas échéant.
script.py

print("This line will be printed.")

Là aussi l'interpréteur Python est indispensable.

Un binaire n'est éditable que sous un éditeur Hexa et c'est une suite de symboles illisibles. En fait c'est l'ensemble des codes machines directement compréhensible par le processeur vers qui il est compilé. Il n'a pas besoin d'un programme annexe pour être exécuté.

Barnstormer · [↑]

Merci Didier

Nirgal76 · [↑]

Parlant WASM, ça a l'air mort pour avoir un GTN/GNS RXP à base de trainer. MS/ASobo ne veulent absolument pas implémenter (ni en dialoguer davantage, même si le dialogue n'a jamais vraiment pu avoir lieu, ils sont absolument fermés) ce qui serait nécessaire à les rendre possible pour MFS. Faudra se contenter d'un truc approchant fait en script (qui selon eux peu atteindre un, je cite "même niveau de fidélité"...looool).
Bref, de l'à peu près, comme le reste du produit
En tout cas, pour ceux qui voudrait avoir un gps par F1 ou rxp, il y a un thread avec vote
https://forums.flightsimulator.com/t/op … -xp/392140
pour demander à MS deja d'accepter de répondre à ces développeurs, au moins avoir cette politesse, et peut être après, penser aux utilisateurs qui veulent avoir une meilleur expérience de simulation,ce que MS ne semble pas souhaiter (enfin, Jork en particulier qui bloque tout de ce que j'ai compris, Asobo n'a pas l'air dans le pipe et implémente ce que le grand manitou Jork leur dit de faire)

Dernière modification par Nirgal76 (06-05-2021 20:33:52)

Gérard BERNARD · [↑]

Taiaut57 a écrit :

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

Pareil pour moi, surtout si c'est écrit avec une orthographe soignée ce qui est le cas ici...

Lagaffe · [↑]

Bonjour,

En furetant de droite et de gauche, j'ai trouvé une info intéressante: il semblerait que l'équipe qui développe un Mini-500 pour MSFS, a dans l'idée d'ouvrir son modèle de vol aux utilisateurs.

[img align=c]https://media.discordapp.net/attachments/843943768083660849/844247401777594428/Screenshot_2021-05-18_181738.png[/img]

Si c'est le cas, je pense que je connais quelqu'un qui sera drôlement intéressé !
Si j'ai bien compris: IFE qui est le speudo du gars, pourrait-être fort bien IndiaFoxEcho ...

J'avais eu déjà l'info via un autre média mais voici un article qui corrobore cette info: https://www.helisimmer.com/news/indiafoxtecho-announces-development-of-experimental-mini-500-for-msfs

tojdank · [↑]

Avec cette histoire de créer un MDV externe au simu, comme le néophyte que je suis, je me demande s'il seront capables de restituer des commandes de vol sur les axes moins sensibles, restituant mieux leur inertie...etc. Sans cela, ça ne changerait rien d'intéressant, pour moi du moins.

Barnstormer · [↑]

tojdank a écrit :

Avec cette histoire de créer un MDV externe au simu, comme le néophyte que je suis, je me demande s'il seront capables de restituer des commandes de vol sur les axes moins sensibles, restituant mieux leur inertie...etc. Sans cela, ça ne changerait rien d'intéressant, pour moi du moins.

Tu sais FlyInside a fait du super boulot avec leur Bell 47 et forcement cela donne des idées aux autres, le dev d'IndiaFoxEcho Dino Cattaneo est loin d'être un manchot donc je lui fais plutôt confiance la dessus.

#26 [↑][↓] 02-05-2021 19:17:39

Re : [MSFS] Code WASM

#27 [↑][↓] 02-05-2021 19:22:47

Re : [MSFS] Code WASM

#28 [↑][↓] 02-05-2021 19:44:34

Re : [MSFS] Code WASM

#29 [↑][↓] 02-05-2021 20:20:32

Re : [MSFS] Code WASM

#30 [↑][↓] 02-05-2021 20:28:53

Re : [MSFS] Code WASM

#31 [↑][↓] 02-05-2021 20:48:54

Re : [MSFS] Code WASM

#32 [↑][↓] 02-05-2021 21:46:16

Re : [MSFS] Code WASM

#33 [↑][↓] 03-05-2021 07:33:56

Re : [MSFS] Code WASM

#34 [↑][↓] 03-05-2021 08:35:42

Re : [MSFS] Code WASM

#35 [↑][↓] 03-05-2021 09:33:46

Re : [MSFS] Code WASM

#36 [↑][↓] 03-05-2021 11:39:08

Re : [MSFS] Code WASM

#37 [↑][↓] 03-05-2021 17:51:24

Re : [MSFS] Code WASM

#38 [↑][↓] 03-05-2021 21:49:11

Re : [MSFS] Code WASM

#39 [↑][↓] 06-05-2021 08:34:29

Re : [MSFS] Code WASM

#40 [↑][↓] 20-05-2021 17:09:09

Re : [MSFS] Code WASM

#41 [↑][↓] 20-05-2021 17:23:02

Re : [MSFS] Code WASM

#42 [↑][↓] 20-05-2021 17:31:27

Re : [MSFS] Code WASM

Pied de page des forums