Avant de commencer
Sauvegardez server.cfg, les missions et la liste des mods avec leurs versions. Préparez une fenêtre de maintenance. Le lancement CubixServ sélectionne explicitement /data/server.cfg avec -config : déposer un autre fichier sans le sélectionner ne le rend pas actif.
Identifier la configuration réellement utilisée
Bohemia précise que -config choisit le fichier de configuration. Travaillez sur server.cfg dans les fichiers du service, en conservant sa syntaxe et une copie de retour arrière. Vérifiez les paramètres documentés pour votre version. Les options de lancement et les règles réseau de l’hébergement restent gérées séparément ; ne remplacez pas le lanceur pour appliquer un exemple trouvé sur un autre environnement.
Préparer les missions et leur rotation
Copiez les missions autorisées dans le répertoire prévu par le serveur, généralement mpmissions. Le bloc Missions de la configuration référence les templates de missions. Vérifiez nom, casse, carte et dépendances avant d’activer une rotation. Commencez par une mission connue et simple. Un fichier présent mais dépendant d’une carte ou d’un addon absent ne deviendra pas fonctionnel par une modification de la seule rotation.
Définir le modpack et ses dépendances
Conservez une liste de mods cohérente avec la mission et les clients. Le Workshop distribue des contenus ; il ne garantit ni leur compatibilité entre eux ni leur chargement par le serveur. Les paramètres -mod et -serverMod ont des rôles différents et dépendent du lancement. Leur modification automatique n’est pas promise sur cette offre : faites confirmer les possibilités du panel avant de construire un modpack complexe.
Contrôler les signatures sans les désactiver
Une signature .bisign accompagne un contenu signé ; une clé publique .bikey permet au serveur de vérifier la signature correspondante. verifySignatures règle cette vérification, avec le mode 2 décrit par Bohemia. Utilisez les clés publiées par les auteurs et ne distribuez jamais une clé privée. Face à un rejet, contrôlez versions et clés au lieu de désactiver globalement les vérifications pour contourner le symptôme.
Mesurer l’IA et comprendre le headless client
Une mission avec beaucoup d’unités IA, de scripts récurrents ou d’objets peut saturer le traitement malgré de la RAM disponible. Un headless client est un processus Arma supplémentaire qui peut recevoir certaines tâches d’IA ; headlessClients[] déclare des connexions autorisées, sans créer ce processus. Il exige une mission adaptée, des ressources et une configuration distinctes. Il n’est pas annoncé comme inclus ni comme correction universelle du lag.
Tester puis rouvrir la communauté
Vérifiez successivement le démarrage, le chargement de mission, les signatures et une connexion client avec le modpack attendu. Examinez les journaux après chaque étape. Testez les changements importants sur une copie plutôt que pendant une session communautaire. Gardez la mission et ses versions précédentes pour revenir en arrière. Pour une erreur persistante, transmettez au support le nom de mission, l’heure et les messages utiles en masquant les secrets.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Mission non chargée | Vérifier le template, les fichiers de mission et les dépendances de carte ou de mods. |
| Signature refusée | Comparer version du contenu, .bisign et clé .bikey correspondante. |
| IA lente avec RAM libre | Mesurer la charge de mission avant de dimensionner une solution ou un processus supplémentaire. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.