Autoit Problème MousClick dans un FPS

[Anonymous]

Bonjour a tous Voilà je me permet de faire appel a vos lumières concernant un petit programme en autoit que j'essaie de faire sur un FPS Bat*****eld3 pour ne pas le nommer ^^'

Je sais que autoit n'est pas a utiliser pour ce genre de jeux mais après avoir réalisé quelques bot perso sur D2 j'ai pas pu m’empêcher d'essayer sur Bat.

Voici le problème rencontré: je réalise un simple pixelsearch et souhaites faire un mouseclick dessus (je récupère donc la position du pixel pour ca)

Le résultat: le pixel est bien repéré dans la zone définie mais le mouseclick clique systématiquement a l'opposé de ce point...

Ma première réflexion est que ma souris garde tout le temps une position fixe sur mon écran en jeu donc forcément elle ne peux pas rejoindre ce pixel mais cependant la souris part dans n'importe quelle direction, gauche droite haut bas, sans réel logique. y aurait-il un calcul savant pour déplacer ma souris (en jeu) en prenant en compte la FOV dans mes réglages de jeux et peut-être aussi la sensibilité de ma souris en DPI? ou la fonction est elle bloquée de base par Gameguard et dans ce cas trouver un moyen de passé au dessus ? ou encore y aurait-il une autre fonction a importer pour réaliser cette opération ?

Désolé si j'ai des questions stupides par avance ^^ mais n'ayant pas trouvé de réponse sur le net et ne voulant pas mourir bête

Merci de votre aide!!

 

[Geraff]

Non désolé la comme ça je ne vois rien.

Simule une souris avec un arduino et commande le avec autoit ^^".

 

[Anonymous]

Oki merci Geraff! je sais juste que ce genre de chose est plutôt réalisée en c++ avec des injections de DLL et de hooking mais beaucoup trop poussé pour moi hélas ^^"

Mais si jamais un spécialiste aimbot passe dans le coin je serais ravis d'avoir son opinion

 

[BlueDream]

RedBust fait de l'autoit depuis un moment il devrait pouvoir t'aider.

 

[Kyu]

Quand tu fais un mouseclick, t'a souris va être automatiquement recentré par le jeu, en fonction de la sensibilité configuré dans le jeu, ta camera ne pointera pas exactement là où tu voudrais qu'elle regarde.

 

[Anonymous]

okay ca semble donc impossible a réaliser en autoit alors Merci pour la réponse en tout cas

 

[ToOnS]

Non désolé la comme ça je ne vois rien.

Simule une souris avec un arduino et commande le avec autoit ^^".

carrement l'usinagaz , pas sur que ca marche mieux et encore moins sur que ca soit plus rapide , le temps de transferer (enfin le transfert est rapide mais faut commander tout ca en autoit ...) 4 bytes (2 pour x et 2 pour y) en usb (ou meme plutot par le port serie car l'usb de l'arduino sera pris pour emuler la souris) et que l'arduino traite la commande le mousemove (ou je sais pas quoi en autoit) aura deja bougé la souris avant l'arduino

 

[Anonymous]

enfaite vu comment le jeux réagis au mousemove/mouseclick je penses surtout que les commandes de souris par autoit sont bloquées ^^" c'est pas faute d'avoir cherché

 

[BlueDream]

Elle ne peuvent pas être bloqué a moins que le jeu utilise le logiciel XTrap ou un nom dans le genre.

 

[Sparkdaemon]

Xtrap est une daube intersidérale.

[/rage]

 

[Anonymous]

Ah oki ^^ mais le problème reste que la souris est automatiquement recentrée sur l’écran lorsque je suis InGame, l'utilisation mousemove\click vers une autre position est donc impossible non?

By the way HAPPY NEW YEAR en avance

 

[RedBust]

