Post réservé à la discussion sur les points que vous désirez connaître un peu mieux quant à l'activité Freelance dans le milieu des jeux vidéos - Microsoft Simulation (j’essayerais d'y répondre entre deux étapes de création ou de livraison vers les USA).
C'est mon ressenti, et je comprendrais que d'autres en aient un différent du mien mais c'est mon expérience d'un année ou presque.

Changements entre FS9 et MSFS:

FS2004, j'ai assez bien connu car c'est par là que j'ai commencé la création et j'ai du pratiqué pendant plus de 8 ans. Certains de mes avions commencés et publiés sous FS9 (Ménestrel, PBY, Calypso, FREMM) l'ont été aussi sous MSFS donc la base de comparaison est là.

Les outils ont bien changés depuis FS2004, notamment ceux de modélisation. Toux ceux qui ont connus FSDS ou Gmax, vont être déçus: ils ne permettent plus de développer.
A la place on a toujours l'inébranlable 3DSMax (très très cher) mais aussi le petit nouveau (qui a quand même plus de 25 ans bientôt) Blender qui est gratuit.
Bien que son interface ne soit pas "académique" comme me le disait Bede40, avec la version 2.83 il est devenu plus abordable et pour quelqu'un qui s'accroche, au bout de 3 mois on arrive à le maitriser de manière à réaliser les premiers modèles. Ensuite avec de l'habitude et de l'exercice on parvient à en tirer la quintessence.
Ceci a été possible grace à un habitué de FSDeveloper: "Krispies" qui a développé un plugin pour exporter vers FSX puis P3D et avec l'aide de "Vitus", ce plugin a ensuite migré vers MSFS où il est maintenu et développé par "RonH" pour être compatible avec les dernières versions de Blender 3.6 et même 4.0 Beta (en tests).

Les animations sont toujours écrites en langage XML et avec la notation polonaise inversée (RPN). On peut utiliser les scripts utilisés pour FSX (ce que certains font encore dans des payware) ou utiliser leur librairies de "poupées russes": les ModelBehavior qui sont des encapsulations d'objets XML apportant à la classe précédentes des fonctions ou des facilités supplémentaires.
Le souci est toujours le même: aucune documentation ou presque sur ce point et Asobo vous laisse parcourir les Mo de librairies pour faire du reverse engineering afin de comprendre le fonctionnement de cette "nouveauté".

Pour les sons, MSFS a encore été chercher la dernière avancée dans le milieu des jeux vidéo: le WWise ... mais là outre le temps de formation, c'est assez difficile d'entrer dans ce cercle. En ce qui me concerne, je me renseigne mais pour nos prochaines réalisations, on sous-traite à l'extérieur cette partie. Une idée du montant que cela coûte pour un simple avion ? plus de 2500€ la prestation clé en mais si la partie modélisation/animation est terminée pour servir de base aux tests.
C'est pet-être très bien mais c'est encore un domaine qu'il faut défricher, expérimenter si l'on veut pouvoir réaliser son avion de A à Z.

Certains "instruments" (au sens large, très large) peuvent être créés en utilisant des outils Web soit HTML5, CSS3 et JavaScript. Ce sont des outils connus depuis longtemps mais l'intégration dans MSFS est encore sujette à caution quant au fait que le SDK est ... embryonnaire sur le sujet. On y arrive (ma tablette 3D est en version 2 et sera dévoilée bientôt) mais c'est encore une partie ardue de recherches, essais infructueux et de beaucoup de patience pour arriver à un résultat correct. Je suis sur cet aspect de la création depuis mi Février ... et ce n'est que maintenant que "mes premiers résultats éclosent" si je puis dire.

Pour les graphismes, certains ne jurent que par Substance Painter dont j'ai d'ailleurs permis la découverte sur PV via quelques posts/années dans cette rubrique. Il n'empêche que l'on peut toujours se débrouiller avec une bonne version de Gimp (gratuite) ou d'Adobe PhotoShop et quelques freeware bien choisis pour créer les fichier d'Ambient Occlusion, les Normal Bump et autres fichiers nécessaires à la création des textures PBR. Pour ma part, j'utilise Material Maker, Normal Generator et PBR-Maker (qui permet de créer une COMP à partir des 3 fichiers de base) et qui sont tous freeware.
Avec un peu de sens artistique et une bonne vision (mieux vaut ne pas être daltonien) on arrive très vite à créer ses propres textures PBR très rapidement.

