Serveurs et administration

Héberger une partie avec ses réglages, ou un serveur dédié Linux ouvert 24 h/24 qui apparaît dans la liste des serveurs Steam, et l'administrer : groupes, permissions, exclusions et bans.

Deux façons d'héberger

Les deux utilisent les mêmes réglages, les mêmes groupes et les mêmes bans.

Réglages du serveur

Dans le jeu, ils sont enregistrés dans %APPDATA%\Godot\app_userdata\PhysiCore\server.cfg (bouton Dossier) ; un serveur dédié lit server.cfg à côté de son programme (créé au premier lancement, ou --config <fichier>).

Le contenu Workshop listé est téléchargé avec ses dépendances et activé pour la partie ; les joueurs le reçoivent automatiquement en rejoignant.

Serveur dédié Linux

1. Dans Godot : Éditeur → Gérer les modèles d'exportation → Télécharger et installer (une seule fois).
2. Dans PowerShell, à la racine du projet : .\tools\export_linux_server.ps1. Il crée build\linux-server\ et l'archive build\physicore-server-linux.tar.gz (programme, start.sh, server.cfg.example). Le dossier addons/godotsteam_server a un .gdignore : sur Windows, l'éditeur et le jeu ne chargent que GodotSteam (les deux ensemble déclarent deux fois SteamProjectSettings). Le script le retire le temps de l'export, pour que le serveur Linux ait SteamServer ; ne le supprime pas.
3. Sur le serveur (Debian/Ubuntu) : extrais l'archive, puis chmod +x PhysiCoreServer.x86_64 start.sh et ./start.sh.
4. Ouvre les ports UDP 27015 (jeu) et 27016 (requête Steam), et le port 27015 en TCP si tu utilises le FastDL en HTTP.

Pour la liste Steam, le serveur a besoin de la bibliothèque steamclient.so (fournie par SteamCMD) dans ~/.steam/sdk64/ :

mkdir -p ~/steamcmd ~/.steam/sdk64 && cd ~/steamcmd
curl -sSL https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz | tar -xz
./steamcmd.sh +login anonymous +app_update 1007 +quit
cp linux64/steamclient.so ~/.steam/sdk64/

Sans elle, le serveur fonctionne quand même, mais seulement par IP (et sans contenu Workshop automatique).

Pterodactyl

L'egg installe le serveur depuis Steam : l'application PhysiCore Dedicated Server (App ID 5448960), téléchargée par SteamCMD en connexion anonyme (aucun compte Steam à saisir).

