Renaud Guezennec a écrit 98 commentaires

Les sources prises sur github ? L'archive zip automatique ?

Tu as bien suivi les instruction du wiki pour la compilation sur linux ?
http://wiki.rolisteam.org/index.php/CompilationLinux

Après je t'invite à poster un ticket sur le tracker du projet.

Oui, je sais bien que MapTool est très utilisé mais pas forcement par la communauté française.

Sinon pour les questions:
1/ Je n'ai pas compris. Oui la première version c'était un peu à l'arrache mais bon, c'était la première version.
Rolisteam est compatible linux. Sinon je n'aurais pas poster une dépêche sur linuxfr. Rolisteam v1.7 ne compile pas avec Qt5.5. J'ai fais mon développement sous Qt5.4. J'ai réparé cela hier sur le dépôt.

2/ Non, principalement par crainte des lois sur les droits d'auteurs. Je laisse l'échange de musique (en streaming ou même en fichier distant) ne me semble pas une bonne idée si je veux éviter des ennuis avec la Sacem. C'est peut-être extrême mais prudence est mère de sureté.

Non, la complexité d'un chat vocal, je préfère la laisser à Mumble, TeamSpeak ou autre. D'abord les cartes vectorielles.

Avec cette version, il est possible de jouer de la musique via des streams. Rolisteam n'est qu'un client de ses flux. C'est un pas en avant. Avec le serveur standalone, nous verrons ce qu'on peut améliorer.

3/ Cela commence à arriver. Dans cette version, il y a l'arrivée des thèmes. Il est possible de les exporter/importer depuis un fichier json (.rskin).
Pour les dés, les alias de dés du MJ sont partagés avec ses joueurs.

Merci :-p

PS: Non, il n'y a plus de gestion de shadowrun. Il y a une faute dans le paragraphe: géré -> gérait. C'était très mal architecturé et ne collait pas vraiment à la philosophie que je souhaite mettre en place dans rolisteam.

Oui, pas de problème. Déjà faire la promo du soft, l'utiliser et faire des retours pour le faire avancer. C'est déjà bien suffisant.

Merci, pour le site de musique. Je ne connaissais pas. Typiquement, je pourrais faire un système qui ouvre directement les fichiers présents sur ce site (avec leur accord, of course).

1/ effectivement, c'est un petit problème de droit. Le mj a tous les droits la dessus. Il peut débloquer la situation.
2/ effectivement
3/ Pour le moment, non car il n'y a pas de mode serveur stand-alone mais c'est mon objectif.
4/ Non, je n'ai pas fait de test avec l'ipv6, c'est à prévoir
5/ Je pensais faire une sorte de règle qui mesure une distance, j'ai espoir de passer les cartes dans un mode vectoriel. Cela sera plus sympa.
6/ Pour les musiques, c'est une limitation, mais pour des raisons de bande passante et de légalités. C'est bien comme cela. Je vais cependant implémenter l'utilisation de flux audio. C'est probablement très discret comme utilisation mais cela ouvrira un peu plus les possibilités.
7/ il me faudra plus de détail.
8/ C'est déjà possible. Tu fais ouvrir plan > et tu sélectionnes une image.
9/ Oui, j'ai longtemps hésiter.
10/ Tu ouvres un tchat et tu tapes une commande de dés: !1d10 ou !6G4 (pour du l5R), !3d6 … Il y a pas mal de documentation sur les différents systèmes: http://wiki.rolisteam.org/index.php/Tchat
DiceParser. C'est le futur. C'est beaucoup plus générique (et mieux écrit) que le système actuel qui est moche et très complexe à maintenir.
11/ Cela vient de la doc de rolistik. Il faut savoir que rolisteam est un fork de rolistik. Je pense faire un peu de ménage la dedans.

C'est mon objectif de le rendre utile même offline. J'ai une branche en réécriture avec l'ouverture de pdf, les plans vectoriels, une gestion des ressources (images/plans) plus fines. Elle est loin d'etre utilisable mais cela va apporter beaucoup de changement.

Je ne bois pas d'alcool, désolé.

Avant le make, il faut générer les fichiers de langue:

lrelease rolisteam.pro

ou

lrelease traduction/rolisteam_*.ts


