Configurer Viewpoint QOL et Simple Mod Check pour un serveur

Séparez la liste des serveurs du runtime client

L'auteur de QOL appelle son code côté client tout en exigeant toujours la liste de serveurs ci-dessous. Traitez-les comme des responsabilités distinctes. N'installez pas de DLL client Windows sur un serveur loué simplement parce que vos clients en ont besoin.

Conserver les entrées lors de l'ajout de QOL

L'auteur donne ces trois entrées pour QOL. Ajoutez-les aux lignes existantes, séparées par des points-virgules, plutôt que de créer des clés en double ou de remplacer tous vos autres mods.

ID QOL et vérificateur en option

Mods=ZombieBuddy;Viewpoint;ProjectViewpointQOL
WorkshopItems=3619862853;3809306528;3811256204

Pour Simple Mod Check, ajoutez SimpleModCheck aux mods et 3812617481 à WorkshopItems, en préservant le reste. Ces lignes identifient les modules abordés ici ; il ne s'agit pas d'une liste complète pour chaque pack de modèles ou mod supplémentaire sur votre serveur.

Chaque joueur termine la configuration unique du ZombieBuddy et approuve le JAR QOL lorsqu'il y est invité. Confirmez l'indicateur de chargeur d'un ami avant de blâmer la liste de serveurs pour un échec de chargement local.

Établir une référence avant de l’appliquer

1. Utilisez le vérificateur sur son environnement Build 42.21 documenté par l'auteur et ajoutez-le à la liste des mods du serveur.
2. Garder DoLuaChecksum sur. Sur la page sandbox Simple Mod Check, définissez Enforce Off pour la première manche.
3. Demandez à un membre du personnel capable de se joindre aux fichiers d'Workshop authentiques et aux pièces Java requises chargées.
4. Lisez le dossier Logs du serveur et les messages du personnel. Résolvez les fichiers manquants, refusés ou incompatibles sur une connexion test avant d'activer l'application.
5. Activez Enforce uniquement une fois que l'ensemble de mods attendu a une référence utilisable.

Enforce Off est une étape d’inspection de base, et non une preuve qu’un client non contrôlé a réussi. Vérifiez l'ensemble de mods prévu par un joueur normal ainsi que la configuration du personnel avant d'inviter tout le monde.

Comprendre les mises à jour et les échecs de vérification

Le vérificateur compare les empreintes digitales SHA-256 des mods Java chargés. Après une mise à jour, la nouvelle empreinte prend effet suite à un redémarrage du serveur et est confirmée par le premier membre du staff ou, par défaut, par trois joueurs différents qui la signalent. Un chargeur manquant, des fichiers JAR refusés/manquants/modifiés et aucun rapport sont des échecs répertoriés par l'auteur. Vérifiez la raison exacte dans le journal ; ne supprimez pas les contrôles de somme de contrôle pour masquer une incohérence.

Ce que ce vérificateur ne peut pas garantir

L'auteur décrit le client Lua avec somme de contrôle d'un joueur défaillant déconnectant ce joueur, avec un délai d'échec de 20 secondes. Il s'agit d'une vérification de cohérence pour l'ensemble de modules client prévu ; cela ne peut pas empêcher quelqu'un de réécrire lui-même le client du jeu.

Cela ne prouve pas non plus que tous les mods de rendu, sauvegardes ou GPU sont compatibles. Un crash d'appareil photo sans échec d'empreinte digitale appartient à Dépannage du chargement/rendu du Viewpoint, et non une modification forcée de la base de référence de sécurité du serveur.