Victor STINNER a écrit 1639 commentaires

Wormux vient d'être intégré dans Gentoo !!!
http://www.gentoo-portage.com/games-strategy/wormux/bugs(...)

Trop cool.

Haypo

Matte notre page de liens, il existe quelques clones libres de LIERO :
http://www.wormux.org/fr/links.php(...)

@+ Haypo

Euh ... t'as quel fournisseur d'accès ? Le problème est toujours d'actualité ? Je consulte *régulièrement* ce site web depuis plusieurs fournisseurs d'accès (9telecom, free, evc), et je n'ai *jamais* eu de problème ...

Un ami m'a déjà demandé si notre serveur n'était pas HS, pourquoi le même jour, ça marchait nickel depuis chez moi. Il avait Nerim à cette époque ...

@+ Haypo

Ils sont encore tout chaud (ils sortent du four), profitez-en !
http://newrpms.sunsite.dk/apt/redhat/en/i386/fc3/RPMS.newrpms/(...)

Sources :
http://newrpms.sunsite.dk/apt/redhat/en/i386/fc3/SRPMS.newrpms/(...)

Les paquets Debian, Mandrake, Gentoo et autres suivront (je vais voir avec les packagers).

Haypo

Oui, j'y ai pensé, mais je la laisse juste pour me motiver à retenter d'écrire un patch pour faire fonctionner Wormux avec SDL :-) Y'a pas beaucoup de choses à modifier, mais c'est des points assez critiques ...

Haypo

Pour la fenêtre des armes, il faudrait aussi éviter les "doublons" dans les icônes (bazooka, et bazooka automatique ;-) )

Hein ? C'est pas du tout la même arme ! Au contraire, il faudrait changer l'icône du bazooka automatique et puis c'est tout !

C'est comme si on disait que la grenade et la grenade à fragmentation sont la même arme ! Ben merde, y'en a une des deux qui fait plus mal au cul que l'autre !

@+ Haypo

Si tu as installé ClanLib (hé hé, balèze), la compilation de Wormux est très facile.

Plusieurs personnes se sont déjà cassées les dents sur un binaire statique, mais je vais quand même m'y réessayer. La grosse difficulté étant de *ne pas* lier Wormux avec OpenGL sans peine de rendre le jeu spécifique au pilote vidéo du préparateur du binaire.

C'est comme la version Windows, un doux rêve ... :-D (Mickael Prager s'y est essayé, il dit qu'il faut beaucoup de patience, et au moins 1 Go de libre pour la compilation ... Nan, il n'a pas réussi)

@+ Haypo

Faudrait une IA, bon oui je sais, c du boulot.

Sans rire, l'IA et le réseau seront dans la prochaine version. On a déjà un bon gros patch pour rendre leurs écriture plus facile (on a même les bases pour l'envoi de paquet client <-> serveur).

J'ai justement sorti la version 0.5 ce week-end pour pouvoir tout casser avec les gros vilains patchs.

Continue tes critiques Ontologia, les plus pertinantes seront très certainement prises en compte (je trouve aussi que les armes dans le menu des armes sont trop petites).

@+ Haypo

C'est normal, docteur?

Tu es dans le mode "SDL". Au début, j'avais essayé de corriger ClanLib pour faire marcher Wormux en mode SDL, mais je me suis brouillé avec l'équipe, et puis voilà. Donc, Wormux est injouable en mode SDL. Décoche la case en question dans le mode des options (Use SDL / Utilise SDL) et relance Wormux.

@+ Haypo

http://2004.eurobsdcon.org/uploads/media/EBSD04_28.pdf(...)

Je trouve que les nouvelles fonctionnalités ressemblent *beaucoup* à FreeBSD 5.x (kqueue, systrace, ...). A ce que j'en ai compris, ils ont repris du code et l'ont rendu portable sur un max. d'architectures. C'est classe ça ! Ce serait encore mieux si FreeBSD et NetBSD deviennaient un SuperBSD qui serait la combinaison des forces de chacun ... Bon, c'est pas pour demain.

J'suis trop fort, j'ai retrouvé le bench' en question :
http://linuxfr.org/2003/10/19/14323.html(...)

En gros, ça montre en image que Linux 2.6.x et FreeBSD 5.x supportent sans problème une forte monté en charge.

---

Je ne dis pas : "boûh les vilains ! ils repompent FreeBSD !". Au contraire, c'est super que voir que tous les OS libres évoluent dans le bon sens :-)

@+ Haypo

Pourquoi est-ce qu'on fait encore des simulations nucléaires à l'heure actuelle ? Par "simulation nucléaire", mais je comprend : << faire une arme plus grosse que celle du voisin, mais qu'on ne pourra jamais utiliser car elle détruirait 4x la Terre si on la déclanchait >> ...