J'avais plus en tête le support de MAC OS X (compilation, installation, packaging); pas le support d'Aqua ( l'interface utilisateur de MAC OS X ).

Je pense que peu de développeurs Qt travaillent sous MAC. C'est là la source des problèmes.

Le support de Mac OS X est plutôt bien fait par Qt. Le travail avec clang et Xcode ça passe. C'est moins naturel que sous linux mais cela marche bien.
Je ne sais pas d'où vient cette idée ?

onintr interupt
git init
interupt:

Bon cela permet de catch les interuption et de relancer le script. Du coup, il suffit d'encadrer le git init avec cela.

C'est pas une mauvaise idée, mais je ne suis pas sur que cela passe niveau politique. Mais bon si mes utilisateurs ne regardent pas l’exécution du script cela restera coincé sur le read, donc je ne sais pas trop. Je verrais mais bon il doit bien y avoir moyen de faire ce que je souhaite.

Il y a une erreur dans mon copier/coller xterm lance "/chemin/vers/index.csh; csh -i"

Les deux commandes sont successives.

Pas vraiment, je n'ai pas envie d'expliquer le problème en détails mais en gros, le code exécuté après le git init est assez critique donc un utilisateur qui lance le script va attendre de voir le git init finir pour savoir si le reste du traitement va fonctionner. Si le git init met trois plombe, la personne ne sait pas si la suite est bien partie. Si elle revient le matin et que cela n'a pas marcher à cause d'une erreur de syntaxe, elle n'aura pas eu le temps de voir et de corriger le problème (une nuit perdue). Passer le git init permet de gagner du temps.

Donc, non je ne peux pas dire aux utilisateurs: votre confort d'utilisation, je m'assoie dessus.

Expliquez-lui de quoi vous avez besoin, et Mali vous dira comment vous en passez. :-P

Ce n'est pas franchement nouveau, la transmission de donnée par des ultrasons. En 1956, Robert Adler a crée une télécommande (pour téléviseur) qui utilisait les ultra sons : [[http://en.wikipedia.org/wiki/Remote_control]]

Il n'y avait pas qu'un problème mais les animaux de compagnies entendaient son système.

Comment que je suis trop content de recycler mon exposer d'anglais sur les télécommandes (il y a 7 ans).

l'ajoute de ceci "csh -i" à la fin de la commande devrait laisser le terminal sur un mode d'attente. De plus, ce qu'il y a après le git init est relativement long (peut aller jusqu'à une nuit de calcul).

Il existe des wrappers (ils simplifient juste l'api) pour utiliser la lib VLC dans des applications Qt. Je sais pas si cela peut t'aider: http://projects.tano.si/en/library/download

non mais c'était une boutade………

l'imprimante du boulot.

sixième ou septième sens, peu importe. L'important, c'est le septième cosmos.

Petit tutorial homemade : http://renaudguezennec.homelinux.org/programmation,3-15.html

L'abréviation de monsieur en français est M; pas Mr qui est Mister en anglais.

Je suis passé à bépo, il y a environ un an. J'aime bien la disposition même si je trouve les claviers typematrix très mal foutu. La touche entrée et la touche back space sont vraiment déroutante au début. J'ai dans les premiers temps fait des exercices de saisie pour m'entrainer.

J'ai récupéré une bonne partie de ma vitesse de frappe mais je n'en suis pas au même niveau. Autre fait troublant, utilisation d'un bépo sur une longue période de saisie (genre: écrire un article/tutorial) provoque des douleurs aux avant-bras. Rien de bien méchant, c'est quand même gênant un petit peu, je dois m'arrêter un peu.

J'ai suivi les conseils de positionnement des mains.
Cependant, la frappe reste agréable, je pense migrer mon poste de travail sur bépo, aussi.

Il faut bien comprendre comment marche notre projet. Il y a deux branches d'évolutions: la 1.0.0 et la v2.0.0. La première découle directement du code de rolistik avec juste les petites modifications, c'est actuellement la branches principales. La 1.5.1 est issue de cette branche.

La v2.0.0 est une refonte totale du soft avec une bonne conception objet etc.. Seul problème, j'ai cassé beaucoup de chose et la v2 n'a pas tout le fonctionnel de la V1 (en faite, toute la partie réseau est désactivée). Personnellement, je ne bosse pratiquement que sur la v2. Je ne fais que de la résolution de bugs sur la branche 1.0.0. Cependant si des personnes proposes et codes des améliorations, elles sont intégrées. Comme il faut de temps en temps sortir une version.

Pourquoi rolisteam et pas MapTool. C'est historique, un mec a demandé un portage de rolistik sur linux dans un forum. Je l'ai fait puis voilà, j'avais pas envie que cela disparaisse. Puis je suis un développeur Qt (certifié et tout le bazard) et que java, je n'ai pas envie. Même si c'est un très bon choix pour ce type d'application. C'est une occasion de maintenir mes compétences Qt. Puis personnellement la dernier fois que j'ai testé mapTool, j'avais rien compris au truc. C'était loin d'être simple comme truc, du moins dans mon souvenir. Puis la diversité, c'est bien aussi.

Il est vrai qu'un gros bug est présent dans la version 1.5.0, je l'ai corrigé et sortie une version 1.5.1. Cependant, les problèmes que tu soulignes sont principalement liés à l'héritage de rolistik. Dont la conception est très chaotique. Nous avons de grand projet d'évolution pour le rendre plus friendly user etc... mais pour cela il faut des gens intéressés. Faire des sorties permet de maintenir le projet en vie.

J'en parle, il me semble, dans les commentaires d'un précédent journal. Pour faire court, le seul moyen de contacter les développeurs de rolistik, c'est l'adresse courriel de son auteur. J'ai envoyé quelques courriels mais aucune réponse en retour. Aucun forum, aucun outil de version (git,svn ..), pas de mailing liste, difficile dans ce cas de travailler sur le projet. J'ai d'abord créé un googlecode pour suivre le développement: svn et tracker de bug. Je n'avais pas eu l'accord de l'auteur de reprendre le nom et je ne voulais pas faire d'amalgame alors j'ai forké. C'est plus, la somme de petite raison.
Depuis, j'ai crée un site web (drupal), avec un forum et un wiki. J'essaie ainsi de créer une communauté.

Merci bien, je vais suivre cela avec intérêt.