Question moteur de rendu, MSFS est devant car son moteur interne lui permet beaucoup plus de choses que son ainé tant au niveau complexité des modèles que pour le niveau des textures.
La gestion des textures était assez rudimentaires sous FS9 (diffuse, specular et normal) et on est passé via P3D à une autre façon plus "moderne" de gérée la lumière etles réflexions : le mode PBR (albedo, comp et normal). Pour plus de détails sur le PBR et sa façon être utilisé sous P3D, Xplane et MSFS, j'ai écris un post qui est épinglé dans cette rubrique.
J'y vois un avantage certain en ce qui concerne la traduction des surfaces réfléchissantes comme les surfaces métalliques, le matériaux absorbant la lumière comme le caoutchouc et ainsi de suite.
Le nombre de polygones traité est aussi en nette augmentation même si la vieille technique qu'avait mis sur pied Bill Ortis (LionHeart) permettait de pousser au delà de la barre des 65000 vertices. J'avais commencé à travaillé sur cette technique et Bede40 avait poussé l'automatisme de sa gestion à un très haut niveau de façon à nous permettre assez simplement de réaliser sous FS9 des modèles très très détaillés. C'était la méthode ULE2.

Question SDK, celui de MSFS est plus étoffé (compte-tenu des fonctions supplémentaires supportées) que son ainé mais ... il conserve encore ce trait de caractère de son ancêtre: il n'est pas terminé ou plutôt énormément de fonctions qui aurait du être traitée, ne sont encore que des ébauches malgré les promesses d'Asobo.
Le mode de production lui aussi a changer pour se mettre à la mode. Qui en 2024 accepte encore de créer et de compiler avec des outils en lignes? Plus personne parmi les jeunes donc Asobo a mis en place un outil intégré au simulateur (comme Prepar3D l'avait fait quelques années avant mais avec une utilisation plus restreinte) et toute la documentation est axée sur l'emploi du DEV Mod.
Certains ne jureront que par les outils graphiques, moi je suis dubitatif:
1) pour "un vieux comme moi" ils ne permettent pas une grande productivité surtout au début d'un projet
2) ils freinent le processus de développement car leur complexité demande de bien mémoriser toutes les fonctions et les diverses fenêtresà ouvrir pour accéder à une fonction
3) ils ont été bugés pendant très longtemps et cela ne facilitait le développement (une fois sur deux je perdais mes sources carrément)

Néanmoins, il est toujours possible de se faire un "atelier sur mesure" afin de gagner en temps de développement:
- création à la racine d'un disque dédié, d'un répertoire MSFS
- création d'un répertoire avec un nom de projet approprié puis recopie dans ce répertoire de l'arborescence d'un exemple de projet (du SDK)
- ensuite on modifie sous Notepad, les fichiers XML nécessaire
- on crée son modèle et on exporte le modèle gltf/bin dans le répertoire dédiés aux sources
- en lançant le programme fspackagetools.exe fournit avec le SDK avec pour argument un fichier XML à la racine du projet on arrive à compiler le projet en cours très rapidement (pas de perte de temps du au chargement des images et des vidéos qui ne servent à rien dans ce cas) et on obtient un package directement utilisable sous MSFS.

Pour ma part, je recopie tous mes projets compilés sur un disque USB externe et via un lien symbolique je le déclare sous Community. Cela me permet de ne pas trop sollicité le SSD de MSFS et en cas de souci j'ai une sauvegarde de mes projets en cours. Le fait de charger l'avion via un disque USB externe ne me fait pas perdre de temps.

Pour la mise au point des fichiers XML des animations, je le fais directement sous Notepad dans la copie qui me sert pour les tests en "live" et une fois que l'avancement est jugé satisfaisant, je recopie ces avancées dans le répertoire source pour l’incorporer dans ma nouvelle version.

Le temps de développement d'un avion basique en partant de zéro est d'au minimum 3 mois pour quelqu'un qui utilise sans problèmes les outils mentionnés.

