Salut McBlyver,
ne connaissant pas trop le BGE, je me suis abstenu, mais ton projet est intéressant.

J'ai regardé comment je m'y prendrais et j'ai peut-être trouvé un début de piste :
On peut apparemment déplacer les objets en jouant sur leurs paramètres de dynamique, au moins pour se déplacer d'avant en arrière et de haut en bas.

Avec un objet en dynamique, tu ajoutes une matière pour gérer la friction (pour l'accélération/décélération), et la logic brick "servo control".
Dans mon test si j'appuis et je maintiens la barre d'espace, l'objet se met alors à accélérer et à prendre une vitesse constante. Dès que je relâche la barre, il ralentit et s'arrête.

Ensuite, pour déterminer le meilleur chemin d'un point A à un point B avec des obstacles, Blender a un algorithme qui fait déjà ça, mais je ne sais plus où ni comment il s'appelle

Citation :
Si tu parles de Raycast & Detour, c'est une branche je crois.

je confirme que c'est une branche
en plus je crois qu'a l'heure actuelle seul des compil pour windows existe


mais elle est prête a être intégrer au trunk donc cela devrait arriver

Non je ne pensais pas à cette branche.

Mais plutôt à la fonction 'select_vertex_path' avec une grille de sommet dans les zones où l'engin peut se déplacer.

Sinon il y a des implémentations de A star (A*)

Où l'utilisation du sensor radar :
http://blenderunderground.com/forums/viewtopic.php?f=12&t=4239

Sur le net il y a pas mal de petit jeu qui font ça déjà très bien mais Raycast/Detour a l'air d'être la solution la plus efficace.

Salut LA-crobate, pour ce qui est de faire bouger un objet avec les propriétés dynamiques et les touches du clavier,
oui j'ai effectivement essayé ça aussi, et c'est joli tout plein, mais dans mon cas, absolument inutile.

Je répète et précise ce que j'ai dit au début :
- un script devra lire les coordonnées d'arrivée de la fourche dans un fichier texte
- il devra ensuite faire bouger la fourche avec une phase d'accélération, une vitesse maxi, et une phase de freinage
- il n'a aura pas d'obstacle à éviter, il ne s'agit pas d'un jeu
- l'éventuelle détection d'obstacle pourrait en revanche servir à simuler le capteur qui détecte la présence
d'une caisse (ou cube) sur l'emplacement d'arrivée et ensuite qui confirme la présence de la caisse sur la fourche
- les commandes au clavier, ou à la souris devront permettre par exemple de changer les paramètres de vitesse ou accélération,
ou encore d'introduire ou de sortir des caisse du système, mais en aucun cas de faire bouger la fourche
(éventuellement de replacer manuellement une caisse qui serait en travers et qui bloquerait l'installation)

Bobibou : j'avais cru comprendre dans le message de Speedlight que justement pour permettre une mise à jour de l'affichage
pendant que le script tourne, il fallait insérer un petit temps d'attente 'time.sleep' (mais je n'ai pas encore essayé)

Je me remettrai à l'ouvrage sur ce projet à la fin de la semaine prochaine si tout va bien.
Merci pour votre soutien et votre enthousiasme.

time.sleep() permet de faire une pause. Ça aura donc pour seul effet de retarder encore plus les choses.
En fait, on met un sleep dans la boucle principale d'un jeu lorsqu'on le programme entièrement, en Python (ou autre langage) pur. Donc dans l'idée, c'était juste, ça sert à conserver un framerate régulier.
Mais là, on ne crée qu'on petit bout de la boucle principale, le BGE s'occupant de gérer tout ce qu'il faut derrière.
Donc on doit vraiment faire un script qui soit court et prévu pour être exécuté 60 fois par seconde.

As-tu un cahier des charges précis pour la syntaxe du fichier de positions ?
Tu dis qu'il n'y aura pas d'obstacles à éviter. Est-ce que ça veut dire que la fourche ira tout droit entre les deux position ? Si oui, ça ne sera pas bien dur et aucun algorithme de pathfinding ne sera requis.

Ponzouâhr !
Après quelques jours (semaines) d'absence et donc de mise en pause de ce projet, je me vlà qu'est de r'tour.

Bon, j'ai bien tout lu en détails tous vos conseils, mais j'ai quand-même pas les idées beaucoup plus claires.
Vous allez me prendre pour un demeuré, m’en fou, c’est gratuit

1) Je ne vois toujours pas comment faire concrètement pour mettre à jour la position de mon cube à chaque itération.
Avec une variable globale, je veux bien, mais si l'objet ne change pas de position aussi souvent que la variable change
de valeur, ça laisse le problème entier (en tout cas pour ce que j'y comprends).

2) Puisque ça paraît si compliqué de déplacer un objet de manière fluide en calculant sa position dans une boucle,
alors pourquoi ne pas essayé avec la méthode des F-Curves ? Si j’arrive à définir une F-Curve dont la première Key
est la position de départ, la seconde Key est la position d’arrivée, je peux ensuite sortir du script pour exécuter la F-Curve, non ?

