bin tu fait un truc du genre

for event in bge.event:
print(event)

pour récupérer le numéro de la touche

et une fois que tu a se numéro tu suit l'exemple de la doc
http://www.blender.org/documentation/blender_python_api_2_65_5/bge.events.html

ou tu rempli le dico de bgui (en faisant gaffe je crois que is shifted et gérer mais pas alt gr)

salut,
j'avais justement commencé par faire ça avant d'écrire ma question.

Voici le fichier de test : keyboard_test.blend

Le code est le suivant :


et les touches é, à et encore d'autres sont ignorées.
O-

a peut être qu'un petit rapport de bug s'impose

dès que je rentre chez moi je teste sur mon ordi pour te donner l'int en question

merci de vérifier si ça fonctionne ou pas chez toi.

Sinon, plus j'y réfléchis et plus j'en viens à penser que ce n'est pas un bug, mais un choix des développeurs.
L'utilisation du clavier dans le BGE n'est pas prévue pour écrire des textes mais pour guider un jeu.

Pour écrire des textes, il faut prendre en compte bien plus de choses :
* détecter toutes les touches du clavier (sans doute pas le plus dur) et retourner l'entier qui correspond
* plus compliqué : retrouver le caractère qui correspond et cela risque de dépendre de l'OS et de la langue, voir de la disposition du clavier
* pire encore : pour écrire un texte on peut avoir besoin de caractères autres (par exemple le symbole → que j'obtiens sur mon ordi Kubuntu avec la combinaison AltGr+Shift+N mais qui devra être obtenu autrement sur un autre OS et une autre locale)

Il semble cohérent pour les développeurs du BGE de ne pas prendre tout cela en compte et de s'en tenir aux codes ascii (d'autant qu'en Anglais il n'y a aucun accent).

Sinon je ne suis pas habitué au C mais les sources ont l'air d'être là :
SCA_IInputDevice.h
et j'ai l'impression d'y voir seulement les touches qu'on retrouve dans la doc.

Par ailleurs en fouillant le web je suis tombé sur un message de 2008 qui semble expliquer la non-intégration de tkinter (pour économiser de la place) :
http://lists.blender.org

La seule solution à mon besoin semble être l'appel à un programme externe qui lui prend en charge tout cela, donc une vraie GUI (tkinter, Qt via PySide ou PyQt, Gtk, etc).

Par contre, c'est bizarre que je ne trouve pas d'exemple de gens ayant déjà fait un truc de ce genre.

O-

bin justement si tu regarde ton premier lien tu voit bien qu'elle est traiter "é" c'est la touche 2

tien regarde je t'ai sorti une fonction d'un module de mot de passe que j'ai crée il y a quelques temps

( a la base je l'ai crée pour empêcher certaine touche dans le mot de passe genre f12)

http://www.mediafire.com/?dzwe1einc0e3uoe

mais si tu veut remettre d'autres touches c'est très simple

Ben voilà autre chose :
ton fichier ne me donne rien de mieux et la touche 2 (prise en exemple, mais les autres indiquées aussi) reste muette.

Là j'ai été pris d'un doute : et si je testais avec un autre ordi ? Pas mieux.
Les 2 étants sous GNU/Linux, je teste alors sur un vieux Windows qui me sert à tester mes logiciels sur cet OS.
Et là ça fonctionne ! Ton fichier comme le mien.

Ça ressemble donc fort à un bug Blender.
Je vais tester encore 2 ou 3 trucs (j'utilise KDE mais je veux voir s'il y a le même soucis avec Gnome ou Xfce) pour savoir si c'est tout Linux ou juste KDE qui est concerné et essayer de faire un rapport de bug (vu la qualité de mon anglais ça va les faire rire).

D'autre part, je crois que je vais rester sur ma solution d'appel à un programme externe car la solution que tu proposes demande à retranscrire tout le clavier, et ce pour une seule langue (sans compter que je ne sais pas ce qui peut se passer avec des dispositions différentes genre Bépo).
Or le jeu sur lequel je bosse doit pouvoir fonctionner dans plusieurs langues et être multiplate-forme.
Du coup, passer par une GUI externe qui intègre déjà tout cela très bien me semble le plus simple.

Merci de m'avoir aidé en tous cas.
O-

je me douter bien que c'était un bug

pour le rapport ne t'inquiète pas tu sera pas le premier (moi compris)

sinon je t'ai pas dit d'utiliser ma fonction je l'ai faite pour un cas bien spécifique je te l'ai juste montrer pour que tu voit que normalement toutes les touches fonctionne avec le bge

je te dit juste que quitte a bosser sur la gestion du clavier autant amélioré bgui comme cela toute la communauté en profitera

Bonjour,

J'ai été confronté au même problème (lien)
Maxiem a donné une réponse:
Citation :
J'ai ici un exemple qui le confirme: .blend
Dans cet exemple le code acii des touches entrées est affiché à l'écran. On remarque effectivement qu'il manque bien la déclaration dans les sources de Blender pour les accents et autres caractères spéciaux de Blender. (N.B.: le clavier fonctionne parfaitement en qwerty, mais pas en azerty)
Donc, actuellement dans le bge, Blender ne capte pas toutes vraiment toutes les touches, puisqu'il n'est pas capable de renvoyer une information ascii si on appuie sur des touches (non "déclarées").

En fouillant un peu les sources de Blender, on trouve le fichier de déclaration des touches (et leur code ascii):
blender/source/gameengine/GameLogic/SCA_IInputDevice.h (bien vu Ed_le_H )
(la ligne 138 déclare la touche 'a' (events.AKEY), qui a bien pour code ascii: 97)
Il faudrait déclarer dans ce fichier les autres touches... puis compiler Blender.
(essai de déclaration de la touche 'é' qui a pour code ascii: 233)
J'ai essayé... sans trop de résultats...
Mais je vais continuer de chercher.

P.-S.: Il semble en effet que, pour l'instant, l'utilisation d'un module externe soit nécessaire... Mais bon, avec un peu de recherche, je pense qu'il doit être possible de déclarer le clavier azerty.
En effet, comme l'a dit moaaa: "quitte à bosser sur la gestion du clavier autant améliorer bgui comme cela toute la communauté en profitera".

Bon, j'ai pris le temps de regarder les sources de Blender pour voir l'origine du problème : il est associé des "espèces de caractères" ASCII... Et comme c'est pensé pour qwerty, il y a même des pseudo-codes ASCII (n’existant pas pour les qwerty, et donc peut-être pour nos azerty) pour les inputs de la souris, et tout autres events.

En fouillant un peu les sources, on découvre ceci dans le code :

Ce commentaire donne envie de continuer... (ref: SCA_KeyboardSensor.cpp, ligne 525)


Bon, il est clair que ce n'est pas demain que nos claviers seront reconnus... En attendant, je vous encourage à poster vos "solutions" ici.


P.-S. : j'ai été confronté à un problème, en fait résolu : pour les inputs de la souris il faut faire :

Je devrai améliorer le BGEutils pour ça...

mdr chacun voit midi a sa porte pour moi la solution classique c'est la première