Je n'ai pas abordé les aspects tablettes ou EFB, création de raccourci via la Toolbar ou les effets ... si cela vous intéresse ...

Proposer un add-on sur le MarketPlace de Microsoft:
Les premières démarches pour entrer au MarketPlace datent de début Mars de cette année. Aucune nouvelle en retour de Microsoft jusqu'en Mai où il a été décidé de faire jouer des connaissances: DC Design et LionHearth).
Là, comme par magie, le dialogue a pu se noué et les premiers échanges ont permis aux deux dirigeants de se connecter via l'application Teams Group au groupe de discussion dédié MSFS.

Ayant pratiqué le Support de Microsoft par le passé (durant 11 ans, j'ai été Administrateur Windows avec un accès au Support Grand comptes/48 heures) j'ai eu beau prévenir mes collègues ... ils ont effectivement approfondi l'aspect commercial ou plutôt financier mais n'ont été pas assez insistants sur le plan technique.
Moralité:
- juste un lien pour accéder aux Conditions d'Utilisation qu'il fallait accepter et un autre pour le site de upload,
- les infos concernant les attendus de Microsoft pour accepter des archives nous ont été transmises au compte-gouttes sur une durée de plus de 2 mois et bien entendu par deux personnes faisant partie d'une société tierce (EXPERIS: sous-traitance encore pour rogner sur les coûts).

Après près de deux mois de perdu (il n'y a pas d'autres termes), à force d'insister lourdement (parfois jusqu'à 3 uploads par jour cette dernière semaine) j'ai fini par me faire MA checklist de ce qu'il fallait respecter pour avoir une chance que leur outil de vérification Microsoft accepte nos archives pour publication.
En effet, j'avais pourtant bien précisé aux deux managers de l'équipe de demander avec insistance une liste des pré-requis pour nos uploads:
- nom et format de l'archive
- contenu exact,
- etc ...
Rien n'a été transmis par ce sous-traitant et il a presque fallu travailler sans visibilité par essais successifs en corrigeant à chaque fois nos archives, ce qui est désolant pour une société comme Microsoft mais bien à l'image de tout ce que l'on a connu depuis 4 ans avec ce simulateur.

En vrac:
- Le lien envoyé pour accéder au Team Group doit être ouvert avec Edge, Firefox n'est pas supporté donc 1 aller/retour vers le support pour comprendre déjà cela,
- Sur la demande express des managers Microsoft m'a rattaché au groupe de discussion mais sans me solliciter directement quant au compte e-mail que j'utilisais pour accéder à MSFS; moralité ils ont pris manu-militari mon e-mail perso et il a fallu encore deux échanges par e-mail avant qu'il ne prenne contact avec moi pour avoir l'adresse idoine.
- le contenu de l'archive attendu par Microsoft doit contenir le résultat d'un "Build and Export" réalisé par le DEV Mod sur la base d'un projet MSFS, cet export est un fichier ZIP qui contient:
   - un fichier ContentManifest.json
   - un répertoire PackagesContent (votre arborescence issue de la compilation de la partie source de votre projet)
   -  un répertoire PackagesMetaData :
           - une compilation de données caractérisant l'entreprise,
           - l'e-mail de contact,
           - le prix qui doit respecter des valeurs précises
           - un ensemble d'images représentant votre avion, images devant respecter des tailles très précises !
           - un fichier Marketplace.json contenant la description de votre avion, ses caractéristiques techniques et les liens pour les images précédentes.

Toutes ces informations de la parte Marketplace sont à renseigner via l'interface du DEV mod, juste avant de lancer l'opération de "Build and Export".

Ce n'est qu'une fois que tout ceci a été fait, et que le premier upload a été envoyé puis refusé que nous avons appris par le Support que nos données de localisation étaient incorrectes. Une semaine a été nécessaire pour mettre au clair cette partie.
J'assume une partie de la responsabilité car je n'avais pas bien lu le SDK sur le sujet, mais il n'est pas très explicite ...

