Guide rapide concernant l'inscription sur le site officiel du jeu. Créez ainsi votre compte joueur qui permet d'être authentifié sur les serveurs de jeu de la 4.2 !
Forums Échanges et discussions entre membres de la communauté
Kiwi : outil d'administration serveur léger
-
PtitBigorneau
- Messages : 516
- Enregistré le : 19 oct. 2008, 13:50
- Localisation : brest
-
Diconico07
- Messages : 1783
- Enregistré le : 18 juin 2008, 18:14
- Localisation : sur la loire
-
Diconico07
- Messages : 1783
- Enregistré le : 18 juin 2008, 18:14
- Localisation : sur la loire
, moins lourd que MySQL, mais s'en est quand même un.
J'en étais sûr que des gens allaient troller du genre. :p
Pour « résumer », si je passe du fichier à SQLite, c'est tout de un, après réflexion, que ça me semble primordial dans la fonctionnement de Kiwi. Avec le fichier, il m'était impossible de par exemple, stocker tous les clients avec guid, dernier nick, dernière ip et les droits sans que ça devienne le bazar. Maintenant, je peux tout stocker sans souci et m'y retrouver encore plus facilement. SELECT * FROM users WHERE GUID=%s, c'est pas mieux qu'une fonction où il faut chaque fois lire le fichier, comparer les lignes, etc ? Il m'est aussi possible de rajouter des bans et bien entendu sans rajouter dix mille fichiers, une interaction externe est aussi possible (programme spécifique, web panel, etc) !
La différence entre MySQL et SQLite est aussi tout à fait explicite :
1) MySQL nécessite un programme serveur (démon) qui utilise des ressources, avec SQLite, c'est une API spécifique à Python qui se charge de lire le fichier et de le rendre utilisable via des requêtes SQL;
2) Presque rien ne change pour l'utilisateur ! Il y aura juste un setup.py qui permettra de configurer le fichier de configuration, de créer la base de données et le log. La base de données étant stockée dans un fichier comme le log, la nouvelle version ne nécessitera aucun programme externe, comme toujours. Je ne souhaite pas m'écarter de l'installation et l'utilisation simple du bot, sans quoi il perdrait son intérêt.
3) Coté performances, rien ne change. Vu que b3 utilise le démon MySQL qui est (trop) souvent sollicité, ça prend cher en ressources. Ici, Kiwi utilisera autant de fois la BDD que le fichier actuel admins.log et vu que l'API SQLite3 de Python lit en fait le fichier BDD comme un autre, rien ne change (encore :p).
La seule différence, c'est que le bot ne sera plus compatible avec les versions 2.4 de Python (SQLite3 est uniquement à partir de python 2.5), il faudra donc faire la mise à jour pour ceux qui ne l'ont pas. Globalement, aucun changement sous Windows car vous avez probablement la 2.5/6, comme Mac, juste Linux pour les machines sous linux qui ont encore la dernière version (etch -> lenny ffs
).
Bref, sauf étonnant retournement de situation, Kiwi utilisera SQLite (parce qu'il le vaut bien :>).
Pour « résumer », si je passe du fichier à SQLite, c'est tout de un, après réflexion, que ça me semble primordial dans la fonctionnement de Kiwi. Avec le fichier, il m'était impossible de par exemple, stocker tous les clients avec guid, dernier nick, dernière ip et les droits sans que ça devienne le bazar. Maintenant, je peux tout stocker sans souci et m'y retrouver encore plus facilement. SELECT * FROM users WHERE GUID=%s, c'est pas mieux qu'une fonction où il faut chaque fois lire le fichier, comparer les lignes, etc ? Il m'est aussi possible de rajouter des bans et bien entendu sans rajouter dix mille fichiers, une interaction externe est aussi possible (programme spécifique, web panel, etc) !
La différence entre MySQL et SQLite est aussi tout à fait explicite :
1) MySQL nécessite un programme serveur (démon) qui utilise des ressources, avec SQLite, c'est une API spécifique à Python qui se charge de lire le fichier et de le rendre utilisable via des requêtes SQL;
2) Presque rien ne change pour l'utilisateur ! Il y aura juste un setup.py qui permettra de configurer le fichier de configuration, de créer la base de données et le log. La base de données étant stockée dans un fichier comme le log, la nouvelle version ne nécessitera aucun programme externe, comme toujours. Je ne souhaite pas m'écarter de l'installation et l'utilisation simple du bot, sans quoi il perdrait son intérêt.
3) Coté performances, rien ne change. Vu que b3 utilise le démon MySQL qui est (trop) souvent sollicité, ça prend cher en ressources. Ici, Kiwi utilisera autant de fois la BDD que le fichier actuel admins.log et vu que l'API SQLite3 de Python lit en fait le fichier BDD comme un autre, rien ne change (encore :p).
La seule différence, c'est que le bot ne sera plus compatible avec les versions 2.4 de Python (SQLite3 est uniquement à partir de python 2.5), il faudra donc faire la mise à jour pour ceux qui ne l'ont pas. Globalement, aucun changement sous Windows car vous avez probablement la 2.5/6, comme Mac, juste Linux pour les machines sous linux qui ont encore la dernière version (etch -> lenny ffs
).Bref, sauf étonnant retournement de situation, Kiwi utilisera SQLite (parce qu'il le vaut bien :>).
Grande nouvelle : le plug-in de statistiques IG codé par Tycale arrive à terme !
Globalement, il y a deux commandes : !stats et !awards.
!stats comprend : le localisation des hits (ex. Head 20pc - Torso 50pc - Legs 10pc - Arms - 20pc), les TK, les kills par HE et les CAP.
!awards comprend : Kills / BestKills - HS / BestHS - Streaks / BestStreaks - le skill - la position en skill (ex : 1/2, afin d'avoir une autre vue sur la partie)
Et j'arrive à deux soucis : faut-il rajouter le ratio, si oui, où ? Et aussi, faut-il sauvegarder le skill dans la base de données (ici le fichier kiwi.db de base) pour avoir une évolution à long terme ou pas et ainsi les récupérer à chaque partie ?
Vos avis sont plus que les bienvenus !
Globalement, il y a deux commandes : !stats et !awards.
!stats comprend : le localisation des hits (ex. Head 20pc - Torso 50pc - Legs 10pc - Arms - 20pc), les TK, les kills par HE et les CAP.
!awards comprend : Kills / BestKills - HS / BestHS - Streaks / BestStreaks - le skill - la position en skill (ex : 1/2, afin d'avoir une autre vue sur la partie)
Et j'arrive à deux soucis : faut-il rajouter le ratio, si oui, où ? Et aussi, faut-il sauvegarder le skill dans la base de données (ici le fichier kiwi.db de base) pour avoir une évolution à long terme ou pas et ainsi les récupérer à chaque partie ?
Vos avis sont plus que les bienvenus !
Il faudra vraiment taper la commande pour obtenir ses informations ? Ça serait pas mieux d'offrir la possibilité de le dire à chaque mort ou toutes les deux morts automatiquement en privé à la personne concernée ? Car ça va puer le flood si la seule possibilité d'obtenir ses informations est une commande à taper, je le vois gros comme une maison.
Je pense qu'il serait beaucoup plus pratique de le dire automatiquement comme on le trouve sur les serveurs ~SG~.
Autre question sinon, comment serait calculé le skill ? Comme sur les autres systèmes dans le genre B3 je pense, mais comment cela est-il calculé de façon précise ? J'ai toujours trouvé sympa de mettre le nombre de fois que l'on a touché sur une partie également, comme sur les serveurs ~SG~ toujours, avec Hits. Peut-être le rajouter dans ce qui est appelé ici awards.
Bonne soirée,
Skaz.
Je pense qu'il serait beaucoup plus pratique de le dire automatiquement comme on le trouve sur les serveurs ~SG~.
Autre question sinon, comment serait calculé le skill ? Comme sur les autres systèmes dans le genre B3 je pense, mais comment cela est-il calculé de façon précise ? J'ai toujours trouvé sympa de mettre le nombre de fois que l'on a touché sur une partie également, comme sur les serveurs ~SG~ toujours, avec Hits. Peut-être le rajouter dans ce qui est appelé ici awards.
Bonne soirée,
Skaz.