[SOLVED] [LUA] [QUESTION] how send message to the server ...

[noc]

Dernière édition du post.

[schlumpf]

Please prefer posting a new post containing content, rather than editing a post and adding a new post telling you updated the old one. It is harder to understand what changed, this way. Especially for people only checking the latest new posts. E.g. I won't go back to the edited post right now, just because of laziness to even search it.

Copying the edited content to the past post is superior to notifying about the update. Just a plain copy will do it already!

[noc]

I'll start by sending a message to the server, it is easier. For that you have to work in and use CharacterSelect.lua example CreateCharacter ("MSGhimodcraftW").
In the server, I'll intercept in ObjectMgr.cpp: CheckPlayerName () testing in the presence of the name "MSG" to start and "W" at the end. If this is the case I code returns a positive but a negative one another the code.
The following happens in CharacterHandler.cpp: HandleCharCreateOpcode () where I will discuss the name as follows:
After CheckPlayerName (), I test MY reponse, if it is positive I send data << uint8 (CHAR_CREATE_SUCCESS), otherwise data << uint8 (CHAR_NAME_TOO_LONG).
Now I have to get the error code in the client CHAR_NAME_TOO_LONG ... it's easy you see.

PS:
Google translate is my friend.

Je vais commencer par envoyer un message au serveur, c'est plus facile. Pour ça il faut travailler dans CharacterSelect.lua et utiliser par example CreateCharacter("MSGmodcraftW").
Dans le serveur, je vais l'intercepter dans ObjectMgr.cpp:CheckPlayerName() en testant dans le nom la présence de "MSG" au début et de "W" à la fin. Si c'est le cas je retourne un code positif sinon un autre code négatif celui-la.
La suite se passe dans CharacterHandler.cpp:HandleCharCreateOpcode() où je vais traiter le nom comme suit :
Après le CheckPlayerName(), je teste MA réponse, si elle est positive j'envoie data << uint8(CHAR_CREATE_SUCCESS); sinon data << uint8(CHAR_NAME_TOO_LONG); .
Maintenant je dois récupérer le code d'erreur CHAR_NAME_TOO_LONG dans le client ... c'est facile vous allez voir.

[noc]

To catch errors or rather the error CHAR_NAME_TOO_LONG must change GlueDialog.lua and more specifically GlueDialog_Show. To make the difference between MY error message and the system, we just consider the fact that it is because of the message it sends MY something will happen before then I send will activate a flag to signal this sends and immediately after I deactivated. This flag is a Boolean variable whose declaration should not be local.
For GlueDialog_Show, check that the flag is active and the Which contains many "INVALID_NAME", if this is the case it is MY mistake. I can not forget a StatusDialogClick () and a little return out of there.
Now it is the turn of GlueDialogTypes ["INVALID_NAME"] because it displays the error message.
In OnShow I check my flag, if it is active then I close by GlueDialog: Hide ();
What is good with GlueDialog is that you can create your own error message ... or others.
Voila, now when the server responds to the creation of a fictional character, I can catch the error code that I set. Despite the limited number of characters, nothing prevents me to send a message to the server.
It only remains for me to send a message to the client, which does not seem to be a more difficult problem than that.

PS:
Google translate is my friend.

Pour pouvoir intercepter les erreurs ou plutot l'erreur CHAR_NAME_TOO_LONG, il faut modifier GlueDialog.lua et plus précisément GlueDialog_Show. Pour pouvoir faire la différence entre MON message d'erreur et celui du système, il faut juste considérer le fait que c'est à cause de l'envoie de MON message qu'il va se passer quelque chose alors avant de l'envoyer je vais activer un drapeau pour signaler cet envoie et immediatement  après je le desactive. Ce drapeau ne sera qu'une variable booléenne dont la déclaration ne devra pas être local.
Pour le GlueDialog_Show, il faut vérifier que le drapeau est actif et que le which contienne bien "INVALID_NAME", si c'est le cas c'est bien MON erreur. Je n'oublie pas un StatusDialogClick(); et un petit return pour sortir de là.
Maintenant c'est au tour de GlueDialogTypes["INVALID_NAME"] car il affiche le message d'erreur.
Dans son OnShow je verifie mon drapeau, s'il est actif alors je ferme par GlueDialog:Hide();
Ce qu'il y a de bien avec le GlueDialog, c'est que l'on peut créer son propre message d'erreur ... ou autres.
Voila, maintenant lorsque le serveur répond à la création d'un personnage fictif, je peux intercepter le code d'erreur que j'ai fixé. Malgré la limitation du nombre de caractères, rien de m'empèche d'envoyer un message au serveur.
Il ne me reste plus qu'à envoyer un message au client, ce qui ne semble pas être un problème plus difficile que ça.

[noc]

I'm lucky for once, the client does not control the length of the name so as to enjoy a little.
As I need to know if it is a message rather than a character I put a header like "MSG_" then my message and send my message I look into CharacterHandler.cpp: HandleCharEnum, this routine sends the list of characters of the player.
Since each call to this routine sends the list of characters that could pose a few problems because if I send my messages to deserts, they will be sent to each call. To remedy this concern I use a flag. If it's negative I send my messages and I active if I send the list of characters. To send a message I need structure character I'll get in Player.cpp: BuildEnumData.  I'll copy routine, paste, change its name and allow the arrival of the message. Once done I'll fill in the variables "by hand" with the data of a character who is in the db and overcharged as to write his name I place my message.
Here is a great thing done. With that my messages have a body and can be send.

