set / seta / sets / setu

[Courgette]

Quelles différences y-a-t'il entre les directives set, seta, sets et setu du moteur quake3 ?

D'après le code de ioQ3 :

• set : Permet d'assigner et de définir des cvar arbitraires depuis la console, même si elles n'étaient pas déclarées dans le code C.
• setu : comme set, mais flag la cvar comme étant une information utilisateur
• sets : comme set, mais flag la cvar comme étant une information serveur
• seta : comme set, mais flag la cvar comme étant une information archivée

Mais ça ne m'avance pas beaucoup tant que je ne connais ce que c'est qu'une cvar flagguée comme 'utilisateur' / 'serveur' ou 'archivée'...

Aussi, lorsque j'édite la config de mon serveur, comment est-ce que je sais laquelle de ces directive utiliser ?

[Kalish]

Peut-être plus clair :

• set : la cvar est définie et lisible dans tous les contextes. Non archivée en fin de serveur / client.
• setu : la cvar est définie et lisible localement par le client seulement. Non archivée.. ( très utile en gtv pour séparer client / serveur )
• sets : la cvar est définie et lisible par le serveur seulement. Non archivée.
• seta : la cvar est définie et lisible dans tous les contextes. Archivée dans le qconfig_server.cfg ( serveur) ou qconfig.cfg ( client )

bref, sachant que tu charges ta cfg fait maison au démarrage côté serveur, et que tu te fiches de savoir si ta cvar est archivée à l'extinction, "set" est la solution multi-usage

[linkboss]

Moi, en parlant des CVar, j'aurais bien aimé savoir comment l'on s'en sert dans le code ioUrTded, car les multiples fonctions CVar_* ne m'inspirent guère. J'avais réussi (en 2-3 heures), à créer une CVar, mais j'ai paumé le code et donc je sais plus comment faire...

[Barbatos]

Ben c'est pourtant pas très compliqué linkboss, passes sur IRC et hl moi j'vais tenter de t'expliquer.

[Courgette]

Merci pour ce début d'explication.

bref, sachant que tu charges ta cfg fait maison au démarrage côté serveur, et que tu te fiches de savoir si ta cvar est archivée à l'extinction, "set" est la solution multi-usage

Toutefois, comment expliquer le comportement suivant :

Si dans mon server.cfg, je mets

Code : Tout sélectionner

set " Website" "http://www.ubu-team.org"

et que je redémarre le serveur, la cvar " Website" n'existe pas et n'est pas visible si je fais un quakestats -R

Alors que si dans ce même fichier de config, je mets

Code : Tout sélectionner

sets " Website" "http://www.ubu-team.org"

tout réagit comme je le souhaite.

Peut-être que ça vient du fait que je déclare un nouvelle cvar qui est inconnue du code C et qui n'a donc pas déjà de Flag (utilisateur/serveur/archivée) par défaut ?

Sinon, que fait un setu si utilisée dans une config de serveur ? le serveur force les clients qui se connectent à avoir cette cvar ?

[Kalish]

Dans le premier cas, elle doit être accessible en "interne", c'est à dire avec le rcon. Essaye en rcon de tapper "website" pour voir .

Quand a setu, non, ce ne sera valable que sur saisi sur un client (enfin, normalement)

[Courgette]

sur l'excellent site TaggedZi's Urban Terror Oasis (section Scripting), j'ai trouvé les informations suivantes :

seta : sets the variable with the archive flag will save the last setting to q3config.cfg and reload that setting every time you run the game. Any changes to variables with an A for the class ID are automatically stored in q3config.cfg - LOKi

sets : sets the variable with the serverinfo flag, so it will be transmitted from a server to connecting clients - LOKi

setu : sets the variable with the userinfo flag, so it will be transmitted from a client to a server while connecting - LOKi

Ce qui explique pourquoi il faut utiliser "sets" si on souhaite que l'info soit visible en faisant une requête getinfo ou getstatus sur un server.

Pour ce qui est de "setu", je ne vois pas encore les implications que ça a... Sans doute que ca apparaît ensuite dans la réponse de dumpuser ou dans les lignes de log clientInfo*

[MathX]

En effet, une variable déclarée coté client avec setu s'affiche bien dans le ClientUserInfo.
Ca aurait été pratique de le savoir plutôt, ça peut être une bonne solution pour s'auth chez un bot comme Kiwi ou b3 depuis un login / mdp sans passer par le GUID (qui n'est pas une valeur sure). Un petit bind et c'est réglé.

EDIT : Ou plutôt, ça serait une très bonne méthode pour pouvoir réactualiser le GUID d'un compte utilisateur. Comme ça, si la qkey est perdue, l'user peut lancer le script et le bot peut ainsi remettre le GUID à jour avec les anciens droits associés.

[sta0]

Sauf que c'est visible sur tous les serveurs, .... qui a parlé de vol d'identifiants ? :d

[MathX]

Bah, suffit de lancer le bind quand on est connecté sur le serveur et comme c'est pas archivé ...