Bot récolte Retro - Retour d'XP

Inscrit
2 Avril 2026
Messages
2
Hello,

Je bosse sur un bot de récolte pour Retro 1.29 (paysan, extensible aux autres métiers de récolte). Je vibe code (Python + Claude) et j'aimerais vos retours sur mes choix : je suis dans la bonne direction ou je me complique la vie ?

Le parcours

J'ai commencé 100% pixel : capture d'écran, template matching OpenCV, OCR pour les coords, pyautogui pour les clics. Ça marchait pour la récolte de base mais les limites sont vite arrivées : OCR fragile, combat en pixel quasi impossible, pods détectés via le changement de couleur d'un pixel...

Du coup j'ai mis en place un proxy MITM (redirection DNS, le proxy relaie et lit/injecte des packets). Maintenant j'ai en temps réel : coords de map (Gc), pods (Ow), combat complet (GJK, GTS, GTM, GA...), et injection pour les actions combat.

La récolte reste en pixel (template matching + clic) parce que ça marche (plutôt) bien.

Navigation

Graphe orienté auto-apprenant : quand le bot change de map (packets GDM/Gc), il enregistre la transition. Ensuite A* pour naviguer partout. Difficulté : chaque map a ses propres positions de clic de sortie.
J'ai des overrides manuels pour les cas spécifiques (portes, escaliers) et des clics par défaut par direction.

Combat (Cra)

Grille de combat (560 cells, 14×40) reconstruite depuis le réseau. Évaluation de toutes les combinaisons (position × sort × cible) chaque tour. Problème principal : les protecteurs bougent beaucoup et les données de walkability des SWF ne matchent pas toujours le serveur.

Mes questions

1. Proxy MITM pour le combat : bonne direction ?
2. Walkability des maps : j'extrais des SWF mais c'est pas toujours fiable. Il y a mieux à faire ?
3. Graphe auto-apprenant vs chemins hardcodés : bonne solution ou il y a encore mieux ?
4. Un truc bancal/bizarre dans l'approche ?

Pas besoin de code, juste valider la direction. Merci d'avance !
 
Je comprendrai jamais les bot pixel, ça doit être ultra gourmand et pas assez fiable. C'est pas ça faire du reverse, puis ça n'aide vraiment pas à comprendre ce qu'il y a sous le capot.

Si tu veux vraiment faire quelque chose de propre, et fiable, faut passer par la notion de reverse :
- Comprendre les paquets, envoi/reception
- Ou bien s'initier à de l'internal avec la notion de hook(je connais mal l'AS dont pas sur non plus que c'est la meilleure piste, mais je vois pas pourquoi ce ne serait pas envisageable)
 
Thomas#0116 a dit:
Je comprendrai jamais les bot pixel, ça doit être ultra gourmand et pas assez fiable. C'est pas ça faire du reverse, puis ça n'aide vraiment pas à comprendre ce qu'il y a sous le capot.

Si tu veux vraiment faire quelque chose de propre, et fiable, faut passer par la notion de reverse :
- Comprendre les paquets, envoi/reception
- Ou bien s'initier à de l'internal avec la notion de hook(je connais mal l'AS dont pas sur non plus que c'est la meilleure piste, mais je vois pas pourquoi ce ne serait pas envisageable)
Je pense que les gens qui font du pixel c'est en général des personnes non tech, qui ont pour seul but d'automatiser des tâches simples à leur portée pendant qu'ils sont absents / font autre chose ou d'automatiser quelque chose qui est ennuyeux à faire manuellement. C'est aussi un des points de départ le plus logique pour commencer, et après aller plus loin (pour des personnes non tech)
 
Thomas#0116 a dit:
Je comprendrai jamais les bot pixel, ça doit être ultra gourmand et pas assez fiable. C'est pas ça faire du reverse, puis ça n'aide vraiment pas à comprendre ce qu'il y a sous le capot.

Si tu veux vraiment faire quelque chose de propre, et fiable, faut passer par la notion de reverse :
- Comprendre les paquets, envoi/reception
- Ou bien s'initier à de l'internal avec la notion de hook(je connais mal l'AS dont pas sur non plus que c'est la meilleure piste, mais je vois pas pourquoi ce ne serait pas envisageable)
Ça me semblait être le plus facile à mettre en place rapidement + le moins détectable.
Au final je n'ai plus que la récolte qui passe pixel.

Comme dit Killersarea pour l'instant le but est juste d'avoir un bot qui va farm métier quand je ne jouerai pas afin d'avoir un peu d'income passif. Après si j'y prends goût peut être que j'irai chercher plus loin pour le fun/challenge.
 
Personnellement j’ai des bots récoltes qui fonctionnent pas mal, entièrement en mitm.

S’agissant de l’idée d’avoir un graphe auto apprenant, je trouve que c’est too much vu qu’en réalité, les maps changent jamais. Perso j’ai trouvé un compromis qui me semble bien avec des fichiers de parcours des maps qui reposent sur des json. Ça permets de les modifier facilement sans toucher au code. Et j’ai aussi prévu un truc assez simple pour les générer (en gros je parcours les Maps que je veux visiter et il enregistre mon parcours).

Sur le combat, pareil pour de pauvres protecteurs ça me paraît too much en combinatoire. Suffit de garder un sort et une logique simple (type : je choisis un seul sort et à chaque tour j’essai de trouver une cell dans un rayon de X case qui possède une ligne de vue vers le protecteur et qui se trouve à la bonne portée. S’il y en a pas j’avance le plus possible vers la cible. X étant mon nombre de PM)
 
Thomas#0116 a dit:
Je comprendrai jamais les bot pixel, ça doit être ultra gourmand et pas assez fiable. C'est pas ça faire du reverse, puis ça n'aide vraiment pas à comprendre ce qu'il y a sous le capot.

Si tu veux vraiment faire quelque chose de propre, et fiable, faut passer par la notion de reverse :
- Comprendre les paquets, envoi/reception
- Ou bien s'initier à de l'internal avec la notion de hook(je connais mal l'AS dont pas sur non plus que c'est la meilleure piste, mais je vois pas pourquoi ce ne serait pas envisageable)
La facilité, au final avec les nouvelles mesures anti-bot de retro, ca te demande quand meme un certain seuil de connaisances et de savoir fouiller
 
en fait un bot pixel avec un sniffeur ca marche très bien et est plus difficile à détecter
ca devient très technique quand tu veux envoyer les events de click virtuel sans focus sur la fenêtre du jeu (il y'a des sortes de drivers virtuel de souris et des hooks dans les dll d'api windows pour faire ca ...)
Tu penses que la réponse est plutôt de spin des vms et là tu te faire butté par l'api sécurity de l'électron backend, mais tu peux tenter toujours de spoof les ids de ta machine en hookant child process avec frida par example
bonne chance
 
Dernière édition:
Retour
Haut Bas