En résumé, il faut utiliser un outil du SDK: MSFSLocalizationManager, pour créer un répertoire Localization à côté des répertoires model, panel, texture, ... et y sauvegarder un fichier *.loc. Ce fichier loc peut contenir plusieurs variables, chacune étant localisée pour les pays que vous désirez.
Et c'est là que cela commence à devenir ubuesque: l'outil permet de choisir parmi 23 pays ou tous les 23 pays et donc la première démarche à été d'en sélectionner un minimum des plus représentatifs et aussi pour se simplifier la tâche de traduction.

Cette version a été refusée car non conforme et nous avons appris qu'il fallait TOUT prendre, l'outil de vérification s'attend à ce qu'il y ait 23 localisations: où est-ce mentionné ? sur quel page du SDK, dans quel document ... nada !
Outre la tâche de traduction impensable pour un petit développeur c'est complétement absurde d'un point de vue technique vu la GUI de l'outil.
Oui, mais d'un point de vue Commercial/Microsoft cela permet de maximiser les ventes et les rentrées d'argent ! (supposition de ma part)
Il eu été bien de le savoir avant mais question informations ... le Support laisse à désirer.

Mais ce n'est pas terminé. Suite à cela, et à mon insistance nous avons convenu de réaliser une seule localisation en en-US et si elle était acceptée comme conforme de pouvoir publier l'add-on. Ah bon, mais l'outil était censé refuser si les 23 localisations n'étaient pas incluses ....  Soit le Support proposé par EXPERIS n'est pas à la hauteur soit il y a des choses qui m'échappent ...

Au final, hier soir, notre dernière archive est passée et elle devrait être publiée dans les prochains jours: avec une seule localisation en-US.
Le plus drôle pour la fin: Microsoft s'engage à traduire nos données de localisation en-US dans les 23 langues pré-citées,  puis de nous les renvoyer pour que l'on puisse faire un update et leur retourner cette mise à jour finale qui sera mise en ligne.

Quelques détails supplémentaires:
- une fois le "Build and Export" réalisée, il vaut mieux ne rien toucher dans l'archive ... à moins d'être sûr de ce que vous faites. Toute modification si petite soit-elle a des répercussions sur l'ensemble et peut conduire à un refus de l'archive.
- néanmoins, c'est faisable: je n'ai créé que le premier "Build and Export", toutes les autres archives ont été modifiées par moi à la main et refaites sans oublier de repasser un outil permettant de reconstruire le layout.json contenu dans la partie PackagesContent.
- pour plus de sécurité, à chaque fois et juste avant de refaire l'archive j'utilise un freeware qui me permet de remettre l'heure et la date de l'ensemble des fichiers et répertoires à une date précise, ainsi tous les données sont synchrones comme si elles venaient d'être produite par le Build and Export.

Dernière modification par Lagaffe (06-06-2024 13:38:35)

Bonne initiative

Bonsoir Didier,

Je suis très intéressé par ce que tu peux nous dire sur ton expérience, tout sujet confondu ! Tu as une telle expérience que tu pourrai écrire un livre que je procurerai avec un immense intérêt !

Je te lirai avec grand intérêt Didier !

Bonjour avec grand plaisir je suivrais ce post !Merci pour cette idée

Merci, entre deux compilations, j'ai écris quelques lignes pour répondre à Barnstormer (j'espère avoir corrigé mes fautes).
Si vous trouvez des zones d'ombres ou des points qui ne sont pas clairs, je peux reformuler "ma prose".

Les autres points seront créés dès que possible.

PS: Cet après midi, Microsoft devrait pouvoir ENFIN accepter nos 3 Stearman pour les publier sur le MarketPlace ... au bout de 3 mois de labeur et d'attente.

Deuxième contribution sur le 2ième post concernant le MarketPlace et les affres d'une publication.

C'est un peu ça ...
Disons que pour quelqu'un qui connaissait FS9 ou FSX, cela demande déjà beaucoup de temps et de ténacité pour apprendre le nouveau SDK et surtout les connaissances qui n'y sont pas décrites.
Faire une avion basique, c'est encore faisable avec du temps et de la patience, vouloir aller au-delà devient vite un travail à plein temps.

