Client/Serveur dédié

From Neos Wiki
Revision as of 16:13, 1 December 2021 by FuzzyBot (talk | contribs) (Updating to match new version of source page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
This file is under deprecation please see Headless Client for the new file


Other languages:
English • ‎français • ‎čeština • ‎日本語 • ‎한국어

Les Client/Serveur dédié sont des versions en ligne de commande de Neos excluant l'interface graphique, ce qui leur permet de fonctionner efficacement dans des scénarios où le rendu n'est pas nécessaire, comme sur un serveur. Les utilisateurs de Neos Pro et tous les "Patrons" au niveau "Gunter" et plus ont accès aux versions du Client/Serveur dédié. Voir le canal Discord #headless-client ou contactez votre administrateur pour obtenir votre code d'accès.

Installation

Ou bien si vous utilisez une interface graphique :

  • Allez dans Steam, ouvrez les propriétés de Neos et allez dans l'onglet BETAs
  • Utilisez votre code pour activer la branche bêta
  • Passer à la branche des clients dédié

Method 1

If using Steam:

  • Go to Steam, open Neos Properties, and go to the Betas tab
  • Use your code to activate the beta branch
  • Switch to the headless-client branch
  • Utiliser la commande SteamCMD

app_update 740250 -beta headless-client -betapassword {Code d'accès}

Configuration

  • Une fois que Steam a terminé la mise à jour, ouvrez le dossier d'installation. Vous pouvez trouver le client sans tête dans le sous-dossier "Headless Client".
  • Vous pouvez utiliser le fichier Config/DefaultConfig.json pour configurer le monde de démarrage ou lui demander de se connecter à un compte (veuillez ne pas utiliser votre compte Néos principal)

{

 "tickRate": 60.0,
 "usernameOverride": "10 year old ThinkPad",
 "loginCredential": null,
 "loginPassword": null,
 "startWorld": {
   "sessionName": "Headless Lounge",
   "description": "This one is running on my 10 year old TabletPC. Let's see how well it runs!",
   "maxUsers": 16,
   "accessLevel": "Anyone",
   "tags": null,
   "mobileFriendly": false,
   "loadWorldURL": null,
   "loadWorldPresetName": "SpaceWorld",
   "defaultUserRoles": {
     "Gourry": "Admin"
   },
  }
}
  • Le "loadWorldPresetName" : charge un monde basé sur les modèles de monde de Neos, les modèles sont : "SpaceWorld", "Basic Empty", "GridSpace", "Microworld", "Testing Scaling", "ScratchSpace", "ScratchSpace (mobile)", "Instancing Test", "Physical Locomotion Test" et "UIX Test"
  • "defaultUserRoles" définit l'utilisateur et le niveau d'accès pour le monde. Le format est "USERNAME" : "RÔLE", Les rôles sont : "Admin", "Builder", "Moderator", "Guest", "Spectator".
  • Lancez l'exécutable pour démarrer le client
  • The "loginCredential" attribute defines the Neos account to run the server with. It is recommended to create a separate account to run the server as if you wish to join your own server - it is not possible to join a server running with the same account on the client and server.
  • The "customSessionId" attribute accepts the following formatting: S-[userID]:[anything] where [UserID] is the userID of the account running the headless session, and [anything] is whatever you want to put
  • Utilized for nested sessions, "parentSessionIds" is recommended to manually configure a custom session ID for parent worlds using the note above as without this, session IDs are dynamic. This allows for nested sessions that do not appear in the public headless server listing.
  • Run the executable to start the client.

Configuration pour la sauvegarde de monde locale ou dans le Cloud

Pour configurer le client/serveur dédié afin qu'il agisse comme serveur de stockage local, réglez votre monde sur "saveAsOwner" : "LocalMachine" (sera remplacé après la première exécution par son startWorldURL unique ) ainsi que "saveOnExit" : true et votre autoSaveInterval.
souhaité Si vous souhaitez que les données mondiales soient sauvegardées dans le cloud (un compte Neos dédié sera nécessaire)
Veuillez utiliser la commande shutdown pour permettre au serveur de sauvegarder les modifications non sauvegardées lors de l'arrêt. Exemple de fichier de configuration : {

 "tickRate": 60.0,
 "usernameOverride": null,
 "loginCredential": null,
 "loginPassword": null,
 "startWorlds": [
   {
     "sessionName": "My World 1",
     "description": null,
     "maxUsers": 32,
     "accessLevel": "LAN",
     "tags": null,
     "mobileFriendly": false,
     "loadWorldPresetName": "BasicEmpty",
     "saveAsOwner" : "LocalMachine",
     "autoRecover": true,
     "saveOnExit" : true,
     "autoSaveInterval" : 240,
     "forcedRestartInterval": -1.0
   }
 ],
 "dataFolder": null,
 "cacheFolder": null
}

Configration using Cloud Variables

For more details for Cloud Variables, see Cloud Variables.

  • The roleCloudVariable allows auto-assigning a role based on a cloud variable.
    • This lets you define a cloud variable and assign value to users to determine their role in given world.
    • The variable needs to be of type string. The value you assign equals the name of the role you want to grant to given user.
    • It is STRONGLY recommended to make sure you're using cloud variable that you can write into on behalf of other users (definition_owner), otherwise users might be able to assign themselves a high permission role.
    • If no value is set for given user, the usual method to determine default role is used
  • The allowUserCloudVariable allows using cloud variable to always allow user into a session.
    • The cloud variable needs to be of type bool and set to true for given user.
    • This is equivalent of the user being sent an invite - they can join regardless of MaxUsers limit and even if the session is set to Private (they need to obtain).
    • Same recommendations as above apply, please make sure you use the right cloud variables that you have proper control over.
  • The denyUserCloudVariable allows denying join access to users via a cloud variable.
    • This functions similarly to allowUserCloudVariable, except when the value for given user is true, they will be denied access
    • This always takes precedence over other variables
  • The requiredUserJoinCloudVariable to world startup configuration, which requires a cloud variable to be set to true for given user so they can join
    • You can set a custom deny message via requiredUserJoinCloudVariableDenyMessage
    • If the variable isn't set to true for given user, they won't be allowed access
    • Setting the variable to true won't automatically grant access (unlike allowUserCloudVariable) and will still need to pass other rules - public access, session user limit and so on
    • allowUserCloudVariable takes precedence over this one, allowing to always allow given user access
    • This variable is useful for controlling access to a session, without bypassing the session max user limit and providing a custom message

Commands

See Headless Client Commands for a list of commands.