Il y a actuellement un vilain bug de Dbus avec les disques dur SAMSUNG.

Ce constructeur a donné un nom finissant avec un '/' à un certain nombre de ses modèles, cela provoque un crash de Dbus au tout début de l'installation...

exemple :
ValueError: Invalid object path '/org/freedesktop/Hal/devices/storage_model_SAMSUNG_HD160JJ/': ends with '/' and is not just '/'
install exited abnormally [1/1]

A l'heure actuelle le bug est reconnu mais pas encore fixé, si vous avec une machine avec un disque SAMSUNG vous risque de ne pas pouvoir installer, voire avoir des problèmes apres avoir lancé une MAJ.

[ Répondre ]

Oui, l'accouchement du site s'est un peu faite dans la douleur :P

Notre créateur web n'est pas français et est extrémement occupé ces temps ci, il a donc du mal à mettre en ligne en temps les traductions qu'on lui donne ... en plus de quelques choses de-ci de-là à améliorer.

[ Répondre ]

même chose ici :

"Utilisation des modèles haute définition pour le projet evolva" => "Utilisation des modèles haute définition DU projet evolva"

les modèles viennent du projet Evolva et ils nous ont gentillement autorisé à les utiliser.

http://www.planetannihilation.com/taan/pages/evolva/evolva.h(...)

[ Répondre ]

A l'époque déjà TA utilisait la 3D, mais c'etait par DirectX, pas OpenGL.

Ce que ne permettait pas la carte vidéo en hardware était fait en software par Direct3D, et c'est pour cela que ca se métait à ramer méchament quand il y avait beaucoup d'unités à rendre ou d'explosions ;)

[ Répondre ]

Ah oui bien sûr..

J'ai oublié d'inclure le code réseau pour le multijoueur, le code est en cours d'écriture mais si il y a des experts dans ce genre de problématique leur aide est bienvenue.

[ Répondre ]

Exact, nous recherchons toujours des gens doués en code, le projet étant écrit en C++ et OpenGL.
Nous recherchons également des artistes en 3D (allez les fans de Blender, montrez vous ;) ) pour modéliser des modéles d'arbres, rochers, pics rocheux, bref tout ce qui dans le TA original était un sprite posé sur la carte, non pas un élément 3D comme le sont les unités.

actuellement le gros problème est le 'pathfinding'.
En clair ce qui permet a une unité de trouver son chemin pour se placer là où l'on clique pour lui dire d'aller. Celui-ci est actuellement très perfectible.

Après vient l'IA pour que le camp adverse controlé par l'ordinateur se mette à faire des constructions, des unités et attaque le joueur.

Après il y a tout ce qui n'est pas encore, ou pas parfaitement, implémenté comme les zones de détection radar par exemple.

[ Répondre ]

Oui il faut l'original.
C'est indiqué sur le site, TA3D est une réécriture du moteur, le jeu n'est pas OSS.

[ Répondre ]

A propos, le thème de base de ce film : relancer une activité solaire défaillante ou ayant un comportement dangereux pour les terriens, et que l'on va aller en vaisseau secouer n'est pas neuf.
Voir "Solar Crisis" en 1990.

[ Répondre ]

Oui, c'est cela qui m'énerve d'autant plus , c'était largement annoncé et il a fallu que les éditeurs du soft en question se trouvent le nez dans le mur pour réagir.
C'est moi qui leur ait appri il y quelque chose comme 2 mois quand nous avons passé certains postes en FC6 que cela faisait 2 ans que l'obsolescence était annoncée.

[ Répondre ]

On pourra aussi noter la fin des anciennes libpthreads.

Terminé les programmes développés par des fainéants qui comptaient sur des LD_ASSUME_KERNEL=2.4.18 à gogo et qui donnaient comme excuse quand on leur disait que c'était dépassé (même déconseillé) "Oui mais nous on se base sur la RedHat enterprise" quand on leur disait que leur merdasse refusait de marcher (pour Fedora depuis la FC5).

Oui j'en ai quelques exemples bien énervants.

[ Répondre ]

Et dans combien de temps on voit tout ça finalisé ?

S'il faut attendre d'avoir toujours tout parfaitement fini pour être présenté jamais rien n'évoluera, il suffit de voir les produits de la "concurrence" (pas de polémique) qui font du beta-test avec leurs utilisateurs depuis belle-lurette et donnent ça comme version finale.

De même ne pas réagir maintenant rendra plus dur de faire machine arrière plus tard.

[ Répondre ]

Marrant, il y a à peu près une semaine un américain a reçu un mail du même genre car son blog portait un nom ressemblant à celui d'une entreprise (genre PME, américaine aussi), et le PDG était pas content que dans google ils soient pas en 1ere position.

Le plus tordant était la manière dont le mail était tourné, il mettait en avant que l'entreprise était (par définition) un générateur de profit et que donc internet se devait de mettre en avant ce qui en générait et mettre au second rang des trucs qui rapportent pas un copec comme des Blogs... (gonflé le mec hein ?).