PS:
Google translate is my friend.

J'ai de la chance pour une fois, le client ne controle pas la longueur du nom alors autant en profiter un peu.
Comme j'ai besoin de savoir si c'est un message plutot qu'un personnage je mets une entete du genre "MSG_" puis mon message et pour envoyer mon message je regarde dans CharacterHandler.cpp:HandleCharEnum, cette routine permet d'envoyer la liste des personnages du joueur.
Comme chaque appel à cette routine envoie la liste des personnages cela risque de poser quelques petits soucis car si je m'en serts pour envoyer mes messages, ils seront envoyés à chaque appel. Pour remedier à ce soucis j'utilise un drapeau. S'il est négatif j'envoie mes messages et je l'active sinon j'envoie la liste des personnages. Pour envoyer un message j'ai besoin d'une structure de personnage que je vais aller chercher dans Player.cpp:BuildEnumData. Je vais copier la routine, la coller, changer son nom et permettre l'arrivée du message. Une fois fait je vais remplir les variables "à la main" avec les données d'un personnage qui se trouve dans la db et plustot que d'écrire son nom je place mon message.
Voila une bonne chose de faite. Avec ça mes messages ont un corps et peuvent donc être envoyer.

[noc]

Client side in UpdateCharacterList () retrieves I my message with name I test whether my header is present. If this is the case ...
Now the problem is that you delete these fictional characters that serve to bring me messages. To do this, we'll have to do something very complicated : GetCharacterListUpdate ();
After that the server receives the request for the list of characters which will clear the list of fictional characters by replacing it with the real ... if the flag been activated.

The result? well no it's over.

I must admit that this is not an easy but you have everything you need to achieve great things.
Send messages to GMs or warnings unscrupulous players, news, authenticator ...
It's your turn now.


PS:
Google translate is my friend.

Coté client, dans UpdateCharacterList() je recupère mon message avec name que je teste pour savoir si mon entète est présente. Si c'est le cas ...
Maintenant le problème est qu'il faut effacer ces personnages fictifs qui ne me servent qu'à apporter des messages. Pour cela, il va falloir faire un truc très compliqué : GetCharacterListUpdate();
Après ça le serveur recoit la demande de liste de personnages ce qui effacera le liste des personnages fictifs en les remplacant par les vraies ... si le drapeau à bien été activé.

La suite? Bin non c'est fini ...

Je dois bien reconnaitre que cela n'a rien de facile mais vous avez tout ce qu'il faut pour réaliser de grandes choses.
Envoyer des messages aux GMs ou des avertissements aux joueurs indélicats, des news, authentificateur ...
A vous de jouer maintenant.

[noc]

Thank you schlumpf, it's better that way I think.

Merci schlumpf, c'est  bien mieux comme ça il me semble.

[schlumpf]

thank you stoneharry yes i am really new to lua moding and i really d not what i am doing but i trying to learn are there any good website where i can learn how to do lua and xml programming ? for free

Looking at the signature: spambot?!

[Ascathos]

thank you stoneharry yes i am really new to lua moding and i really d not what i am doing but i trying to learn are there any good website where i can learn how to do lua and xml programming ? for free

Looking at the signature: spambot?!

Nope, he's been around for a while. I always think the same though, lmao.

[noc]

whaou ... +7000 views.
Too bad there have no more questions. To celebrate this, the 7000 views eh, this is what significantly improve the code but also the desing.
So to take the concept of customer discution / server and vice versa, I opt for a simple but effective principle. Because the server sends an error code when there is a problem why not do the same thing when it are none? So define in the negative an answer server for expressing that everything is good and another negative response to say that there is a problem, for example too of characters ect. In the client, modify the lua in the routine that has been modified to intercept the error message for it to accept others and manage the new answer as it should. this way, no need to create a fictional character that will avoid a lot of problem in case of accidental disconnections.


whaou ... +7000 vues.
Dommage qu'il n'y ai pas plus de question. Pour feter ça, les +7000 vues hein, voici de quoi ameliorer sensiblement le code mais aussi le concepte.
Donc pour reprendre le principe de la discution client/serveur et inversement, j'ai opter pour un principe simple mais efficace. Puisque le serveur envoi un code d'erreur quand il y a un probleme pourquoi ne pas faire la meme chose quand il n'y en a pas? Donc definissez dans le serveur une reponse negative pour exprimer que tout est bon et une autre reponse negative pour dire qu'il y a un probleme, par exemple trop de caracteres ect. Dans le client, modifiez le lua dans la routine qui a été modifiée pour intercepter le message d'erreur pour qu'il en accepte d'autres et gérez la nouvelle reponse comme il se doit. De cette facon, plus besoin de creer un personnage fictif ce qui evitera pas mal de probleme en cas de deconnection intempestive.