41 réponses à ce sujet

[Anakha]

Participation au développement du Bot

Afin de simplifier de nombreux aspects de la gestion du bot, il a été décidé de mettre le bot sur un gestionnaire de version. Nous hébergerons donc les sources du bot sur GitHub qui utilise, comme son nom l'indique, git (c'est la même chose que svn avec des différences)

Ce tuto est destiné aux gens qui ne savent pas / pas bien utilisé Git avec GitHub, pour les autres, l'information qui vous intéresse se trouve là : https://github.com/M...3ROS-ArreatCore

Je décris ici comment participer au développement, pas comment simplement récupérer les sources sur GitHub (ce qui est plus simple que tout ce qui est dis ici, mais sera détailler autre part)

Pour les personnes qui participent activement aux devs, envoyez moi un PM avec votre nom GitHub et je vous ajouterai au repository principal



I. Intérêts d'utiliser git / svn

Les intérêts sont assez simples en fait, mais utiles :
- Gérer les ajouts / modifications de chacun de façon claire et facilement intégrables dans les version en cours
- Pouvoir suivre le développement plus facilement
- Rend l'accès aux sources (à jours) plus facilement pour permettre à n'importe qui d'y contribuer

De façon complètement annexe, GitHub permet également d'avoir un système de ticket, comme beaucoup de site similaire, qui pourra servir pour lister les bugs / amélioration / nouveautés à faire


II. Comment participer

Tout d'abord il vous faut un compte. Pour ce faire, allez ici : https://github.com/join puis :

• Entrez les informations de votre compte (login, pass, mail) et faites créer le compte
• Choisissez ensuite "Free" comme "personal plan"
• Vous arrivez ensuite sur votre dashboard, qui est votre page d'accueil du compte.

Bravo ! Le plus important est fait !

Maintenant, on va distinguer deux types de personnes :

• Celles qui vont avoir directement accès au repository principal
• Les users "lambda" qui veulent contribuer au bot

Pourquoi cette distinction ?
Celà me permet de gérer simplement les gens qui développent de façon régulière sur le bot, et les gens qui arrivent et veulent simplement contribuer un peu, pour tester, aider, ou autre.
Par contre, ça n'empêche personne de contribuer tout autant au bot !


III. Quelques règles

• Si vous avez accès au repository principal : faites une branch pour vos dev et ne fusionnez que quand tout fonctionne !
• Idem pour les forks : ne faites pas de pull-request si vous n'avez pas test que tout fonctionne avant !
• Faites vous plaisir à dev !

[Anakha]

Entrons dans le vif du sujet

Pour commencer, les personnes qui n'ont pas accès au repository principal, vous devrez d'abord effectuer un fork (si je parle chinois, lisez le petit lexique dans le prochain post).

1. Faire un fork

Allez sur cette page : https://github.com/Kyria/ArreatCore vous verrez alors ces boutons :

Spoiler

Pour résumer les boutons de droites :
- Watch : permet de vous abonner au repository : vous serez alors informé de tout ce qui se passe dessus. Les notifications sont présent sur votre dashboard, ou certains par mail.
- Star : permet de dire à la communauté GitHub "ce répository est sympa!" (pour résumer)
- Fork : c'est ce qui nous intéresse

Cliquez donc sur "Fork", vous aurez une page d'attente puis vous serez redirigé vers votre propre projet pour le bot, ce qui ce voir ici en jaune :

Spoiler

