Alors, je vais essayé de répondre dans l'ordre :
@Alesk : La fonction AddForce n'a rien à voir là dedans
@NDrew : Je vais passer au dessus du "naïf" en te rappelant au passage qu'il y a l'opposé : ceux qui ont tellement de connaissance dans leur domaine qu'il ne se rende plus compte que ce domaine comporte des failles. Une sorte de naïveté, si voit ça avec un peu de recul...
Les contraintes, si je comprend bien, c'est du scripting, pas quelque chose de gérable via l'interface de Unity. C'est bien ça? Si c'est le cas, cela pourrait - a priori - régler mon problème. D'ailleurs c'est ce que je disais 6 posts plus haut (cf. "private ToiTuBougesPasQuoiquilarrive").
Mais du coup faire du scripting là ou il suffirait d'une simple à cocher sur l'interface? Ou l’antithèse de l'ergonomie et de l'intuitivité.
@LudlowFx Pas faux, l'option "static" a plusieurs utilités. Mais avouons... Quand même... Si on coche cette case, pourquoi l'objet est-il toujours dépendant de la physique, puisqu'il n'est pas sensé bouger? Au lieu de ça, faut faire un script... dommage non?
@manthoR Merci pour la tentative d'explication, sincèrement. Hélas je savais déjà tout ça. Pour répondre à ta première question, je ne peux pas mettre de rigidbody sur le paddle car la balle le pousserait vers le bas lors de la collision.
Je tiens quand même à émettre une hypothèse : sachant que la balle ne pousse pas mon mur lors de la collision, bien qu'elle ait un rigidbody, j'en déduit que mon paddle avec rigidbody le pousse parce que c'est moi qui le fait bouger. Peut-être me fourvoie-je, mais je pense que c'est parce que lors de la collision, mon paddle applique une force continue sur le mur, alors que la balle change de direction grâce à la physique. Je pense que je vais repartir à zéro en suivant le tuto donné par giyomuSan et quand je serai un peu plus à l'aise avec le scripting, je trouverai un moyen de forcer un objet à rester sur sa position, quelque soit l'évolution événementielle.
