Forge Modding Helper 3

Forge Modding Helper 3

Après vous avoir présenté Forge Modding Helper 2 il y a deux ans, voici la nouvelle version de cet outil ayant pour objectif de vous simplifier la vie dans la création de vos mods Minecraft avec l'API Forge !
Plus optimisé, plus intuitive, plus jolie, plus de fonctionnalités : c'est tous le pari de cette nouvelle version !

Les principales différences avec Forge Modding Helper 2 :

- Je vais rien vous apprendre en vous disant que le VB.Net c'est pas incroyable quand on commence à faire des choses complexes avec une interface de plus en plus complète.
J'ai donc décider d'apprendre le C# afin de pouvoir développer des applications en WPF sous Visual Studio. Forge Modding Helper 3 n'est donc plus développé avec SoftwareZator, mais avec Visual Studio en C#.

- En poursuivant mes projets de modding Minecraft ces deux dernières années, je me suis rendu compte que la génération des fichiers de modèles d'items et de blocs n'étaient pas les seuls choses répétitives auxquelles il fallait remédier.
J'ai donc fais une liste des choses qu'il fallait "automatiser", puis j'ai commencer à développer cette nouvelle version de Forge Modding Helper. L'idée est d'aider le moddeur dans la gestion de son espace de travail et non plus simplement dans la création de fichiers-modèles.

- En passant en C# (et donc en code pur), je me suis également beaucoup penché sur l'open source. En progressant sur le projet, je me suis dit qu'il serait bon de le proposer en open source afin que d’éventuels personnes puissent contribuer, mais aussi pour avoir un point central où les bugs, suggestions et changelogs seraient facile d'accès et en anglais afin de toucher la plus grosse communauté possible. Cela permet également aux personnes de voir qu'il n'y a rien de malveillant dans le logiciel. 

Où en est-on aujourd'hui ?

La plupart des fonctionnalités de bases sont en place ! 
Bien sûr elles seront étoffées au fur à mesure des versions, mais c'est déjà pas mal fonctionnel !

L'Assistant Creator :

C'est une des forces de Forge Modding Helper 3 !
L'Assistant Creator vous permet de créer en quelques cliques votre espace de travail Minecraft Forge configuré sur mesure !
Il s'occupe de tout : configuration des fichiers, téléchargements et décompression du MDK et même le créations des dossiers d'assets de base !

Le système de projets :

Vous pouvez depuis l'interface d'accueil voir vos derniers projets ouvert, y accéder ou bien les supprimer.
Vous pouvez également importer un espace de travail déjà existant, à condition que la version de Minecraft soit supporté par Forge Modding Helper.

L'explorateur de projet :

C'est le point central du logiciel !
Vous pouvez à partir de cette fenêtre gérer l'ensemble de votre espace de travail : modèles jsons, textures, fichiers de traductions, paramètres généraux de votre mod et même la recompilation !

Les options :

Forge Modding Helper 3 a pour objectif d'être le plus personnalisable possible.
Ainsi vous pouvez non seulement changer la langue de l'interface, mais vous pouvez également ajouter des fichiers de traduction pour n'importe quelle langue !
Et cerise sur la gâteau : vous pouvez totalement changer les couleurs de l'interface grâce à un système de thèmes. Là encore vous pouvez facilement en créer vous-même !



Vous savez tout !
Vous trouverez toutes les informations et téléchargements sur le GitHub du projet : https://github.com/JeremTech/Forge-Modding-Helper
Il y a également un Trello en français pour suivre la progression des mises à jours : https://trello.com/b/4C7TwCta/forge-modding-helper

A une prochaine !
Jerem'

Bonjour,

Très belle interface ! Bien organisée, couleurs cohérentes pour chaque catégories... bravo ! 
On voit que tu as bien pris de la bouteille sur WPF !

Le logiciel te sert un peu à expérimenter/mettre en pratique du code non ? On voit que tu t'applique dans l'utilisation des structures, la gestion des threads, la traduction... C'est très bien organisé.

Honnêtement, j'ai pas testé (ça fait un moment que j'ai décroché de minecraft) mais de ce que je vois du code et de ton organisation, ça part très bien  !

Bonne continuation !

Hello @polien !