Il est important de noté que, si vous faites un fork, vous travaillerez dessus seul puis vous pourrez envoyer vos modifications vers le projet maître (ce qui s'appelle un "pull request")

2. Récupérer les sources

Etant donné que le projet est en AutoIt, toutes mes indications seront faites pour la version Windows.

Comme les lignes de commandes ne sont pas forcément la tasse de thé de tout le monde, nous allons téléchargé l'outil graphique de GitHub pour gérer les projets : http://windows.github.com/ téléchargez et installé l'outils puis lancez le.

Au démarrage il vous demandera votre login et mot de passe GitHub et ce sera bon ! Si à la limite vous voulez choisir où mettre vos source, allez dans Tools => Options => Default storage directory et mettez ce que vous souhaitez.

Dans l'application, dans la partie GitHub, sélectionnez votre login, puis cliquez sur "Clone"

Spoiler

Une fois ça de fait, vous aurez le code sur votre PC (visible dans la partie "Local" de l'application.

3. Envoyer votre code

Nous allons partir du principe que vous avez fait des modifications à votre code et que vous souhaitez à présent envoyer vos modifications. Avant tout, il faut connaitre les "états" qu'on peut avoir :
- Code "non commit" : c'est les modifications / ajouts que vous n'avez pas encore
- commit: vous avez figé votre code en local avec un label pour tracer vos modifications
- commit synchronisé : vous avez envoyé (push ou synchronized) vos commits vers GitHub.

Donc tout d'abord, allez dans l'application GitHub (que vous avez télécharger) puis dans Local -> repositories et là double cliquez sur ArreatCore, vous arriverez sur une interface similaire à ça :

Spoiler

Ici vous pouvez choisir les fichiers que vous souhaitez commit, la description courte du commit (obligatoire), la description longue (optionnelle). ensuite cliquez sur "Commit to XXXXX" (XXXXX représente le nom de la branche, par défaut Master)

Une fois le commit fait, vous pouvez voir que votre commit est passé dans "Unsynced Commits" :

Spoiler

Puis, en cliquant sur "Publish" en haut à droite, vous enverrez vos commit sur GitHub. Votre commit (ou vos commits si vous en avez plusieurs) passeront alors dans l'état "History" :

Spoiler

4. Comment récupérer les commits des autres

Pour ce faire, rien de plus simple : il suffit d'appuyer sur le petit bouton "Sync" dans la fenêtre où vous faites vos commit.

[Anakha]

Lexique

branch

Spoiler

Définition

cloner

Spoiler

Le clonage d'une repository est le fait de télécharger sur son pc les sources disponibles sur un repository donné (en lecture seule ou lecture/ecriture)

commit

Spoiler

Faire un commit ça veut dire qu'on "fige" ses modifications avec une description afin de pouvoir, plus tard, les push vers le serveur (GitHub ici)

push

Spoiler

C'est le fait d'envoyer ses commits vers le serveur (GitHub ici)

pull

Spoiler

C'est la récupération des modifications qui ont été faites et envoyé déjà par tous sur le repository auquel on participe

synchronized

Spoiler

Sur l'interface de l'application GitHub, ça permet de faire un pull

pull-request

Spoiler

Uniquement faisable par l'interface du site github, il s'agit d'envoyer les modifications qu'on a fait dans son fork vers le repository maître afin de partager ses modifications

[Anakha]

Réservé

Spoiler

(todo :
- expliquer comment mettre à jour son fork
- comment faire une branch
)

[Anakha]

Pour information ça commence à peine, donc il va falloir qu'on rode l'affaire

Pour la version actuellement présente : c'est la 8.1 avec la version 4.1 d'automatisation du bot

[Anakha]

Pour ceux que ça intéresse, vu que je me suis attaqué à l'uniformisation de tout le code (toutes les fonctions écrites de la même façon, toutes les variables écrites de la même façon, *déclaration de toutes les globales dans un fichier etc etc) voici la liste des fonctions avant/après du toolkit.

Après un après midi complet, j'ai fait le tour des 6700 lignes du toolkit.au3 et j'ai renommé / virer l'inutile (~700 lignes en moins)

En bleu : nom qui change
En rouge : fonction qui disparaît (soit pas utilisée, soit inutile et remplacé par maximum 2 ligne de code à 1-2 endroits max)
 diff_nom_fonction_toolkit.zip   13.47 Ko   483 téléchargement(s)

Je n'ai pas reporté les autres fichiers où j'ai fait des modifs du même genre, car le nombre de fonctions présentes est largement moins grand... y a pas 7000lignes dans ces fichiers !

Dans l'idée les conventions de code qu'on adopterait serait les suivantes :

Func NomDeFonction()
$typeNomDeVariable ou simplement $nomDeVariable

[Lapinrose]

Bonjour,

Déjà un grand merci Anakha, le code est lisible, homogène et claire (pas dû être facile ).

Je me suis lancé dans la lecture et le résumé de tout les fichier .au3 (constants.au3, FTP.au3, settings.au3, skills.au3, UsePath.au3, Toolkit.au3, main.au3). Globalement settings,ftp,constants,skills sont simples.
Mais :
UsePath.au3 utilise des algos que je dois encore étudié.
Toolkit.au3 comprend une tonne de fonction diverse et varié.
Main.au3 rassemble tout.

Je n'es pas trouvé Game.au3 ni player.au3 ou utils.au3, je pense que ces fichiers on été rassemblés dans main ou toolkit.

De plus :
-certain variable importante ne sont pas ou peux décrit, c'est à dire qu'est ce qu'elle stock et comment? (exemple : Pour le stockage des Path la structure me semble être $arr[5] = ($x, $y, $z, $a, $m_range), mais je n'est pas trouvé d'explication type x,y,z coordonnées cartésienne, a = ? , m_range = ?).
-la plus part des fonctions n'ont pas de description (ou alors minime) de leur fonctionnement, j'entend par la les types des variables d'entré , l'algorithme de la fonction simplifié (écrite en terme mathématique) et le résultats de sortie avec son type. ( exemple : fichier usePath.au3 getNextPosIndex on trouve une notes pour voire l'algorithme décrit mathématiquement en anglais, manque les types des arguments d'éntré avec leur représentation, le type du résultat).

Ceci ne sont que des exemples, ayant fraichement commencé à lire tout le code, je les trouverais peux être plus tard, mais je trouve dommage que toutes ces informations, qui me semble importante pour la compréhension des nouveaux arrivant, ne soient pas regroupées dans un fichier.

Voila mon petit projet de la semaine. Si des personnes sont intéressées pour m'aider envoyer moi un message pour répartir les tâches.

Merci.

EDIT : je n'avais pas la bonne version du bot j'ai chopper la V4_1 merci.

Modifié par Lapinrose, 05 February 2014 - 19:00.

[Anakha]

Je n'es pas trouvé Game.au3 ni player.au3 ou utils.au3, je pense que ces fichiers on été rassemblés dans main ou toolkit.

https://github.com/Kyria/ArreatCore/tree/master/lib
Avant c'était dans la branche "revamp"

De plus :
-certain variable importante ne sont pas ou peux décrit, c'est à dire qu'est ce qu'elle stock et comment? (exemple : Pour le stockage des Path la structure me semble être $arr[5] = ($x, $y, $z, $a, $m_range), mais je n'est pas trouvé d'explication type x,y,z coordonnées cartésienne, a = ? , m_range = ?).
-la plus part des fonctions n'ont pas de description (ou alors minime) de leur fonctionnement, j'entend par la les types des variables d'entré , l'algorithme de la fonction simplifié (écrite en terme mathématique) et le résultats de sortie avec son type. ( exemple : fichier usePath.au3 getNextPosIndex on trouve une notes pour voire l'algorithme décrit mathématiquement en anglais, manque les types des arguments d'éntré avec leur représentation, le type du résultat).

Ca devrait être dans les commentaire de fonctions, mais vu qu'il n'y a quasi pas de commentaires... Je pense avoir répondu à ta question, et non je n'ai pas ces infos.

Les gens (pour la plupart) ne comprennent pas qu'un code avec du commentaire (rien que pour les fonctions, j'en demande pas plus) est un meilleure code qu'un code "propre" sans commentaire.

Sinon :
UsePath.au3 c'est la gestion des mouvement, ça permet en gros de faire tes déplacements selon les séquences, gérer les mobs sur le chemin et la gestion du "retour" sur ce chemin (genre si tu t'éloigne de trop, il va éviter de passer plusieurs fois au même endroit, de faire des allés/retour pour rien etc.
<br style="color: rgb(28, 40, 55); font-size: 13px; line-height: 19.5px; background-color: rgb(250, 251, 252);">Toolkit.au3 c'est toutes les fonctions qui font de la lecture mémoire dans d3<br style="color: rgb(28, 40, 55); font-size: 13px; line-height: 19.5px; background-color: rgb(250, 251, 252);">

[Lapinrose]

Je n'es pas trouvé Game.au3 ni player.au3 ou utils.au3, je pense que ces fichiers on été rassemblés dans main ou toolkit.

https://github.com/Kyria/ArreatCore/tree/master/lib
Avant c'était dans la branche "revamp"

De plus :
-certain variable importante ne sont pas ou peux décrit, c'est à dire qu'est ce qu'elle stock et comment? (exemple : Pour le stockage des Path la structure me semble être $arr[5] = ($x, $y, $z, $a, $m_range), mais je n'est pas trouvé d'explication type x,y,z coordonnées cartésienne, a = ? , m_range = ?).
-la plus part des fonctions n'ont pas de description (ou alors minime) de leur fonctionnement, j'entend par la les types des variables d'entré , l'algorithme de la fonction simplifié (écrite en terme mathématique) et le résultats de sortie avec son type. ( exemple : fichier usePath.au3 getNextPosIndex on trouve une notes pour voire l'algorithme décrit mathématiquement en anglais, manque les types des arguments d'éntré avec leur représentation, le type du résultat).

Ca devrait être dans les commentaire de fonctions, mais vu qu'il n'y a quasi pas de commentaires... Je pense avoir répondu à ta question, et non je n'ai pas ces infos.

Les gens (pour la plupart) ne comprennent pas qu'un code avec du commentaire (rien que pour les fonctions, j'en demande pas plus) est un meilleure code qu'un code "propre" sans commentaire.