Depuis Aout, j'essaye de bosser entre 2h et 5h par jour en me ménageant beaucoup de pauses et en variant les occupations qui sont nécessaires: recherches, lectures, participation à des forums et création pure sans oublier le support à apporter à Paul et Gil qui gèrent Golden Age Simulations.
Et puis si un jour je n'ai pas envie, je ne me force pas: je fais autre chose.
Faire cela tout les jours comme si c'était un boulot ne m'intéresse pas et cela risque de me dégouter sur le long terme.

Donc, je pratique comme un loisir disons "régulier"

Salut Squirrel,

Ah, les questions arrivent, c'est bien Cela ne me dérange aucunement mais si tu en as d'autres, n'hésites pas
Comme les questions sont très précises, je vais y répondre dans la foulée:

Outils graphiques / 3D:
Oui, j'avais testé Substance Painter (payant), Quixel Mixer (maintenant free), ArmorPaint (donationware) mais aussi PBR-Painter (disponible sur GumRoad) que j'ai acheté d'ailleurs et qui est un plugin se greffant à Blender.
En fait sur l'année écoulée, j'ai principalement travaillé sur le Stearman qui avait déjà ses textures donc le travail de peinture a été assez réduit.
Ces logiciels sont très bien pour créer une texture en partant de zéro mais pour faire évoluer une texture existante: je n'ai rien trouvé de satisfaisant.
J'ai donc utiliser Gimp pour la plupart de mes travaux de retouche (retrait des boulons dessinés, détails à supprimer) et pour les COMP, j'ai décomposé la diffuse dont je disposais en 3 couches (R,V,B) et je les ai passé en Noir&Blanc. Puis elles ont été travaillées les unes après les autres de manière à correspondre à l'attendu puis avec Gimp elles ont été recomposées en un seul fichier COMP.
Depuis j'ai trouvé un freeware sur FSDeveloper qui se nomme PBR-Maker (créé par un gars de FSDeveloper) et qui est plus rapide pour générer cette COMP.
Ceci dit, il m'a fallu quand même refaire certaines textures en partant de zéro et là j'ai pris ArmorPaint pour les éléments du cockpit par exemple.

PS: Substance Painter est quand même une usine à gaz quand il s'agit juste de faire une planche de bord ou 3 fonds d'instruments et leur licence a évolué dans un sens que je n’apprécie pas trop donc j'ai conservé mon ancienne version des fois que j'en ai besoin ponctuellement.

Pour le Super Stearman, avec Paul nous sommes tombé d'accord pour que une troisième personne s'occupe des textures extérieures. Elle aurait du commencé début Mai mais cela a pris un peu de retard. Vous connaitrez son nom d'ici peu ...

Support :
Pour cela il y a déjà la hot-line de GAS, et les deux ou trois forums sur lequels l'avion a été présenté (Forum Officiel MSFS, SOH et PV). J'assure les réponses techniques puisque c'est moi qui me suis occupé de la totalité des aspects techniques (3D, code XML, animations, etc). J'essaye lors des livraisons de passer une fois par jour sur chaque site pour jeter un œil.
Pour ce qui est des décisions d'évolutions, c'est tranché en comité restreint entre Paul et moi. Par exemple, pour les sons des avions Ai qui n'avaient pas été prévus, j'ai regardé un peu ce que je pouvais faire même si Paul trouvait que c'était pas indispensable et au final j'ai trouvé un compromis qui a l'air d'avoir satisfait l'auteur de la demande.

Pour la personne qui trouvait que le modèle de vol n'était pas comme il le désirait et qui avait publier sans vergogne un mod qui reprenait presque la totalité de l'avion, j'ai été sans doute un peu sec (mais je ne transige pas avec l'aspect légal) et ce gars là, un Français en plus s'est vexé et j'ai retrouvé l'add-on sur un site "non officiel". Les cons ça ose tout !

Pour les évolutions techniques, en fait c'est moi qui les ai proposées à Paul: la tablette en 3D, le PULL-THROUGH (brassage d'hélice qui est maintenant pris par tous les nouveaux avions comme le J3 en préparation). Pour la manivelle et le volant d'inertie, c'était une idée de Paul et Gil issue de la version FSX. La partie Refueling avec la manivelle c'est une élucubration de ma part en me basant sur le point précédent.

