C# [C#] - Gestion des maps et déplacements

  • Auteur de la discussion Anonymous
  • Date de début
A

Anonymous

Invité
#21
#21
Re: [C#] - Gestion des maps

Ah ok, mais ça parait logique ça.
Tu peux pas te déplacer "dans le vide", sur des cases inexistantes.
Il suffit de vérifier que les cases que tu check sont bien dans la map mais ça je le fais déjà.
Pour les changements de map, je ne me suis pas renseigné encore mais j'imagine qu'il faut se mettre sur un des bords et envoyer un packet spécial avec l'id de la map.
Je vais déjà essayer d'avoir un déplacement fonctionnel ce soir, je verrais après pour les changements de map.
 
4

4R7Y

Contributeur
#22
Inscrit
6 Mars 2011
Messages
213
Reactions
0
#22
Re: [C#] - Gestion des maps

Oui les changements de map sont très facile à réaliser.
L'autre difficulté du déplacement est de savoir quand envoyer le packet de fin de déplacement (oui car il y a un packet de fin de déplacement)
 
A

Anonymous

Invité
#23
#23
Re: [C#] - Gestion des maps

Ça existe encore sur 2.0 ça ?
Je sais qu'il y a un deuxième paquet à envoyer mais pour le moment je l'envoi direct après...
Je croyais que c'était juste pour "confirmer le déplacement" et pas "dire que je suis arrivé à destination".
 
4

4R7Y

Contributeur
#24
Inscrit
6 Mars 2011
Messages
213
Reactions
0
#24
Re: [C#] - Gestion des maps

Oui ! C'est souvent l'erreur au départ, et des bans tombent à force (de 2h, pas ceux administré par les modos)
Donc pour les déplacements de 4 cases, ça va, mais pour ceux d'un bout à l'autre de la map : Non.

*En attente de la remarque de ToOnS sur le MITM concernant ce fameux paquet à envoyer* x(
 
A

Anonymous

Invité
#25
#25
Re: [C#] - Gestion des maps

Hum...
Il faudrait trouver un ratio de temps que l'on pourrait multiplier par le nombre de cellules parcourues puis lancer un timeout.
Le plus compliqué doit être de trouver ce ratio étant donné que ces déplacements sont relativement rapides (ils n'excèdent généralement pas quelques secondes...).
 
4

4R7Y

Contributeur
#26
Inscrit
6 Mars 2011
Messages
213
Reactions
0
#26
Entre 150 et 200ms pour chaque cellule (c'est ce que j'utilisais pour mon bot) et ça ne posait pas trop de problèmes.
Mais ce n'est pas parfait : il ne faut pas oublier le cas des dragodindes, et sur certaines cellules, les personnages avancent un peu plus vite que sur d'autres.
 
A

Anonymous

Invité
#27
#27
Tant que c'est pas détecté par le serveur, aucun soucis.
D'ailleurs c'est mieux qu'ils avancent plus vite ;)
Et pour les dragodindes, j'utiliserai rarement des bots avec des dragodindes (quoi que ça pourrait être sympa, une armée de 8 crâs sur des dragodindes ! =D)
 
4

4R7Y

Contributeur
#28
Inscrit
6 Mars 2011
Messages
213
Reactions
0
#28
Qu'ils avancent vite ou pas, la fin du déplacement n'est indiqué que par la réception du 952 par le serveur (que le client aura donc préalablement envoyé) et toute action sera donc impossible jusqu'à la fin du déplacement ! c'est pourquoi avoir la formule exacte permet un certain gain de temps (Si tu considères des longs trajets, le temps perdu peut devenir considérable)
 
A

Anonymous

Invité
#29
#29
Du coup faut peut-être pas faire un timeout.
Le mieux c'est peut-être de le mettre en "pause" afin d'éviter qu'il n’envoie d'autres paquets alors qu'il n'est pas censé pouvoir le faire.
Des avis ?
 
4

4R7Y

Contributeur
#30
Inscrit
6 Mars 2011
Messages
213
Reactions
0
#30
Le problème du timeout c'est qu'il empêche de recevoir, et si tu essaies d'envoyer un packet dont tu n'as pas le droit (enfin normalement tu peux tout envoyer) je pense que tu recevra un "BasicNoOperationMessage" et rien de plus, il ne faut pas oublier que par le client, lors d'un déplacement tu peux tenter plein d'opération (je prend un exemple : une demande d'échange lors d'un déplacement)
 
ToOnS

ToOnS

Membre Actif
#31
Inscrit
8 Avril 2009
Messages
974
Reactions
0
#31
Re: [C#] - Gestion des maps

4R7Y a dit:
Oui ! C'est souvent l'erreur au départ, et des bans tombent à force (de 2h, pas ceux administré par les modos)
Donc pour les déplacements de 4 cases, ça va, mais pour ceux d'un bout à l'autre de la map : Non.

*En attente de la remarque de ToOnS sur le MITM concernant ce fameux paquet à envoyer* x(
Cliquez pour agrandir...
en effet cette pause est tres importante (lolo si tu nous lis ... tes nombreux bans venaient de ca).
dans le cas du multi bot il faut pas faire deplacer tout le monde en meme temps.
dans le cas d'un follow meme punition faut attendre un peu (vers 500 ms) avant de suivre le chef

avec un MITM c'est simple il y'a rien a envoyer , c'est le client officiel qui s'en occupe (personne mieux que lui peu savoir quand le deplacement est fini , meme avec dragodinde , deplacement dans la boue ou prise d'anabolisant) , au mieux on peu intercepter le paquet pour que le bot sache que le deplacement est fini et du coup en attendant on bloque pas la reception coté serveur (apres avec un thread de reception si c'est bien pensé ca bloque pas non plus).

dans le pire des cas on peu aussi faire une pause non blocante dans ce genre meme si c'est moins "pro" :
Code: 
'ici c'est pour aller boire un café (enfin si y'a le temps)
    Friend Sub pause(ByVal ms_to_wait As Long)
        Dim endwait As Double = Environment.TickCount + ms_to_wait
        While Environment.TickCount < endwait
            System.Threading.Thread.Sleep(1)
            Application.DoEvents()
        End While
    End Sub
 
A

Anonymous

Invité
#32
#32
Merci !
Mon déplacement fonctionne !
Il zig zag un peu parfois mais c'est pas très gênant...
Je me repencherai sur l'algo plus tard.
Je vais tester avec un sleep et faire un chemin assez long.
[Edit] : Hum en fait je crois que j'ai encore des petits problèmes de déplacement...
Je viens de me manger un ban :x
 
ToOnS

ToOnS

Membre Actif
#33
Inscrit
8 Avril 2009
Messages
974
Reactions
0
#33
xiwiz a dit:
Il zig zag un peu parfois mais c'est pas très gênant...
Cliquez pour agrandir...
comme mon voisin :lol:
 
A

Anonymous

Invité
#34
#34
En fait c'était des problèmes de parité, là ça m'a l'air plutôt good :)
Même sur les trajets longs !
Il fait même parfois des itinéraire qui semblent plus naturel que ceux du jeu.
(J'ai remarqué que en jeu les persos évitent les cases où se trouvent des monstres lors de l'itinéraire)
Je fais un sleep de 100ms par case. Ca a l'air de passer...
Je vais tester jusqu'à me faire ban (si ça arrive).

[Edit] : Ban après plusieurs dizaines de déplacements OK.
Je pense que j'envoie la sauce trop vite (le packet 952).
Et je pense qu'il faut un ratio moins élevé différent si le nombre de cellules parcourue est supérieur à 3 ou 4 (quand le perso se met à courir).
 
A

Anonymous

Invité
#35
#35
Alors, tu envoi le packet de confirm déplacement trop vite je pense.
C'est pas 100ms mais 300ms en courant et 500 en marchant.

If path.movepath.Count <= 2 Then ' Si le nombre de case est inférieur a 2 alors on marche
movewait = path.movepath.Count * 500 ' 500ms fois le nombre de case
Else
movewait = path.movepath.Count * 300 ' 300ms fois le nombre de case
End If
end if
 
A

Anonymous

Invité
#36
#36
Merci je vais tester.
C'est fiable comme valeurs ?
Tu les utilise régulièrement sans problème ?
300 ça me parait long quand même...
 
ToOnS

ToOnS

Membre Actif
#37
Inscrit
8 Avril 2009
Messages
974
Reactions
0
#37
il faudrait pour optimiser le temps sniffer plusieurs fois et plusieurs cas avec wireshark en ajoutant une marge d'erreurs , il affiche l'heure des packets dans la colonne time

sinon vaut mieux trop long (un lag) que trop court (un bot)

pour se deplacer d'une seule case (sans courir) je trouve en moyenne environ 600 ms et 2300 ms pour 10 cases (en courant) , les valeurs de lolo sont assez proches de la realité
 
A

Anonymous

Invité
#38
#38
Moi avec ces valeurs je n'ai jamais eu de probleme.
Parfois 1s d'attente, mais les valeurs exact de chaque case se trouve dans les d2p, variable speed.
Le probleme c'est que chez moi elles sont a zero xD
 
A

Anonymous

Invité
#39
#39
Ah c'est donc cette variable !
Je regarderai.
En utilisant les valeurs de Lolo j'ai environ une seconde de "lag" sur les longs trajets.
 
ToOnS

ToOnS

Membre Actif
#40
Inscrit
8 Avril 2009
Messages
974
Reactions
0
#40
tu peux essayer 240 ms (ou 256 pour etre sur mais pas sous 230) par case ca doit passer (quand tu cours) , sur 20 cases tu gagneras autour d'une seconde (avec encore un leger "lag" en theorie de 200 ms mais ca se ressentira pas) et ca va pas sous les 2300 ms pour 10 cases en gardant une petite marge de 5% d'erreur au cas tu marches dans la boue

pour speed c'est un coefficient multiplicateur (qui est plus important si la case est de la boue , de l'herbe ...) mais j'ai jamais vraiment cherché son rapport exact avec le temps (comme de toute facon dans mon cas y' pas a calculer le temps de deplacement, c'est le client officiel qui calcul pour moi)

pour les longs sleep il faut eviter car c'est blocant , pendant tout le deplacement le programme est comme "gelé" et c'est jamais bon ca , ca donne une impression de plantage qui se traduit par "blablabla ne repond pas" , utilises plutot la fonction "pause" qui est au dessus , grace a application.doevents ca degele le programme , d'ailleur (a tester) il est meme surement possible de supprimer la ligne System.Threading.Thread.Sleep(1) de cette fonction
 
Vous devez vous connecter ou vous inscrire pour répondre ici.
Haut Bas