Dans cette phrase le serveur dédié est sous entendu. Puisque côté archive final de mod, on ne différencie que le serveur dédié et le client (avec serveur intégré).
Après c’est vrai que ça peut porter à confusion.
Le fait d’avoir une seule archive pour les deux restes un gros avantage, à l’époque ou les deux n’était pas regroupé, développer un mod serveur était beaucoup plus compliqué. L’universalité à énormément simplifié les choses, donc pour moi ça reste un gros avantage, parmi les autres avantages de forge. Mais c’est vrai que c’est pas juste cette avantage qui fait tout l’intérêt de Forge.
Pour les proxies, franchement je ne vois pas ce qu’il y de compliqué.
Il y a une deux classes, si le mods est lancé en client, le proxy prend la valeur client proxy, et sinon si c’est lancé en serveur le proxy prend la valeur commonProxy.
En fait ce que je trouve mal fait, c’est le nom de common proxy qui devrait plutôt être nommé serverproxy, car en réalité il n’est que exécuté par le serveur, sauf si on fait un super.maMéthode() dans le client proxy.
Mais à l’époque où j’ai appris à créer un mod forge, ceci n’était pas expliqué et du-coup le client proxy / common proxy est resté (et puis c’est aussi le nom indiqué dans la ligne du @SidedProxy, ce qui est aussi mal fait …).
ÉDIT : d’ailleurs je viens de me rendre compte que ton explication est fausse dans ton tutoriel sur le network, common proxy n’est pas exécuté par le serveur intégré. Le serveur intégré est considéré comme le client, donc il passe aussi sur le client proxy.