Forum :: EOSERV :: Quest rule for handling "Cancel" button in dialog?

Hello,

I need to be able to reset a quest when the user presses the "Cancel" button in a dialog box (via AddNpcInput).

Is there a rule that I can use to trigger on cancel press?

The current code I have is:

state Begin

{

action AddNpcText(500, "What list would you like to view?");

action AddNpcInput(500, 1, "Top Normal Players");

action AddNpcInput(500, 2, "Top All Players");

action AddNpcInput(500, 3, "Top Administrator Players");

rule InputNpc(1) goto ShowTopPlayersNormal

rule InputNpc(2) goto ShowTopPlayersAll

rule InputNpc(3) goto ShowTopPlayersAdmins

rule TalkedToNpc(500) goto Reset

}

"rule TalkedToNpc(500) goto Reset" works perfect for handling the "Okay" button, but it doesn't handle the "Cancel" button.

I have tried adding "rule Always() goto Reset" to the bottom, because documentation says that it can be used as an "else" statement. But it just triggers right when Begin state loads.

If there's no built in support for capturing the cancel button, is it possible to add the support via server source code? Or is it an event that the client doesn't send to the server?

Thank you!

---
Just your friendly neighborhood Programmer-Man!

https://eoserv.net/forum/topic/20990

Thank you, that post is informative.

I decided to use the "hidden" header attribute. Didn't know it existed until now.

---
Just your friendly neighborhood Programmer-Man!

Hey Shilo what's the hidden header attribute? And what Sausage said about moving is no longer applicable because the most recent EO Hacks includes a hack to move around with quest dialogues open, hehe.

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

Hacker_Alex posted: (4th Mar 2017, 11:42 pm)

Hey Shilo what's the hidden header attribute? And what Sausage said about moving is no longer applicable because the most recent EO Hacks includes a hack to move around with quest dialogues open, hehe.

You can't move outside of the quest NPC's range and still use the dialog box. This will make the dialog invalid.

Apollos right, except it's even more restricted than that.
The moment you open a quest dialog, then move even a single tile afterwards (with the dialog menu walk hack) the npc dialog will stop working untill you go back to the tile you opened the dialog from.

Also, I found the ml pointer that shows if a quest dialog is open or not.
Sausage said the problem, is it is impossible to know whether a quest dialog has been closed or not.
Well this is surely a way that could work by reading the clients memory related to this address. Or is that not viable and considered too hacky?

---
EO Resources/Guides: â—„ eobud.boards.net â–º

@Hacker_Alex

The term I used of "hidden header attribute", is probably not correct. I am just refering to the meta data that's in the header section.

Example:

main

{

questname " " //Newbie Island Board (Board #1)

version 1.0

hidden

}

---
Just your friendly neighborhood Programmer-Man!

shayne posted: (5th Mar 2017, 09:22 am)

Apollos right, except it's even more restricted than that.
The moment you open a quest dialog, then move even a single tile afterwards (with the dialog menu walk hack) the npc dialog will stop working untill you go back to the tile you opened the dialog from.

Also, I found the ml pointer that shows if a quest dialog is open or not.
Sausage said the problem, is it is impossible to know whether a quest dialog has been closed or not.
Well this is surely a way that could work by reading the clients memory related to this address. Or is that not viable and considered too hacky?

DEFINITELY VIABLE ! This is something Sordie can do :P

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

Hacker_Alex posted: (5th Mar 2017, 11:57 pm)

shayne posted: (5th Mar 2017, 09:22 am)

Apollos right, except it's even more restricted than that.
The moment you open a quest dialog, then move even a single tile afterwards (with the dialog menu walk hack) the npc dialog will stop working untill you go back to the tile you opened the dialog from.

Also, I found the ml pointer that shows if a quest dialog is open or not.
Sausage said the problem, is it is impossible to know whether a quest dialog has been closed or not.
Well this is surely a way that could work by reading the clients memory related to this address. Or is that not viable and considered too hacky?

DEFINITELY VIABLE ! This is something Sordie can do :P

Well then I hope this gets implemented soon..

If that's as viable as you say, then a similar fix should be done to finally fix client chat leak... It is a privacy issue after all, since you can easily leak usernames/passwords.
Especially if you don't know minimizing the client from the taskbar causes chat leak, which a lot of people don't.

I would provide the pointers/info if Sausage or Sordie wants. These are two things I really think need to be fixed..

---
EO Resources/Guides: â—„ eobud.boards.net â–º

I've ran into that chat leak quiet a few times. It's definitely a major security issue. A workaround/fix would be great!

---
Just your friendly neighborhood Programmer-Man!

Why can't you fix chat leak yourself? You want the server to ignore chat packets when the client sends the notification that it's chat leaking? Or you want sordie to hook into that notification client-sided and stop chat packets from being sent in the first place.. 