1. Dans le panel : Admin → Nests → Import Egg, choisis server/pterodactyl/egg-physicore.json (s'il existe déjà, importe-le par-dessus ou mets à jour l'egg, puis réinstalle les serveurs qui utilisaient l'ancien).
2. Crée un serveur avec cet egg (image ghcr.io/parkervcp/steamcmd:debian), une allocation principale (port du jeu, UDP et TCP pour le FastDL) et une deuxième pour la requête Steam (Port de requête Steam).
3. L'installation télécharge SteamCMD puis le serveur Linux, met steamclient.so dans .steam/sdk64/ (indispensable pour la liste des serveurs Steam et le Workshop) et rend PhysiCoreServer.x86_64 exécutable.
4. Mise à jour automatique (AUTO_UPDATE, 1 par défaut) : SteamCMD met le serveur à jour à chaque démarrage. Branche Steam (SRCDS_BETAID) et son mot de passe (SRCDS_BETAPASS) installent une branche bêta.
5. Les autres variables (nom, mot de passe, gamemode, carte, collection et objets Workshop, superadmins, FastDL…) remplacent les valeurs de server.cfg. Les objets et la collection Workshop sont téléchargés par le serveur à chaque démarrage.
6. Pour le FastDL, envoie tes mods dans le dossier fastdl/ avec le gestionnaire de fichiers du panel (ou en SFTP), puis redémarre.

La console du panel envoie les commandes au serveur ; le bouton Arrêter envoie quit. Les fichiers à garder entre deux mises à jour (server.cfg, convars.cfg, prop_protection.json, lua_data/, fastdl/) ne sont pas dans le dépôt Steam : SteamCMD ne les touche pas.

FastDL : envoyer ses mods sans le Workshop

Un serveur dédié peut envoyer lui-même ses mods aux joueurs qui le rejoignent : addons (modèles, maps, véhicules, armes, playermodels, sons, Lua…) et gamemodes, sans rien publier sur le Workshop. Le Workshop ([content]) marche toujours en même temps.

1. Mets chaque mod dans un sous-dossier de fastdl/, à côté du programme du serveur (créé au premier lancement). Un dossier avec un gamemode.json est un gamemode, les autres sont des addons (même structure qu'un addon local). Noms de dossier : lettres, chiffres, _, - et ..
2. Redémarre le serveur : il prépare chaque mod (seulement ceux qui ont changé) et affiche [FastDL] N mod(s) prêts.
3. Les joueurs les téléchargent en rejoignant (barre de progression sur l'écran de chargement), puis seulement quand ils changent.

PhysiCoreServer.x86_64
server.cfg
fastdl/
├── ma_ville/          addon → identifiants addon:fd_ma_ville/…
│   ├── addon.json
│   ├── maps/ville.pcmap
│   ├── models/…
│   └── lua/autorun/…
└── monrp/             gamemode (gamemode.json) → gamemode="monrp"
    ├── gamemode.json
    ├── init.lua, cl_init.lua, shared.lua
    └── sound/…

Dans server.cfg, un addon FastDL se nomme fd_<dossier> (map="addon:fd_ma_ville/maps/ville.pcmap"), un gamemode par son nom de dossier (gamemode="monrp" ; il remplace un gamemode du même nom). Les fichiers préparés sont dans fastdl_build/ (régénérés tout seuls) et la clé du serveur dans fastdl.key : garde-la privée et ne la change pas, sinon les joueurs retéléchargent tout.

Téléchargement

• HTTP sur le même numéro de port que le jeu, mais en TCP (le jeu est en UDP : les deux cohabitent). Rapide, et un téléchargement coupé reprend où il en était. Sur Pterodactyl, l'allocation principale ouvre déjà le port en TCP et en UDP.
• Si le port TCP n'est pas joignable (pare-feu, http=false), le joueur télécharge par la connexion du jeu, automatiquement. C'est plus lent, mais ça marche partout.
• max_rate limite le débit de chaque joueur (HTTP et connexion du jeu) et max_downloads le nombre de téléchargements HTTP en même temps (les autres attendent leur tour).

Protection des mods

• Seuls les joueurs admis (version, mot de passe, bans, Steam vérifiés) reçoivent un jeton de téléchargement, valable tant qu'ils sont connectés. Sans jeton, le serveur HTTP ne donne rien, et il ne sert que les mods (aucun autre fichier du serveur).
• Le code Lua n'est jamais dans les fichiers téléchargés : les scripts client arrivent en mémoire avec les scripts du jeu, et les scripts serveur ne quittent jamais le serveur.
• Données seulement : un mod FastDL ne contient que des fichiers de données (modèles .glb/.gltf/.fbx, images, sons, polices, maps .pcmap, JSON, texte). Les scripts, scènes et ressources Godot (.gd, .tscn, .tres, .res…) sont laissés de côté à la préparation (le serveur l'affiche) : un joueur refuse un mod qui en contient, et un mod ne peut jamais remplacer un fichier du jeu. Ainsi, rejoindre un serveur ne peut pas faire exécuter de code sur l'ordinateur du joueur.
• Chez le joueur, les mods sont gardés dans un cache chiffré (AES-256, clé propre à ton serveur, donnée seulement à la connexion) aux noms illisibles : pas de dossier de modèles, de sons ou de maps à copier. Pendant la partie, ils sont lus depuis une archive qui reste chiffrée sur le disque, sans jamais être décompressés en fichiers, puis effacée en quittant le serveur. Le cache oublie les mods inutilisés depuis 30 jours.

Sécurité et anti-triche

Le serveur ne croit pas ce que les joueurs lui envoient : il vérifie lui-même. Ce qui est fait par le jeu, sans rien régler :

• Déplacements (anticheat, activé par défaut) : chaque joueur calcule ses propres mouvements, le serveur contrôle chaque position reçue. Une vitesse impossible (téléportation, speedhack), une montée impossible, un vol (en l'air sans tomber plus de 2,5 s), le noclip là où il est interdit et le passage à travers un mur de la carte remettent le joueur à sa dernière position correcte, préviennent les admins en jeu et s'affichent dans la console ([Anti-triche] …). Après anticheat_kick infractions rapprochées (une infraction est oubliée au bout de 20 s), le joueur est exclu. Les marges sont larges : bunny hop, pentes, bousculades, lag et props qui transportent un joueur ne déclenchent rien ; les vitesses données par les scripts (ply:SetVelocity, ply:SetWalkSpeed…, /freeze) et les téléportations du serveur (ply:SetPos, réapparitions, sièges) sont prises en compte. En véhicule, la position envoyée par le conducteur est limitée à 200 m/s.
• Outils et dupes : les réglages du toolgun sont bornés par le serveur (force d'un propulseur, rayon d'une roue, matériau…), il faut avoir reçu le toolgun ou le physgun pour s'en servir, et 12 actions par seconde au plus. Une dupe ne transporte que les réglages de ses gadgets, le matériau et la masse de ses props, plus ce que le Lua du serveur accepte (entités scriptées et modificateurs, recréés par leurs fonctions Lua) : impossible d'y glisser une arme ou des munitions. Ses props restent à 150 m de son origine.
• Scripts Lua : un script qui tourne plus de 5 s sans rendre la main (boucle infinie) est arrêté avec une erreur au lieu de figer le serveur ; de même chez les joueurs pour les scripts client. Les requêtes web sont coupées par défaut (allow_http) et ne peuvent jamais viser le réseau local ; la base SQLite refuse les commandes qui ouvriraient d'autres fichiers.
• Réseau : seuls les joueurs admis reçoivent les scripts client et la carte de l'éditeur ; la voix est limitée au débit d'un vrai micro.
• Pour les joueurs : les dupes et les données venant d'un serveur sont lues sans pouvoir créer d'objets ni charger de fichiers, et les mods FastDL ne contiennent que des données (voir plus haut). Rejoindre un serveur ou ouvrir une dupe du Workshop ne peut pas exécuter de code sur l'ordinateur.

Protection des props

En multijoueur, chaque prop, véhicule et PNJ appartient au joueur qui l'a fait apparaître. La protection (inspirée de FPP sur Garry's Mod) décide qui peut y toucher. Elle marche dans tous les gamemodes et le serveur vérifie chaque action : un joueur ne peut pas la contourner en trafiquant son jeu. En solo, elle ne fait rien (tout est à toi).

Tout se règle dans le menu de spawn (Q), onglet Protection. Clique dans l'onglet et le menu reste ouvert ; Q ou Échap le referme.

• Mes props (tout le monde) : pour chaque joueur, ce que tu lui permets sur tes props (physgun, toolgun, utiliser, endommager, monter dans tes véhicules). La liste est enregistrée sur ton ordinateur (protection_buddies.json, par SteamID) et vaut dans toutes les parties. Si le serveur le permet, tu peux aussi ouvrir tes props à tout le monde pour une action.
• Props des joueurs (permission cleanup) : le nombre de props de chacun et un bouton Nettoyer.
• Règles du serveur (permission protection : l'hôte et les superadmins) : clique sur Appliquer pour envoyer les règles à tous les joueurs, y compris à ceux qui arrivent plus tard. Elles sont enregistrées dans prop_protection.json (dossier de server.cfg) pour les parties suivantes.

Ce que couvre chaque action : physgun pour attraper, et R pour libérer un prop figé ; toolgun pour tous les outils du jeu et les outils Lua, le remover sur un PNJ et la sélection du duplicateur (une contrainte vérifie ses deux props) ; utiliser pour E sur un prop (bouton, entité scriptée, arme au sol) ; endommager pour les tirs, les coups et les explosions d'un joueur sur un prop, un véhicule ou un PNJ ; monter dedans pour E sur un véhicule. Si un joueur revient avant la fin du délai de nettoyage (même SteamID), il récupère ses props. Quand une action est refusée, sa raison s'affiche un moment à droite du viseur.

Console du serveur

Dans le terminal du serveur dédié (ou la console Pterodactyl), avec tous les droits :

Groupes et permissions

Chaque joueur appartient à un groupe (par son SteamID). Un groupe hérite des permissions d'un autre, et a une immunité : on ne peut viser qu'un joueur d'immunité inférieure.

Autres permissions : setgroup, groups (créer et modifier les groupes), config (recharger la configuration), lua (recharger les scripts), protection (régler la protection des props ; superadmins seulement par défaut, /grant admin protection pour les admins), lua_run (lancer du Lua avec /lua_run, /lua_openscript et /lua_run_cl ; superadmins seulement par défaut). Un admin_groups.json créé avant l'arrivée de convars garde ses anciennes permissions : ajoute-la avec /grant admin convars. Les groupes sont modifiables en jeu (/addgroup, /grant…) et sont enregistrés dans admin_groups.json ; les joueurs dans admin_users.json, les bans dans bans.json (dans le dossier de server.cfg).

En partie hébergée, l'hôte est superadmin. Sur un serveur dédié, les SteamID de [admins] superadmins le sont ; les autres groupes se donnent avec /setgroup. Les SteamID sont vérifiés par Steam (ticket d'authentification) : impossible de se faire passer pour un admin. Un joueur n'entre qu'une fois que Steam a confirmé son identité (15 s au plus, sinon il est refusé), et un même compte ne peut pas être connecté deux fois.

Commandes admin

Tapées dans le chat (Y) avec un /. Un joueur se désigne par une partie de son nom, #id (voir players), son SteamID, ou ^ pour soi-même. /admin liste les commandes permises.

Réglages en jeu (ConVars)

Les gamemodes et addons déclarent leurs propres réglages (durée de manche, argent de départ…) : ce sont les ConVars. L'hôte et les joueurs qui ont la permission convars les changent en jeu par Pause → Réglages du serveur, ou avec /cvar. Des ConVars intégrées reflètent server.cfg : sbox_maxprops, sbox_maxnpcs, sbox_noclip, sbox_playershurtplayers, sv_props_per_second, sv_rp_movement, sv_player_push, sv_anticheat, sv_force_fog, sv_nametag_distance, sv_allow_http, sv_http_whitelist et sv_allowcslua. En Lua, game.ConsoleCommand("sbox_maxprops 300\n") les change comme la console du serveur.

Sur un serveur dédié, les valeurs archivées sont dans convars.cfg à côté de server.cfg, et PHYSICORE_CVAR_<NOM> impose une valeur de départ (variable à ajouter dans l'egg Pterodactyl si besoin). Les données des scripts (file.Write) sont dans lua_data/, au même endroit : pense à le sauvegarder.

En Lua

Les scripts peuvent s'appuyer sur ce système : ply:IsAdmin(), ply:IsSuperAdmin(), ply:GetUserGroup() (aussi côté client), et côté serveur ply:HasPermission(nom), ply:Kick(raison), ply:Ban(minutes, raison), ply:IPAddress(), game.GetServerSetting(clé) et game.IsDedicated().

concommand.Add("annonce", function(ply, args, texte)
	if not ply:IsAdmin() then
		ply:ChatPrint("Réservé aux admins.")
		return
	end
	PrintMessage("[Annonce] " .. texte)
end)