C'est une question que je trouve très intéressante...
Le fait que le curseur soit fixé au centre de l'écran, et que ce soit l'environnement qui est en mouvement n'est pas gênant en soit puisqu'il est possible cependant de simuler des déplacement "absolus", a partir du moment ou le curseur revient systématiquement au centre de l'écran après chaque action : sera pris en compte uniquement le nombre de pixels parcourus durant le déplacement.
Le problème c'est que dans un FPS on cible des objets en 3D, la distance en pixels du curseur (crosshair) à l'objet ciblé n'est pas forcément égale à la quantité de mouvement en pixels à simuler pour atteindre la cible : puisque celle-ci n'est pas fixe relativement au curseur, elle se déforme en raison de la variation de l'orientation 3D, de plus cela dépend aussi de l'accélération de la souris configurée par le jeu vidéo et par Windows dans certain cas, qui fait varier les angles parcourus en jeu, et aussi tout naturellement de la vitesse de déplacement de la cible en question.
Quelques petits screenshoots pour illustrer le problème, pris sur un jeu tout à fait pourri mais qui a tué l'ennui de nombreuses de mes soirées glandouille...
Je commence par cibler un objet, ici il s'agit d'une lampe suspendue au plafond :

En vert est représenté la distance véritable séparant à cet instant le crosshair de la cible, qui fait 110 pixels ici, et en orange le mouvement de souris suffisant à atteindre la lampe, qui est légèrement plus court.
Pour se déplacer de notre position initiale à celle-ci qui pointe parfaitement sur la lampe :

On s'est déplacés d'un angle de 17° pour pouvoir pointer la lampe.
Il apparaît clairement qu'a cause de l'accélération souris et de l'orientation 3D la distance réelle nécessaire au déplacement du curseur vers la cible et celle mesurée sur l'écran sont très différentes.
Une solution à ce problème peut-être approchée en créant un algorithme vérifiant dynamiquement la position relative de la cible par rapport au curseur et modulant progressivement le mouvement de manière à s'en approcher progressivement.
Cette méthode soulève plusieurs obstacles :

• Les effets d'ombrage et la variation des teintes dues à la 3D rendent difficile le ciblage dynamique des pixels, surtout avec AutoIt
• La simulation des déplacements sous AutoIt exige de connaître la position d'arrivée ce qui implique de partir systématiquement d'une position centrale

Sauf erreur, je pense que c'est la manière dont fonctionnent les aimbots pour FPS...
Ça a l'air sacrément tordu à torcher en tout cas.
Sinon bonne année 2013, je suis en train de me mater le Seigneur des Anneaux un bon jus de fruit en main, le pied quoi.

 

[RedBust]

Petite précision : la taille du champ de vision détecté par ton bot doit être réglée de manière à ce qu'a partir du moment que tu fais entrer une cible dans celui-ci l'aimbot puisse finir le travail sans trop de problèmes, sa taille doit être moyenne, ni trop petite pour éviter les problèmes de ciblage, ni trop grande pour éviter d'avoir plusieurs cibles dans le champ ce qui risque de créer des exceptions difficiles à gérer (surtout en AutoIt).
Tu dois donc régler le FOV de ton bot de manière judicieuse.

 

[Anonymous]

Tout d'abord merci RedBust pour tes lumières
Alors question bête pour commencer! mais comment déplacer la souris de manière absolue?
ensuite j'ai fais quelques test pour afficher la position de ma souris IG lorsque je détectais les pixels cherchés et je me suis rendu compte que la souris n'était pas toujours centré a la même position (surement du a la vitesse de rafraichissement a laquelle la souris est recentrée par le jeux\windows).

Edit: je viens de voir que c'est ce que tu as di dessus déjà ^^' """Et dans ce cas pour "approcher" le pixel visé ne serait-il pas possible de déplacé la souris vers ce point, resserrer la zone de recherche de qques pixel autour du pixel trouver pour approcher la souris a nouveau ? ce ne serais pas fluide ça c'est sur ^^"""

Et sinon si j'ai bien compris le but est de trouver un rapport entre la distance en pixels du crosshair au point visé, le déplacement réel de la souris a effectuer en prenant en compte la distance de l'objet 3d et lacceleration de la souris (windows, IG ou logiciel)

pour la distance en pixel pas de soucis pour l’accélération de la souris on doit pouvoir le definir aussi je penses le problème reste la position de l'objet 3D dans ce cas!

petite question (encore ) est ce que ceci pourrais aider: définir la position du cross hair, définir la position du pixel ciblé, déplacer la souris de 10 pixels a droite et redéfinir la position du pixel et de la peut être trouver une formule pour définir combien de pixel la souris doit réellement réaliser pour arriver du point A au B

Je restes assez novice sur autoit quand même donc désolé s'il y a des questions de simplet dans mon pavé ^^'