Je propose juste de les listés dans un fichier à part type txt comme une libraire ou une aide.

[Anakha]

tu peux pas faire une doc avant d'avoir commencé à commenter le code Personne ne le tiendras à jour

Dans l'idée il faut créer les docs à partir des commentaires, non l'inverse, sinon ça part dans l'oublie

[TheCat31]

Pour moi un bon commentaire devrait contenir :

• Date création, date mise à jour
• Descriptif de la fonction (à quoi je sers? par qui je suis appelé?)
• Liste des variable d'entrées et leur définition
• Liste des variable de sortie et leur définition (et leur destination)

[Anakha]

dans le cas présent il faut ajouter

• Liste des globales qui sont assignées / modifiées

Vu que tous le bot n'utilise quasi que des globals :/

[Adjudant]

Pour moi un bon commentaire devrait contenir :

• Date création, date mise à jour
• Descriptif de la fonction (à quoi je sers? par qui je suis appelé?)
• Liste des variable d'entrées et leur définition
• Liste des variable de sortie et leur définition (et leur destination)

C'est discutable et c'est un débat de longue date chez les devs, quelque soit la techno utilisée... De plus les devs qui commentent pas leur boulot (même pour des projets) sont juste à mettre au bûcher selon moi Surtout maintenant avec les IDE qui nous mâchent le travail pour commenter un minimum, ne serait-ce que les fonctions...