Désolé je n'ai pas eu trop le temps de repasser ces derniers temps
En tout cas merci pour tes retours !

En effet ce logiciel me permet de mettre en pratique un peu toute l'expérience que j'ai accumulé au fil du temps, tant en UX/UI qu'en back-end. Mais c'est aussi un outil qui me servira donc c'est tout bénef' pour moi ! (En même tant quand on est dev un p'tit truc répétitif on le voit toujours comme un truc à automatiser )

Pour le côté organisation, ça pour le coup ça vient du modding Minecraft. J'ai toujours tout bien rangé en dossier (package en Java), donc j'ai gardé ce fonctionnement car selon moi c'est beaucoup plus propre et facile de s'y retrouver, surtout dans le cadre d'un projet d'équipe ou open-source.

J'ai encore beaucoup à apprendre sur le WPF, je suis d'ailleurs en train de réécrire l'interface de l'Assistant Creator pour le rendre responsive (même si le redimensionnement ne sera pas permis), car actuellement tout est placer à la souris, donc c'est pas propre du tout dans le code .
Mais en soit oui je commence à bien comprendre le WPF, surtout quand tu le combine à Blend, c'est très puissant.

En tout cas la version stable 3.0.0.0 commence à se dessiner, j'espère la sortir assez rapidement (Janvier 2021 si j'arrive à avoir suffisamment de temps libre d'ici là).
La 3.0.0.0-Pre5 est en phase d'amélioration, ça sera la dernière beta, puis une release-candidate la suivra avant la sortie en version stable.
J'ai déjà pas mal de plans pour de futurs mises à jour, mais ça dépendra à nouveau du temps que j'aurais par la suite.

Voilà voilà !
Bonne continuation à toi aussi !

Jerem'

Hello ! (ouah ça fait terriblement longtemps que j'ai pas posté un message ici moi...)

J'espère que vous allez tous bien, ça fait un bail !

Je continue de jeter un coup d'oeil de temps en temps au fofo pour voir ce qu'il s'y passe, ça fait toujours plaisir de voir quelques messages de temps en temps !

Pas mal cette nouvelle interface, effectivement tu commences à bien te débrouiller en WPF et c'est trop cool
Comme j'étais le chieur qui fait tout le temps des remarques, j'avais pas envie d'échapper à la règle pour cette fois  Mais c'est pas tant des remarques négatives, plus des pistes pour t'améliorer !

J'ai jeté un coup d'oeil rapide à ton répo, c'est du code propre il n'y a rien à dire là-dessus, mais tu ne profites pas de toute la puissance de WPF. En effet, WPF repose grandement sur un système de Bindings afin d'éviter au maximum le code-behind (l'utilisation de fichiers .xaml.cs). Pourquoi ça ? Pour que les devs et les designers puissent travailler indépendamment sans se marcher dessus ! Avant tout le monde travaillait sur les mêmes fichiers c'était vraiment pas bon :/

Les bindings en quoi ça consiste exactement ? Je ne vais pas faire un cours complet mais je te filerais quelques ressources utiles !
Je ne sais pas si tu as entendu parler de ce qu'on appelle les design patterns, mais c'est des motifs récurrents dans plein de codes (à tel point que ça en devient des références pour architecturer son projet / son code). Un plutôt connu est MVC, qui sépare le projet en 3 parties : Model View Controller. La partie Model regroupe tout le code permettant la gestion des données, la partie View regroupe tout ce qui est de l'ordre de l'affichage, et la partie Controller fait le lien entre les deux (en réalité on considère souvent que la vue peut interagir avec le modèle mais je trouve ça bof, m'enfin passons !).
Le pattern qu'on utilise ici est dérivé du MVC et s'appelle MVVM. C'est le pattern de référence quand on fait du WPF ! MVVM signifie Model View ViewModel. Dans cette variante, le ViewModel remplace donc le contrôleur. Son rôle va être de récupérer les interactions effectuées dans la vue (par l'utilisateur donc) et appeler le modèle en conséquence. A la différence du MVC, ici le ViewModel ne connait pas la View. C'est la View qui connait le VM (plus rapide à écrire haha) et qui va appeler des méthodes et en récupérer le résultat. Mais ces méthodes, la view ne va pas les appeler à la main (sinon il faudrait du code-behind et on revient au problème initial). On va dire que la view binds ses actions au VM. Concrètement, ça se fait comme ça (au niveau d'un bouton par exemple) :