Merci et Bonne année 2013!!! (passé dans un bar métaleux faute de mieux ><)

 

[Kyu]

Je pense que ce serais moins compliqué de passer par l'injection dll, que de perdre son temps sur une formule mathématique non tangible.

 

[Anonymous]

je sais bien jones mais l'injection par DLL ne m’intéresse pas hélas... je cherches uniquement une solution via la recherche de pixel (qui n'est pas détectée IG au passage ^^) puis ce me semble être un bonne exercice pour se creuser la tête sur autoit!

 

[RedBust]

L'injection DLL je veux bien, mais c'est quand même beaucoup plus tordu à réaliser à priori.
Même si c'est dur de démarrer en graphique, à la fin ça roule tout seul et c'est juste une question de petits ajustements légers, c'est d'ailleurs sûrement pour ça que la plupart des Aimbots sont basés graphique.
Quand je parle de bouger la souris de manière absolue, je veux dire sans tenir compte de la position de départ et d'arrivée de la souris mais juste par rapport à la quantité de mouvement et à sa direction (puisqu'on revient toujours au centre, il est évident qu'il n'y a que ça qui compte).
Le problème avec l'AutoIt c'est qu'il faut spécifier une position de départ et d'arrivée de la souris, (en définissant une vitesse au mouvement grâce au troisième paramètre du MouseMove si je ne me trompe pas), il faudrait donc trouver le moyen de repositionner "virtuellement" la souris au centre de l'écran.
Le truc c''est que je ne sais pas si les fonctions AutoIt usuelles fonctionnent toujours dans ces cas-là, il faudrait faire quelques tests mais ça m'étonnerait pas mal.

Et dans ce cas pour "approcher" le pixel visé ne serait-il pas possible de déplacé la souris vers ce point, resserrer la zone de recherche de qques pixel autour du pixel trouver pour approcher la souris a nouveau ? ce ne serais pas fluide ça c'est sur ^^

Oui c'est une bonne idée, le problème c'est que la cible est généralement en mouvement dans un FPS, il faut donc trouver le moyen de le faire très rapidement en faisant une série de recherches successives à l'écran en un temps très réduit, et en bougeant successivement la souris vers plusieurs positions intermédiaires, trois ou quatre "resserrages" successifs devraient suffire.
En AutoIt je doute que ça se fasse assez rapidement (surtout au vu de la vitesse de certains jeux-vidéo, on se retrouve au tapis en quelques dixièmes de seconde c'est une vraie catastrophe), il faudrait voir à utiliser d'autres langages, comme le C ou le C++.

 

[Anonymous]

Quand je parle de bouger la souris de manière absolue, je veux dire sans tenir compte de la position de départ et d'arrivée de la souris mais juste par rapport à la quantité de mouvement et à sa direction (puisqu'on revient toujours au centre, il est évident qu'il n'y a que ça qui compte).
Le problème avec l'AutoIt c'est qu'il faut spécifier une position de départ et d'arrivée de la souris, (en définissant une vitesse au mouvement grâce au troisième paramètre du MouseMove si je ne me trompe pas), il faudrait donc trouver le moyen de repositionner "virtuellement" la souris au centre de l'écran.
Le truc c''est que je ne sais pas si les fonctions AutoIt usuelles fonctionnent toujours dans ces cas-là, il faudrait faire quelques tests mais ça m'étonnerait pas mal.

Oui! j'ai cherché pas mal la et j'ai rien trouvé qui permettrai réellement de déplacer la souris d'un nombre de pixel et non pas d'une position physique sur l’écran mise apart le fait de boucler un "$pos=mouseGetPos() ; MouseMove($Pos[0]+1,$Pos[1]+1)"....

Et pour ce qui est d'un scan répété sur un pixel c'est clair qu'en pleine partie ça serais pas viable vue la vitesse du gameplay ^^'

le C++ après je ne connais pas du tout le langage :\ et pour avoir regardé un peu comment se faisait l'injection par DLL j'ai vue qu'il fallait bien plus que quelques notions pour y arriver! rien que de désassembler le jeux pour retrouver les nom de fonction a utiliser dans la DLL c'est un vrai casse tête en chinois!

En tout cas je vais continuer a faire quelques test même si c'est pas utilisable ça reste intéressant
Merci pour votre participation !!!