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 20:25:46)

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

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

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.

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

Merci Didier

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

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.