• [ 1 ] Une classe en PHP pour lire les informations renvoyées par un serveur halfd (l'expérience a montré que cela provoquait du lag sur le serveur).
• [ 2 ] Une API en C++ pour lire directement les informations sur le serveur counter-strike (y compris utilisation de rcon).
• [ 3 ] Une réflexion (à dédaut de plus) sur le comportement des bots.

C'est donc une classe en PHP pour lire les informations renvoyées par un serveur halfd (l'expérience a montré que cela provoquait du lag sur le serveur).
J'ai programmé ça à la demande de Sioc pour son serveur, il n'était pas satisfait de csadmin et voulait y faire des modifications.

Voilà les fichiers, il y a une version avec affichage debug et une utilisable directement. Ils sont prévus pour ètre enregistrés et non pas affichés (sauf la version démo de cs_tcl_list-debug) :

• cs_tcl_list-debug.php

  version démo

• cs_tcl_list.php.

Je veux avancer un peu avant de publier des fichiers. Voilà ce que fait mon programme pour le moment :

• Connexion à un serveur counter-strike (IP, port et éventuellement mot de passe rcon fournis comme paramètres), normalement, ça doit marcher pour tout serveur half-life mais j'ai pas testé.
• Possibilité de connexion/déconnexion en fonction des besoins et sur plusieurs serveurs simultannément (traitement de chaque serveur comme une instance de la classe).
• interrogation du serveur pour les données "infos", "details", "rules" et "players".
• début d'implémentation de rcon : analyse des informations renvoyées par "rcon status" et capacité d'envoyer des commandes.
• Cache de données avec temps minimum réglable. Si les données sont présentes depuis moins longtemps que cette valeur, elles ne sont pas rechargées mais prises dans le cache. Le cache est indépendant pour chaque type d'info.
• Le simple fait de demander une donnée suffit pour que la connexion se fasse si necéssaire (y compris analyse des données).
• rcon est maintenant intégré pour les commandes "à la main" et pour la commande status (qui renvoie une info fausse en ce qui concerne le nombre de joueurs si quelqu'un est en train de se connecter, d'ailleurs). Si le mot de passe rcon a été saisi, c'est rcon qui sera utilisé, sinon il sera ignoré.
• Possibilité d'avoir une connexion unique (open/close) pour toutes les actions ou d'avoir une connexion/déconnexion à chaque commande (connexion au besoin seulement).

• Intégration complète de rcon (y compris des commandes spécifiques aux divers bots).

• Un programme qui récupère des infos comme la liste des joueurs et la map pour un serveur donné (s'intègre très bien dans les fonctions d'un bot irc).
• Un programme qui sert de console (il envoie ce qu'on tape et affiche le résultat).

• librairie PHP (chargement avec la fonction dl() ou dans php.ini) permettant l'accès à ces données bien plus vite qu'avec php lui-même ou en passant par un programme de type script ou un serveur comme halfd. Pour l'instant un problème de compilation m'arrête, toute contribution serait la bienvenue.
• Interface PHP/IRC pour pouvoir parler avec des gens dans une partie quand on est sur irc.
• Outils d'administration counter-strike (ligne de commande linux et pourquoi pas programme windows).

Disons que j'aimerais bien programmer un bot pour counter-strike mais que j'ai pas le temps pour le moment, alors histoire que ça se perde pas, voilà quelques reflexions (n'hésitez pas à m'en faire d'autres en m'écrivant par e-mail.

Donc quelques idées :

• Un bot se doit de ne pas tirer en pleine tête à coup sûr : c'est un remplaçnt d'humain, il se doit d'être faillible.
• Les waypoints doivent être propres à chaque bot et être calculés par lui pour éviter les problèmes liés à l'installation de nouvelles map ou au changement d'anciennes (calcul des waypoints d'après une analyse du niveau par calcul d'un coût pour les differents trajets).
• Un bot ne doit pas accepter de rester sur place ni de tourner en rond, il doit avoir un objectif (trouver la bombe, la proteger, trouver un otage, trouver un ennemi, etc...) et doit utiliser cet objectif pour bouger.
• Un bot ne doit pas avoir des yeux dans le dos, par contre, il doit se retourner s'il reçoit des dégâts sans voir d'ennemi.
• Il faudrait gérer les obstacles pour que les bots soient capables de les contourner ou escalader en fonction des besoins.
• A suivre...