Code:

<Button Command="{Binding Path=MyCommand}" />

Ici, la commande (qui fait référence au click pour un bouton) de notre bouton est "liée" (bound) à la propriété MyCommand du ViewModel référencé dans la vue (j'explique ça juste après).
On peut aussi lier une propriété classique ("Content" pour un Label par exemple) à une propriété du VM, ce qui a pour effet que dès qu'une des deux entités (View ou ViewModel) modifie cette propriété, elle est modifiée de l'autre côté également. On peut le voir comme un partage d'information prévu nativement, plus besoin de bricoler / de code-behind !
Je passe très vite dessus mais pour lier un ViewModel à une View, il faut le passer dans la propriété DataContext (par exemple de la Window). Il existe plusieurs façons de gérer ses VM, je te laisserais regarder dans les ressources à la fin.

(Oh le roman que j'écris...)

Bon finalement comment on organise son projet ?
Tu dois avoir 4 grandes parties :
- View
- ViewModel
- Model
- Services

Services ???? Ca sort d'où ça encore

En gros, il faut savoir que ton ViewModel n'est pas responsable de la logique métier. Par exemple, ton VM ne doit pas être capable de générer un mod Minecraft lui-même, il fait juste la liaison entre la View et le Model. Mais on aime bien laisser la gestion des données au Model et pas plus. Du coup on peut stocker des données et en retrouver grâce au Model, mais on a aucune partie qui effectue toute la logique dans cette application... C'est pour ça qu'on se sert des services ! Un service, ça va être une classe responsable d'une partie de la logique (ModService pour gérer la génération de mods, ConfigurationService pour gérer la configuration du logiciel, etc...).
Finalement, le flux d'information fait View -> VM -> Service -> (Model) (je l'ai mis entre parenthèses parce-que la notion de Model est très fortement liée aux BDD, ce qui n'est pas tout le temps utile).

Je sais pas si tout ça était super clair, mais j'espère t'avoir appris un truc

Par ailleurs, pour implémenter plus simplement MVVM dans tes projets WPF, je te conseille l'excellent package NuGet dont le petit nom est MVVMLight, tu trouveras ça dans les ressources !
Pour un code ENCORE plus propre, jette un coup d'oeil à l'injection de dépendances, ça te permet d'éviter que ton VM instancie lui-même une classe de service. Il dira plutôt "j'ai besoin de tel service" et si ce service en a besoin d'un autre, etc... tout sera instancié et injecté automatiquement. Pas besoin de s'embêter à instancier à la main toutes les dépendances !

Bonne soirée à tous et à bientôt !

Ressources :

MVVM
https://www.dotnetdojo.com/mvvm/

Binding en WPF

https://www.wpf-tutorial.com/fr/34/data-binding/introduction-au-data-binding-de-wpf/

MVVMLight
https://www.c-sharpcorner.com/article/getting-started-with-mvvm-light-with-wpf/

Injection de dépendances
https://medium.com/ividata-link/c-linjection-de-d%C3%A9pendances-di-et-l-inversion-de-contr%C3%B4le-ioc-48dbe76cff6b

(je ne me souviens plus de quel package j'utilisais pour l'injection de dépendances en WPF, j'essaierais de retrouver ça si ça t'intéresse !)

Hello !

Waow merci pour toutes ces infos !
La puissance du WPF repose en effet sur ce principe de binding, mais ayant déjà essayé par le passé, je trouve ça plus compliqué que l'utilisation des évènements pour au final pas grand chose de plus, si ce n'est un peu d'optimisation et de propreté.

Un jour peut-être je m'y pencherais, mais pour l'instant je n'y vois pas trop d'intérêts.
Je fais énormément de traitements sur toutes les entrées utilisateurs, et selon moi les évènements sont plus adaptés à ça (et plus simple).

Merci en tout cas pour les infos et les ressources, ça me servira quand je trouverais intéressant de basculer sur du binding !

A une prochaine !
Jerem'

Salut

Je comprends bien qu'il soit compliqué de situer l'intérêt du pattern MVVM (et donc du système de binding) quand les évènements font, à priori, la même chose.
Ici, on est totalement dans ce qu'on appelle de la [url=https://fr.wikipedia.org/wiki/S%C3%A9paration_des_pr%C3%A9occupations#:~:text=La s%C3%A9paration des pr%C3%A9occupations (ou,g%C3%A8re un aspect pr%C3%A9cis de]séparation des préoccupations[/url]. L'objectif est de séparer la logique de l'affichage des données de celle de la gestion des données. On peut trouver que c'est une charge de travail inutile au début, mais en fait ça a quelques avantages non-négligeables :

Plus de clarté au niveau du code
On sépare bien comme dit précédemment ce qui affiche les données de ce qui les gère

Une meilleure segmentation du code
Segmenter son code, ça revient à pouvoir changer n'importe quelle partie sans problème, sans que ça supprime autre chose. Aujourd'hui, tu veux changer ton interface entièrement, tu vas supprimer ton fichier xaml qui supprimera le code-behind avec. Bien sûr tu peux copier-coller ton code-behind mais on cherche à bricoler le minimum quand on dev hahaha ! Aussi, imagine que tu souhaites changer le type de BDD que tu utilises, ou n'importe quel autre outil externe. Ca sera plus simple si cette gestion est encapsulée dans une partie bien précise (dans l'idéale une seule classe) de ton programme, plutôt qu'un peu partout.

Une gestion des tests unitaires 100 fois plus simple
C'est probablement un des points les plus importants !
Je ne sais pas si tu connais le principe de tests unitaires (je n'ai pas regardé sur ton repo s'il y en avait) mais c'est très très important quand on dev ! Si tu fais du dev ou que tu comptes en faire plus tard tu ne pourras pas y échapper.
Un test unitaire, c'est un bout de code qui permet de tester automatiquement qu'une partie de ton programme fonctionne. Par exemple, tu ne veux pas avoir à lancer ton programme pour savoir s'il est toujours capable de générer un mod après une modification du système. Enfin, tu peux en avoir envie, mais ton test unitaire te le diras en bien moins de temps.
Mais pour ça il faut que ta logique de génération de mod (par exemple) soit encapsulée dans une classe à part de ton code-behind (et même de ton ViewModel, potentiellement dans un Service, c'est ce qu'il y a de plus propre). Tu pourras ainsi instancier cette classe dans ton test et l'utiliser comme bon te semble pour vérifier qu'elle sort bien ce que tu veux derrière. C'est faisable avec du code-behind mais très brouillon.

Finalement c'est ce qu'il faut retenir. L'architecture d'un projet est ultra importante, surtout quand il est amené à grandir. Tous les grands logiciels en WPF suivent ce pattern. Visual Studio est codé en suivant le pattern MVVM, et il fonctionne très très bien malgré ses (très) nombreuses fonctionnalités. Séparer les préoccupations permet d'avoir un code plus clair, une interchangeabilité des différentes pièces de ton app (si je fais référence à un puzzle) et surtout de faire des tests unitaires bien plus facilement.
Et n'oublie pas que ce qui est le plus simple n'est pas toujours le plus adapté !

Si tu veux continuer de dev avec WPF, je te conseille très fortement de passer au MVVM, c'est un standard utilisé par (quasi) toutes les boites qui font du dev et à juste titre, c'est préconisé par Microsoft (en même temps WPF a été pensé comme ça).

Bonne journée !

Bonjour à tous !

Petit point sur l'avancé, car ça fait un petit moment !

J'ai mis à jour le premier message avec toutes les avancées faites sur Forge Modding Helper 3 !

La première version stable est sortie mi-janvier 2021. Toutefois, certaines choses n'étaient pas parfaite, et le côté technique n'était pas suffisamment modulaire pour envisager des mises à jours par la suite.

Je suis donc actuellement en plein développement de la version 3.1. Une première pre-release est déjà disponible avec une quantité monstrueuse de changements. J'ai notamment recoder toute l'interface de l'Explorateur de projet, le code WPF est bien plus propre maintenant
J'ai toujours assez peu de temps pour avancer dessus, mais ça progresse doucement tout de même

Vous avez tout !

A une prochaine !
Jerem'