Et que si le monsieur changeait pas le nom de son blog, il était attaqué en justice (une tradition US), ce qui bien sûr ne manque pas de faire rigoler l'interessé.

J'ai perdu le lien, si quelqu'un a suivi cette histoire ...

[ Répondre ]

à moins que toi (ou l'utilitaire de configuration de X de ta distribution) ne l'aies déjà fait, il est souhaitable, sinon indispensable, de définir dans xorg.conf (Section "Monitor") un Mode correspondant à ton moniteur

Oui et non, les modeline doivent (!) disparaitre, la méthode moderne est d'utiliser dpms.
Et oui j'avais entré la résolution à utiliser a ma mano, il s'en fichait royalement et fail-safait en 800*600 (ouch!)

[ Répondre ]

Ce pilote pose certains problemes, en 2D il est clairement plus lent que le driver proprio et n'aime pas un certain nombre de resolutions d'ecran (il a refusé mordicus de configrer la resolution correspondant a mon LCD 20' widescreen)

[ Répondre ]

je suis à 100% d'accord, seulement relis bien ce qui est marqué et dans mon post, et dans les liens que j'ai inclus.
Il est nécéssaire d'avoir une update du kernel AVANT que livna puisse créer ses RPM, il manque l'indispensable fonction print_tainted.

Je l'ai fait premièrement par défi, deuxièmement parceque ne pas avoir de 2D acceptable ni d'extension xv était insupportable, pour la 3D c'etait parce que bon... arrivé là pourquoi ne pas continuer ;)

En plus je fais une chasse au bug éffreinée, j'en suis a 5 bug reports il me semble.

[ Répondre ]

Je n'ai pas résisté, voila donc comment avoir la 3D :)

Je suppose que les étapes précédentes ont déjà été accomplies

1- faire un lien symbolique

ln -s /usr/lib64/xorg/modules/extensions /usr/X11R6/lib64/modules/extensions

2- lancer l'installation du driver propriétaire

3- copier les 2 fichiers dans /usr/X11R6/lib64/ dans /usr/lib64/


à noter qu'il y a aussi des fichier dans un dossier /usr/X11R6/lib/ qui peuvent avoir à subir le même sort que les opérations précédentes, ceux-ci correspondent à la question "voulez vous installer les librairies de version 32bits" dans l'installeur de NVidia.

personnellement je ne l'ai pas fait et cela n'empêche pas glxgears de se lancer, à vous de voir selon vos besoins.

[ Répondre ]

attention, ceci est une methode façon bulldozer pour ouvrir la porte, mais elle permet d'avoir un driver propriétaire NVidia fonctionnel en attendant les mises a jour premièrement du kernel, deuxièmement du pilote NVidia.

Cette méthode telle que jevais la décrire permet d'avoitr l'accèlération 2D, mais je suis sur que des plus fous que moi tenteront de faire marcher la 3D.
Notez que je suis en x86_64.

Le kernel car comme expliqué dans un post sur la mailling-list de developpement, il y a eu un malheureux revert d'un correctif provoquant une impossibilité de compiler le pilote propriétaire (pas que le NVidia en fait !).
voir ici http://lwn.net/Articles/175796/

Le pilote propriétaire NVidia ensuite, normal a cause de GCC-4.1, xorg-7 et des changements dans le kernel depuis la version 2.5.15 (ouf !).

1- creer les repertoires suivants, avec Xorg-7 ils n'existent plus et sont placés dans usr/lib64/xorg/

/usr/X11R6/lib64/
/usr/X11R6/lib64/modules/

2- faire un lien symbolique

ln -s /usr/lib64/xorg/modules/drivers /usr/X11R6/lib64/modules/drivers

3-

installer le kernel de dev kernel-2.6.16-1.2083_FC6 et son devel, ils sont trouvable sur le repository de developpement de fedora
http://download.fedora.redhat.com/pub/fedora/linux/core/deve(...)

4-

rebooter avec le kernel 2.6.16

5-

extraire et patcher le driver NVidia avec 'sh NVIDIA-Linux-x86_64-1.0-8178-pkg2 --extract-only'

6-

patcher avec le patch NVIDIA_kernel-1.0-8178-U012206.diff.txt et compiler le tout
(http://www.nvnews.net/vbulletin/showthread.php?t=62021)

il ne reste plus qu'a modifier xorg.conf et relancer X

[ Répondre ]

je ne sais pas si vous utilisez tous des postes linkes directement sur le net, mais j'ai pu constater de gros problemes à utiliser un proxy, au menu :

-yum ne prend pas le proxy indiqué dans son yum.conf, on est obligé de faire un export http_proxy=http://proxy:8080
-system-config-kickstart est incapable de se lancer quelque soit le user ou les variables d'environnement utilisé (voir plus haut)
-PUP est incapable de recuperer les infos de package (surement lié au 1er bug cité)

pour ne citer que les plus flagrants, j'ai surement d'autres truc qui sont impactés

[ Répondre ]