Mais bon, ce n'est pas la vision de tout le monde... J'ai appris récemment par exemple que les devs de Microsoft ne commentaient pas leur travail (sauf si trop vraiment trop complexe ou s'ils devaient partager leur code avec le public)... Pour eux, tout doit être limpide grâce au nom des variables et autres fonctions... Si un dev lit le code d'un autre et ne le comprend pas, c'est qu'il y a un problème dans le nommage ou que le code est trop compliqué pour ce qu'il doit faire... Bref, c'est plutôt extrême comme vision...

[Anakha]

Pour moi un bon commentaire devrait contenir :

• Date création, date mise à jour
• Descriptif de la fonction (à quoi je sers? par qui je suis appelé?)
• Liste des variable d'entrées et leur définition
• Liste des variable de sortie et leur définition (et leur destination)

C'est discutable et c'est un débat de longue date chez les devs, quelque soit la techno utilisée... De plus les devs qui commentent pas leur boulot (même pour des projets) sont juste à mettre au bûcher selon moi Surtout maintenant avec les IDE qui nous mâchent le travail pour commenter un minimum, ne serait-ce que les fonctions...

Mais bon, ce n'est pas la vision de tout le monde... J'ai appris récemment par exemple que les devs de Microsoft ne commentaient pas leur travail (sauf si trop vraiment trop complexe ou s'ils devaient partager leur code avec le public)... Pour eux, tout doit être limpide grâce au nom des variables et autres fonctions... Si un dev lit le code d'un autre et ne le comprend pas, c'est qu'il y a un problème dans le nommage ou que le code est trop compliqué pour ce qu'il doit faire... Bref, c'est plutôt extrême comme vision...

Pour ma part, limpide ou pas, tu dois pouvoir connaitre le fonctionnement d'une classe / d'un objet / d'une fonction avec le nom ET le commentaire, sans devoir lire le code. Que le code soit bien écrit permet de ne pas commenter le contenu.

Après, sans être mauvaise langue avec qui que ce soit : le code du bot est tout sauf ça a l'heure actuelle (nom qui veulent rien dire, pas de commentaires...)

Moi ce que je veux pour le bot autoit c'est au minimum le commentaire des blocs de fonctions (cf TheCat)

[sebo]

Tu attends ce genre de commentaires ?

Spoiler

;===============================================================================
;
; Function Name:    GuiCtrlCreateHyperlink()
; Description:    Creates a label that acts as a hyperlink
;
; Parameter(s):     	$s_Text      	- Label text
;               			$i_Left   	- Label left coord
;               			[$i_Top]      - Label top coord
;               			[$i_Width]    - Label width
;               			[$i_Height]   - Label height
;               			[$i_Color]    - Text Color
;               			[$s_ToolTip]  - Hyperlink ToolTip
;               			[$i_Style]    - Label style
;               			[$i_ExStyle]  - Label extended style
;
; Requirement(s):   None
; Return Value(s):  Control ID
;
; Author(s): 
;
;===============================================================================

[Anakha]

Dans l'absolu, ouai x)

[Alkan]

Bonjour à tous,

Ne serait-il pas plus profitable de tout simplement scinder en deux projets et laisser les utilisateurs faire un choix sur la version qu'il préfère?
Il y aurait une version communautaire qui vivrait en fonction des idées/modifications des développeurs/utilisateurs
Et il y aurait une version prête à être utiliser, après chacun viendrait ajouter les fonctions qu'il désire.
De mon point de vue, ce n'est pas une perte de temps d'avoir deux versions du bot disponibles. C'est juste de projet qui ont une base commune et qui vont prendre deux chemins différents (un peu comme les différentes de distribution de linux )

Vous avez tous des qualités, c'est indéniable. Il serait dommage de priver la communauté de vos talents.

Je vous souhaite à tous une bonne soirée.

Modifié par Anakha, 10 March 2014 - 20:57.
J'ai léger changé / enlevé certaines chose, (pour enlever le sujet précédent) n'hésite pas à éditer si besoin

[Anakha]

Pour répondre de façon "neutre":

Si et non : d'une certaine manière, ça l'est, car effectivement ça permet une version "light" et une version avancée du bot et libre aux gens de choisir.

Le "problème" : la modification faites par les personnes qui gère la version de base se font "dans leur coin" et la release n'est faites qu'avec l'intégralité des modifications : ce qui est le problème majeure dans cette "bi-version", car on ne peut pas tracer facilement (sans svn/git/outils similaire) la liste des modifications à faire.

Pourquoi ce problème : les raisons se trouve au dessus et ici : http://forum.gmstemp...showtopic=15118
Pour simplifier : une structure différente du toolkit (épurée et "divisé" par fonctionnalité dans la version github) et les noms des fonctions qui ont changés (pour tout avoir écrit dans une même "convention de nommage"). Donc le "merge" entre les deux version n'est pas évident, même pour une chose "aussi simple" que les offsets..

[Duciel]

Merci à toi pour tout ça, c'est la première fois que j'utilise GIT et c'est une bonne entrée en matière je trouve. J'ai quelques idées de fonctions à ajouter / améliorer. Cependant je regarde le changelog et je vois que c'est la version 8.0a la dernière en date. Est-ce le changelog qui n'est pas à jour ? Si non y a-t-il un autre commit avec les sources de la dernière version ou dois-je le faire manuellement ?

Je pense me lancer par une analyse un peu plus poussée du code que ce que j'ai fait jusqu'à présent. Mais j'ai quelques idées d'amélioration, en particulier pour le mode hardcore (qui est le mode que j'utilise actuellement).

[TheCat31]

@Duciel, ce n'est plus la version en cours.

Version pour ROS est ici, qui risque de ne plus fonctionner suite à la maintenance de ce jour, il faudra attendre 18h00 CET.