I guess you're saying you don't know how to inject your own custom code like sordie does.

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

shayne posted: (6th Mar 2017, 01:28 am)

Hacker_Alex posted: (5th Mar 2017, 11:57 pm)

shayne posted: (5th Mar 2017, 09:22 am)

Apollos right, except it's even more restricted than that.
The moment you open a quest dialog, then move even a single tile afterwards (with the dialog menu walk hack) the npc dialog will stop working untill you go back to the tile you opened the dialog from.

Also, I found the ml pointer that shows if a quest dialog is open or not.
Sausage said the problem, is it is impossible to know whether a quest dialog has been closed or not.
Well this is surely a way that could work by reading the clients memory related to this address. Or is that not viable and considered too hacky?

DEFINITELY VIABLE ! This is something Sordie can do :P

Well then I hope this gets implemented soon..

If that's as viable as you say, then a similar fix should be done to finally fix client chat leak... It is a privacy issue after all, since you can easily leak usernames/passwords.
Especially if you don't know minimizing the client from the taskbar causes chat leak, which a lot of people don't.

I would provide the pointers/info if Sausage or Sordie wants. These are two things I really think need to be fixed..

I know this is off topic, but I'd really advise people add a check to stop people spitting out their own username or password in-game! Maybe just replace the word with stars, or block the message all together!

callum posted: (6th Mar 2017, 07:13 pm)

shayne posted: (6th Mar 2017, 01:28 am)

Hacker_Alex posted: (5th Mar 2017, 11:57 pm)

shayne posted: (5th Mar 2017, 09:22 am)

Apollos right, except it's even more restricted than that.
The moment you open a quest dialog, then move even a single tile afterwards (with the dialog menu walk hack) the npc dialog will stop working untill you go back to the tile you opened the dialog from.

Also, I found the ml pointer that shows if a quest dialog is open or not.
Sausage said the problem, is it is impossible to know whether a quest dialog has been closed or not.
Well this is surely a way that could work by reading the clients memory related to this address. Or is that not viable and considered too hacky?

DEFINITELY VIABLE ! This is something Sordie can do :P

Well then I hope this gets implemented soon..

If that's as viable as you say, then a similar fix should be done to finally fix client chat leak... It is a privacy issue after all, since you can easily leak usernames/passwords.
Especially if you don't know minimizing the client from the taskbar causes chat leak, which a lot of people don't.

I would provide the pointers/info if Sausage or Sordie wants. These are two things I really think need to be fixed..

I know this is off topic, but I'd really advise people add a check to stop people spitting out their own username or password in-game! Maybe just replace the word with stars, or block the message all together!

Would love that to be solved because I've accidentally leaked my password on my server and it almost ended badly. lol.

Hacker_Alex posted: (6th Mar 2017, 07:02 pm)

Why can't you fix chat leak yourself? You want the server to ignore chat packets when the client sends the notification that it's chat leaking? Or you want sordie to hook into that notification client-sided and stop chat packets from being sent in the first place.. 

I guess you're saying you don't know how to inject your own custom code like sordie does.

I don't see how I could achieve this with client modification alone.

The only some what decent way I can think to do it, would be to read the pointer that holds the 'window state' value server side, and if the value is equal to 1, then that means the client has been minimized by the task bar, and chat leak is active.

Then provoke a hack server side to stop players from being able to chat, or just block chatting..
Then you can reactivate chat once the value of the pointer is 0 (active).

0= Active
1= Minimized by 'task bar' (Chat Leak)
2= Minimized by '-button'

Maybe there is a way to do it with the client alone, but I'm not really sure, and haven't messed around enough yet. =/

Callum Yea, that would be a good idea to.

---
EO Resources/Guides: â—„ eobud.boards.net â–º

shayne posted: (5th Mar 2017, 09:22 am)

Apollos right, except it's even more restricted than that.
The moment you open a quest dialog, then move even a single tile afterwards (with the dialog menu walk hack) the npc dialog will stop working untill you go back to the tile you opened the dialog from.

Also, I found the ml pointer that shows if a quest dialog is open or not.
Sausage said the problem, is it is impossible to know whether a quest dialog has been closed or not.
Well this is surely a way that could work by reading the clients memory related to this address. Or is that not viable and considered too hacky?

It's not possible to know, because the server doesn't send any communications about closing it with the cancel button. If what you say is correct though, and the solution were TO send a packet if cancel was clicked, the server would no longer be considered vanilla.


As for fixing up the keyboard leakage, and since Sordie is assumably good at doing what she's doing at adding in more functionality to the client, you could just check to see if the window is flagged as "focused". Although I'm not quite sure if just minimizing it will flag it as "not focused", but you could also just potentially capture the window messages and force it either way.

---
Wish upon a star!