J'en ai encore d'autres en préparation sur le Super Sterman: une gestion de la consommation d'huile, la possibilité de remplir le réservoir d'hile via la GUI de MSFS, une gestion de l'usure du moteur, le phénomène de détonation au niveau des cylindres (embryonnaire), la gestion des premiers instants suivant le démarrage du moteur (ralenti, RPMs à ne pas dépasser, encrassement des bougies) bref pas mal de choses que j'ai eu envie de reporter à partir de ce que j'avais fais sur le TiBush.

Ah, j'oubliais une interface pour gérer l'avion mais qui ne soit pas une tablette mais une fenêtre commandable via une icône de la ToolBar de manière à pouvoir l'avoir sur demande affichée à l'écran. Cette fenêtre permet de "suivre la visite pré-vol" via des clics sur un avion schématisé à l'écran et de se déplacer sur les points à vérifier. Tu me diras: cela existe déjà sur beaucoup d'avions ... oui mais sur une tablette 3D et une fois la vérification extérieure faite, il faut manipuler pour revenir dans le cockpit et re-cliquer sur le point suivant. Avec ma solution, le schéma de l'avion étant en transparence à l'écran (comme un HUD qui est d'ailleurs traité comme une fenêtre Windows spéciale) on peut tourner autour de l'avion et faire la checklist puis j'ai prévu un dernier bouton pour revenir dans le cockpit ! La version prototype fonctionne très bien.

L'avant-projet testé dans une navigateur internet:


La version en cours de tests dans MSFS:


Freeware:
Théoriquement, je n'ai pas abandonné mes projets en cours.
La plupart des avancées techniques en fait sont réalisées de manière à être ré-utilisables. Elles ne sont pas la propriété de GAS, mais la mienne. Je les développe sur leurs avions et ils en bénéficie en premier mais tous ce que je viens d'énumérer dans le paragraphe précédent devrait être reporter sur le Canso PBY dès que possible. Ce Canso restera d'ailleurs freeware !

Deux images du Super Stearman en cours :

Dernière modification par Lagaffe (07-06-2024 11:45:50)

Eh bien c'est une façon de bien occuper sa retraite

Dans ma vie professionnelle, j'ai développé deux brevets et je savais comment cela se passe: un prime 4 ou 5 ans après les brevets et ceux-ci restent la propriété de l'entreprise.

En discutant avec Paul, j'ai bien compris qu'"il avait repris du service", un peu pressé par les gens qui suivaient les add-ons de GAS et principalement par ses collègues de SOH. Il ne fait pas cela pour l'aspect financier (on est en phase sur ce point encore).

Donc je lui ai suggéré de me laisser toute latitude pour créer et que ce que j'arriverais à faire serait disponible en priorité pour GAS: tout le monde est gagnant dans ces conditions.
Une chose en entrainant une autre, j'ai commencé petit et à force on commence à avoir un modèle d'avion assez sophistiqué. Je ne dirais pas que l'on titille certains autres studios mais on tire notre épingle du jeu.

De toute façon, les innovations ne restent pas longtemps l'apanage d'un développeur:
- en 2013, j'ai créé le Tibush et Bede40 a eu l'idée d'animer les fenêtres avec la vitesse ...le dernier J-3 a un fonction similaire
- sur le Ménestrel, j'ai offert la possibilité de démarrer le moteur par un clic sur l'hélice en position cockpit ... quel avion léger n'a pas cette fonction actuellement,

Effectivement, ce sont de très beaux avions, ceci dit de mon côté, j'ai un faible pour le Brunner Winkle de couleur bleu pale sur la première image. Je note que tu connais pas mal la gamme de Golden Age Simulations, cela fera plaisir à Paul.

Je ne sais pas par quel projet l'aventure se continuera ... peut-être un PT-22, celui là même dans lequel Harrison Ford s'est "crashé" dernièrement

Néanmoins, j'ai un peu la nostalgie de mon Canso PBY-5 que j'aimerais bien upgrader et certains de mes anciens projets se rappellent à moi: Dewoitine D-551, Mosquito de Fontenay le Compte ou le Bonanza de Jacques Brel qui me fait de l’œil de temps en temps.

Dernière modification par Lagaffe (10-06-2024 11:48:14)