Moi je dis : Peace & Love :)

Bon, j'ai sûrement mal compris, ça doit être pour faire de la fission nucléraire (non polluante et avec un rendement largement meilleur) ou alors nous pondre des voitures qui ne polluent plus et roulent avec de l'eau ... ah nan, merde, ça c'est les piles à combustibles.

@+, Haypo

- il me faut qqch comme 7 click pour changer le smtp qui me sert a envoyer des mails. C'est une operation que je fais deux fois par jour, je trouve ca super penible

Tiens, j'ai trouvé comme arrêtér de se prendre la tête à changer de SMTP sans arrêt (en journée, serveur de la boîte, le soirée : neuf télécom). J'utilise l'email de ma boîte pour envoyer des emails depuis ma boîte. Dans Evolution chaque compte (POP/IMAP) a son serveur SMTP.

Bon, un script bash qui me changerait ça (serveur SMTP) automatiquement selon par exemple le serveur DNS / mon IP / autre serait la bienvenue. Car le week-end je dois encore passer à evc.net ou lieu de neuf.fr :-P (pfff, trop dur pour moi)

@+ Haypo

Pas de problème, ça peut être étendu.
Il y a deux solutions, soit on augmente la taille de la liste des partitions, soit on diminue la taille de chaque entrée.

Je n'ai rien vu de tel dans les spécifications, ou alors j'ai mal lu. Je pense que le plus raisonnable serait de permettre d'avoir plus d'entrée plutôt que de diminuer leur taille.

Par contre, je suppose que cette limite doit être fixée une fois pour toute, sinon il faut grignoter le début de la première partition primaire, ou bien ? Le plus raisonnable serait de permettre au moins 100 partitions (faut voir large) par défaut : ce qui fait à peu près 4 secteurs par tables à peu près (selon mon calcul de tête). Après, on pourrait en faire plus (ou moins ?) lors de la création des tables. 8 secteurs de nos jours jours ... je ne crois pas vraiment que ça fait beaucoup (sur un disque de 250 Go par exemple).

L'utilisateur de liste chaînée est si gênante ? Ok qu'on peut faire plus de connerie avec ça, mais c'est plus souple ... J'utilise des listes chaînes tous les jours en copiant des fichiers sous ext3, et ça ne m'a jamais planté à la gueule :-)

C'est tellement chiant ces limites. Dernières en tête : sur une architecture 32 bits, on ne peut accéder à plus de 32 bits par processus. Sous Windows, pendant longtemps, on ne pouvait pas faire de fichier de plus de 2 Go (embêtant pour l'enregistrement de vidéo brute non compressée) ... hum, je pense que c'était pareil sous Linux. Ne pas pouvoir faire plus de 4 partitions primaires. J'ai appris ça le jour où j'en tenté d'en créer une 5e (damned !). etc.

@+ Haypo

Hum, moi ce qui me gêne, c'est la limitation de 31 partitions. Ca fait 4 partitions pour 8 distributions différentes (par exemple). Il faudrait pouvoir changer cette limite, voir même prévoir un système illimité.

De plus

Haypo

Etant mainteneur d'un projet (Wormux), il me faut expliquer l'absence de réponse. Il peut y avoir de très nombreuses réponses à cela :
- Le mainteneur est overbooké, a mis ton email de côté puis l'a oublié
- Le mainteneur est fatigué du projet et ne s'en occupe plus vraiment
- L'email s'est perdu dans les méandres de l'Internet (mauvaise adresse ?)
- ...

Le patch peut être génial, mais comme il faut qu'un humain l'applique et que l'humain par défaut est fénéant, il arrive que les patchs se perdent.

Conclusion : insiste ;)

PS: De manière générale, ne jamais commencer par un patch de 10.000 lignes. Il sera rejetté presque à coup sûr. Il faut y aller progressivement. Il ne faut pas négliger le côté humain ;-) (je dis ça en général, et par expérience)

@+ Haypo

N'étant pas utilisateur de KDE, je n'ai pas compris tout de suite la remarque "". La première ligne du site web explique bien cela (je laisse quand même la description complète) :

MPlayer/Xine/ffmpeg/ffserver frontend for KDE.

As a stand-alone application it can:

* play movies from file/url
* play DVD
* play VCD
* play from a pipe
* play from a TV device (experimental)
* keep movie sizes ratio
* movie progress slider
* control arts volume
* resize/fullscreen support
* optional show mplayer output before and after a movie plays
* configurable pattern matching
* position slider
* recording using mencoder
* proxy settings from konqueror are used to set http_proxy environment variable
* DCOP KMediaPlayer interface support

It's also a KPart, making it possible to embed in konqueror (preview in Embedded KDE interface for MPlayer) or KHTML
Additionally:

* Javascript support

Ca m'a l'air bien sympa !

Haypo

Essayez plutôt :
http://www.nsa.gov/ia/industry/gig.cfm?MenuID=10.3.2.2(...)

(pas de commentaire pour l'instant, je suis en train de m'informer ...)

@+ Haypo

Depuis quand l'anglais est "standard" ? Pfffff

En fait, pour comprendre pourquoi on est passé du 100% français à " l'anglais par défaut et plein de traductions derrières ", il faut lire les commentaires qu'on a reçu lors de notre première news sur happypenguin.org (avant début Juillet 2004) :
http://happypenguin.org/show?Wormux#comments(...)

On passe des commentaires du style :

Oh my god... :P Not only is the site in French, so is INSTALL.txt! I have just started to hate French people a little bit more ;) Ps. I'm not english, but I don't mind writing in english on an international medium. Why do French people always think they are better than the rest of the world?

à des choses plus encouragentes :

OUTSTANDING

J'écris ça plus pour expliquer pourquoi on développe tellement d'effort pour ce passage à l'anglais (super lourd). J'ai bien compris que ce "troll" venait du mot "standard".

@+ Haypo

bof, je ne vois pas le probleme a ecrire ses propres Makefile, et je n'ai pas constate de problemes d'interoperabilite particuliers, a part ceux inherent au code (donc rien a voir avec le Makefile) et aux gens etroits d'esprit qui ecrivent pour gmake...

Ben matte le Makefile qu'il y avait avant. Il nécessitait un patch pour chaque distribution (incompatibles entre eux, bref). Je pense donc que les autotools vont nous permettre de mieux s'adapter à chaque système (peut-être un portage BSD, Windows ou Mac ?).

@+ Haypo

ps: c'est la deuxieme fois que tu postes ca, mais les autotools ne sont - toujours - pas un standard.

Là encore, utiliser des outils plus "courant" permet une meilleure interopérabilité plutôt que chacun écrire son Makefile dans son coin, avec ses noms de variables, etc.

Pourquoi ? autotools est si mal vu ? C'est compliqué à utiliser (je trouve), mais exsite-t-il mieux ?

@+ Haypo

et evidemment que l'anglais est plus commun que le francais si les francophones utilisent l'anglais au lieu du français! et pour finir c'est super dommage, parce que ca aurait permis a des francophones de se pencher sur du code dont ils comprennent les noms de variables, pour une fois...

Hum, il y a plus ne non francophones que de francophones qui se sont intéressés au code source. Malheureusement ils sont vite repartis ...

Déjà qu'il n'y a pas beaucoup de développeurs Wormux (deux à peu près), autant mettre toutes les chances de notre côtés.

Vous vous voyez travailler sur un projet en russe, allemand, ou polonais ? ... (non, je ne parle pas courament esperanto)

@+ Haypo

En plus je lui réserve une petite surprise (à ma copine). Elle est fan de "Bob l'Eponge" (oui bon, pas de commentaires :) et j'ai vu qu'on pouvait jouer avec lui en téléchargeant une skin.

Non, le format des skins (et des équpes) a changé entre Wormux 0.4 et 0.5. Je viens de mettre à jour Bob l'éponge :
http://www.wormux.org/fr/skins_non_free.php(...)

Si tu veux je pourrais également mettre à jour Mario Bros, le schtroumph, etc. Suffit de demander !

@+ Haypo

Arf. Disons que la langue anglaise est plus commune, donc plus pratique pour les traducteurs. De toute manière la version esperanto est disponnible : "export LANGUAGE=eo" avant le lancement du jeu. Tu peux te baser sur po/eo.mo pour traduire le jeu dans une nouvelle langue.

Par contre, là où Wormux (ClanLib en fait) sucks : ça ne gêre pas l'UTF-8 ni les polices TTF. C'est très gênant pour la localisation ...

@+ Haypo

C'était parce que j'avais mis mon premier journal (beta2) en privé alors que je le voulais en publique. J'ai écrit un email aux modérateurs LinuxFR.org : aucune réponse ... C'est pour ça que je me suis permis de remettre le même texte.

En fait, ce qui change avec la beta3 :
- Corrections de bugs au niveau du moteur physique
- La compilation du sous-répetoire po/ fonctionne correctement (il manquait un fichier et une ligne dans Makefile.am)
- J'ai décidé de ne plus couper le projet en deux parties (source + donnée)

J'ai surtout fait cette release pour les préparateurs de paquet, car faire un paquet d'un programme qui ne compile pas c'est balèze :-)

@+ Haypo

A partir de la version 4.3 (ou avant ?) Xfree86 utilise l'EDID de l'écran :o)

@+ Haypo