3) Bobibou : oui j’ai (en quelque sorte) un cahier des charges précis et rigide.
En fait cet entrepôt existe et fonctionne. Le fichier texte contenant les positions et les ordres est bien "réel".
Je ne sais pas encore exactement tout ce qu’il contient, mais c’est du code, avec de la doc, et j’ai les collègues qui connaissent.
Mais en quoi est-ce important pour le problème qui me bloque ? Je fais des essais avec un fichier et des positions 100% factices.

4) Il n’y a pas et n’aura pas d’obstacles à éviter. Ce n’est pas un parcours miné.
La fourche (sorte de bras ou grue robotisé) se déplace à l’horizontale sur un rail (c’est mon axe X)
Sur ce socle est fixé un espèce d’ascenseur (axe Z) qui peut bouger en même temps de l’axe X.
Ensuite, fixé sur l’ascenseur, on trouve une sorte de tiroir qui permet de prendre et déposer des caisses (cubes pour les essais)
qui sont placés sur des rayons à plusieurs étages de part et d’autre du rail de base.
Cet axe Y ne peut donc bouger que lorsque X et Z sont à l'arrêt complet, et que le tiroir est en face d'un "casier".

Alors quand on en arrive là, oui, il y a obstacle possible, dans le cas d’une erreur de programme, si la fourche doit
déposer une caisse sur un emplacement déjà occupé. Mais la fourche ne peut pas contourner, elle doit simplement renvoyer
un message d’erreur. Idem dans le cas d’un ordre pour prendre une caisse qui ne serait pas présente.
Le message est ensuite reçu par un autre logiciel, qui va chercher un autre casier libre par exemple,
et informer un utilisateur qu'il y a une erreur en cours.

En fait, ce système (le vrai, pas mon imitation) est entièrement automatisé, et par conséquent la base de donnée du logiciel
contient en permanence l’image exacte du stock réel (et inversement bien sûr). Si la fourche ne peut pas exécuter les ordres
qu’elle reçoit, il s’agit d’une erreur système (et donc un programmeur va se faire passer un savon) ou alors d’un problème mécanique
(et donc l’entreprise responsable de la maintenance va devoir intervenir).

Dans l'idéal (d'ici quelques milions d'années), mon bidule pourrait par exemple permettre de tester le programme
qui génère les ordres pour la fourche ou servir de démonstration pour des présentations à des clients.

Bon, je fais quoi moi maintenant (après avoir consacré un moment à remplir mon estomac qui manifeste actuellement
son désaccord avec mes horaires) ?

Je dois vraiment être tarte.
On peut choisir un Actuator de type F-Curve, mais on ne peut pas dire quelle F-Curve on veut utiliser.
On ne peut pas choisir d'Actuator de type Action, alors qu'il me semblait que c'était possible avec la 2.49.
Au point où j'en suis, j'avoue que je ne serais pas contre un fichier d'exemple.
Avis aux experts qui ne savent pas quoi faire cet après-midi

[edit]
Ah si, en fait l'actuator s'appelle "Shape Action" et on peut choisir une action... qui ne fonctionne pas.
Si j'avais eu autant de problèmes quand j'ai commencé avec la 3D, je crois que je serais resté unidéiste.

Et je continue en solitaire...
Mon progrès du jour : faire jouer une action par un script.
Quand ça marche, finalement ça paraît presque simple :

import bge
controller = bge.logic.getCurrentController()
actuator = controller.actuators["Nom_de_l_actuator"]
controller.activate(actuator)

A noter que l'Actuator Action n'est visible que lorsqu'une Armature est sélectionnée.
Il me semblait pourtant qu'à partir de la 2.5x, tout objet pouvait recevoir une Action.

Maintenant il faut que je puisse, dans le script, éditer l'Action, c'est à dire changer la position des Keys.
!!! Attention, il ne s'agit pas de changer les paramètres Start Frame et End Frame de l'Actuator Action !!!
Encore qu'il faudra forcément le faire aussi, mais ça il semblerait que ça soit facile à trouver (pas encore testé).
Il se pourrait même qu'il soit nécessaire de changer la position des poignées de le F-Curve correspondante.

Mais comment diable récupère-t-on ces données dans le script ?
J'ai beau lire et relire les différentes sections de l'API du BGE,
je ne trouve absolument rien du tout. Je cherche forcément le mauvais truc, ou à la mauvaise place.

Si quelqu'un pouvait avoir pitié de moi, svp...

Vu qu'il y a du monde, un petit tour par ici svp...
Si quelqu'un pouvait réussir à me pondre un mini fichier d'exemple avec la méthode de la variable globale à Bobibou,
ou si vous avez des pistes pour choper les paramètres de la F-Curve et de l'Action, je suis preneur.