Client popup menu

[Entropy]

This is a feature that we should have had for years, which will make the game much more versatile.

So, here is how it will work:

The server sends the client a command, like:

POPUP_MENU, with some values: menu title, menu description, options, and what to send back for each option (2 octets).

 

The client would then display a window with the title sent by the server, and under the title there will be a description, and a list of options. Sort of like the NPC menu, but this one should be vertical rather than horizontal.

 

This menu can be used for the following things:

1. Send important messages to the client, such as if you are new and you are about to die, the server can tell you to go heal.

2. It can be used for quests, like if you click on an object, you'd get a menu with various options.

3. In can be used to control the summoned creatures.

4. For pets.

5. Many other things.

 

So, who wants to do it?

It should be relatively easy to implement. First, do just the GUI stuff, then we will decide together on the client/server communication format.

[Learner]

On top of that if the client<--> server protocol can also be extended for a Bot to supply this to the server to be sent to a client, and get responses back from another client, the bot should also get get a packet if a player USE's the bot (like you do an NPC). This would allow bots to use this for trade and inventory and add more flexibility as well.

[Usl]

This is a feature that we should have had for years, which will make the game much more versatile.

So, here is how it will work:

The server sends the client a command, like:

POPUP_MENU, with some values: menu title, menu description, options, and what to send back for each option (2 octets).

 

Unfortunately I am not conversant enough in OpenGL to offer to do that myself ... However, by including an icon-id (from some predefined set shipped with the client or pushed later on through auto-update) with the options, and possibly a single octet encoding a "presentation style" (e.g., verbose or compact) the protocol could easily accommodate the ideas expressed in this post about the GUI (especially point 3.), which would make the user interface more uniform.

 

As for allowing bots to put up their own menus, the idea is nice as long as such menus are clearly visually distinguishable from system-issued ones (to avoid all kind of tricks from "evil" bots posing as system menus). A glaring purple (bot names' color) or black/yellow (attention indicator) border would probably suffice.

 

I'll go bankrupt with all these 0.02 €...

[Entropy]

I don't think that bots masquarading as system menus to cheat people will be a concern. You need to pay at least 20 bucks to get a blessed bot, and doing such a thing would be totally against the rules and would get both you and your bot banned, so..

[trollson]

See Also:

• "The Tavern Channel" for discussion on using bots to run games, implemented by subverting local chat messages. Would benefit from bot extensions to the protocol as described.
  
• "Public Library" for a case for additional bot blessings (no protocol extension).
  

Edited February 14, 2008 by trollson

[Grum]

Btw, we already have a serverpopup.c in the client, which apparently is supposed to handle text messages with channel ID 255. Is this used? Can we adapt that to handle the POPUP_MENU?

[bluap]

Btw, we already have a serverpopup.c in the client, which apparently is supposed to handle text messages with channel ID 255. Is this used? Can we adapt that to handle the POPUP_MENU?

That is a possibility. As I did the original serverpopup patch I would have like to look at it but I'm busy on a couple of other things at the moment, may be in a few days.... One minor issues, I did just check the serverpopup code and it now crashes the client it was fine when it was committed last year honest. I'll investigate and submit a bug fix.

[bluap]

One minor issues, I did just check the serverpopup code and it now crashes the client it was fine when it was committed last year honest. I'll investigate and submit a bug fix.

Looks like someone did some overzealous editing and removed a couple of lines. Please could you restore them grum

Index: serverpopup.c
===================================================================
RCS file: /cvsroot/elc/elc/serverpopup.c,v
retrieving revision 1.6
diff -a -u -r1.6 serverpopup.c
--- serverpopup.c	   19 Sep 2007 17:38:29 -0000	  1.6
+++ serverpopup.c	   19 Sep 2007 17:45:32 -0000
@@ -342,6 +342,8 @@
	/* make a copy of the message body so we can modify it and so the caller can free the memory
			 make the copy bigger than we need so it can be text rewrapped */
	message_body_size = 2*strlen(message);
+	   message_body = (char *)calloc(message_body_size, sizeof(Uint8));
+	   safe_strncpy(message_body, &message[body_index], message_body_size * sizeof(Uint8));

	/* initialise the window text widget text buffer */
	init_text_message (&widget_text, message_body_size);

[Grum]

Oops, yes, my bad

 

It's back in. I hope you don't mind that I removed the sizeof's. First, since you copied char and to a char*, they should've been sieof(char). And by definition, sizeof(char)==1 (yes even when a char is larger than a byte).

[bluap]

Oops, yes, my bad It's back in.

Thanks.

I hope you don't mind that I removed the sizeof's. First, since you copied char and to a char*, they should've been sieof(char). And by definition, sizeof(char)==1 (yes even when a char is larger than a byte).

hehe, my paranoia of sizeof stems from years writing C code for TMS320C processors. That did weird things with sizeof(char) being the same as sizeof(int) though it was so long ago I no longer remember what value that was

[Entropy]

Well, those two things can work together, for example if we don't want to send a whole menu, but just a pop-up text, we can use the channel 255 trick.

If we want to send a menu, we use the menu thing.

But it would be nice if they are consistent in their interface, so the users won't be confused.

 

BTW, is the channel 255 thing currently in the official client?

[bluap]

BTW, is the channel 255 thing currently in the official client?

Yes it is.

[alvieboy]

This menu can be used for the following things:

1. Send important messages to the client, such as if you are new and you are about to die, the server can tell you to go heal.

2. It can be used for quests, like if you click on an object, you'd get a menu with various options.

3. In can be used to control the summoned creatures.

4. For pets.

5. Many other things.

 

So, if I understand correctly, you want a menu with two kinds of behaviour:

 

- Present the user with some options and closes after the user chooses;

- Present the user with some options and does not closes after the user chooses - useful for 3,4 and 5;

 

About the options, you're thinking about clickable stuff only (text and/or icons) or leave room for combo boxes, drop down entries and text entries, or other kinds of stuff ?

 

The description of the menus can be XML, or do you prefer a binary interface for it?

 

Álvaro

[Entropy]

Hmm, I guess maybe the server will tell the client if the menu should be closed or not when the player choses an option.

And there will be no XML, just binary data, to save up bandwidth.

[alvieboy]

Hmm, I guess maybe the server will tell the client if the menu should be closed or not when the player choses an option.

And there will be no XML, just binary data, to save up bandwidth.

 

Ok.

 

Just another question - should it be possible to have multiple popups opened? I'll start presuming that yes, we can have multiple popups. On this scenario, each popup should have a unique ID, so that replies associate with it.

 

Álvaro

[Entropy]

I am not sure of that yet, but each option WILL have an unique identifier sent by the server anyway.

I guess it wouldn't hurt to have multiple menus at a time, although if this is the case, we need to take care for them not to cover eachother.

 

As for your previous question about other kinds of menus, such as radio, drop down, text field, sure, I think it would be a good idea.

[alvieboy]

Hey,

 

I've done some basic stuff. This is a screenshot of the current implementation, with only text options.

 

The mouse is over the second choice.

 

You can see a screenshot here: ScreenShot

 

Sorry I cannot link directly to the image there.

 

The code is very simple and easy to use:

const char *ptext = "The administrators want you to answer the following question. "
	"If you fail to answer, you will lose all gc you have in storage and in yourself.\n"
			"\nWho rules this game?\n";

popup = popup_create("Administrators poll");

if (popup) {
	popup_set_text( popup, ptext, strlen(ptext) );
	popup_add_option( popup, "A guy named Entropy\n");
	popup_add_option( popup, "The fabulous Entropy! He's the uber geek around the whole globe, universe, and some places in C2\n");
	popup_add_option( popup, "Entropy is the name\n");

 

 

Any ideas after seeing this?

 

This is not the final implementation, it still needs a lot of work.

 

Álvaro

[alvieboy]

Hey,

 

I need your reply on this:

 

Each popup will have an ID. Any idea about the type ? u16 ?

 

Each popup option will have a type, group ID and a value ID:

• a type is needed to create it, because we will support different types of entries (text, clickable text, radiobuttons);
  
• a group ID is needed if we intend to mix up different types of inputs (for example, clickeable text and some radio buttons and a text entry). For example, on this case the clickeable text would have group ID 0 and all of the radio buttons would have group ID 1 (or you can have multiple groups of radios, can also be done) and the text entry group ID 2.
  
• a value ID, to be sent back (not used for text entries).
  

I'd like to have preliminary sizes for them (u16,u32,char*). Any ideas so far?

 

Álvaro

[Entropy]

First, sorry for the late reply. Been busy with the test server, switching to a new scripting angine and had some additional issues tot ake care of.

 

The menu entry looks nice, but there should not be any \n between entries, unless if the server sends that at the end of some option string.

Maybe the server should send the x_size and y_size of the menu window as well.

 

As for the IDs, the type can be u8 (we'll never have more than 256 types).

The value ID should be u16, and the menu ID should be u16 as well.

 

As for the group ID, I am afraid I do not understand what exactly you mean, and why is it necesary.

[alvieboy]

Hey

 

First, sorry for the late reply. Been busy with the test server, switching to a new scripting angine and had some additional issues tot ake care of.

 

The menu entry looks nice, but there should not be any \n between entries, unless if the server sends that at the end of some option string.

Maybe the server should send the x_size and y_size of the menu window as well.

 

As for the IDs, the type can be u8 (we'll never have more than 256 types).

The value ID should be u16, and the menu ID should be u16 as well.

 

As for the group ID, I am afraid I do not understand what exactly you mean, and why is it necesary.

 

That "\n" you see in the code on each option at the end is just to overcome a "bug" in reset_soft_breaks, that does not process the last char. Actually that space you see between the options is a #define, so it can be changed to a smaller value.

 

About the size_x, I was thinking I could "figure out" an optimal value, assuming a minimum and a maximum width.

 

The size_y is automatic, and always fits the text/options to display.

 

Let me explain you the idea of grouping:

 

Imagine you want to send a popup like this:

 

Text: "How much time you play per day ? And do you play during daytime or during the night?"

Text Entry (group 0, no ID (is string) ): "Hours:"

Radiobuttons, group 1:

ID 1: "I play during the night"

ID 2: "I play during the day"

 

The reply to the server would have the following info:

Group 0, value "14(example)"

Group 1, value 2

 

If you don't want to mix up entry types, this is not needed.

 

Álvaro

[Entropy]

Oh, ok, so this is more of a thing to help us organize things better, rather than using large IDs.

 

Then the group ID and value ID should be 8b instead (except for the text).

[alvieboy]

Hey,

 

another thing I forgot to mention: If we're dealing with radiobuttons or text entries, we need a "send" button. But this button can be omited if we only have "one-click" options, like shown on my first screenshot.

 

The popup also can work in persistent/non-persistent mode - if it's persistent, when you use "one-click" options, the answer is sent back to the server, but the popup remains visible. This behaviour should be defined by the server, imho.

 

Another thing that came to my mind is splitting the popup ID in a class ID/instance ID. This could be used to avoid the same popup to pop up several times - for example, when the player is AFK. We should also ensure that on "critical moments" (like fighting), popups do not appear until the "critical moment" is gone. Or we could have a small icon "flashing" to notify the player that a popup requires his attention. Unless, of course, that the popup is triggered by player action, on that case it should appear immediately. So the class ID should depict whether the popup rises immediately, if it is a singleton, and maybe some other options.

 

About the server<->client protocol, do you want me to define a draft for it ?

 

Álvaro

[Entropy]

I don't think we need persistent menus for the time being. If we will in the future, we can add them.

In the future, we can also add client based menus, that are stored in XML or something on the client side, and the server will send a message like: "open menu blah", and the client will open it from the local saved xml.

 

But now we do not have time for that, we should first get this menu system to work.

 

I agree that we should have a submit button. I guess that should be implicit, and the server should not have to send it (the client would add it by default whe needed).

 

And yes, please define a draft for the protocol, then I'll see if we can improve it, or if it needs changes.

As soon as the draft is done and approved, I will add some server support so we can do some tests.

[alvieboy]

I don't think we need persistent menus for the time being. If we will in the future, we can add them.

In the future, we can also add client based menus, that are stored in XML or something on the client side, and the server will send a message like: "open menu blah", and the client will open it from the local saved xml.

 

But now we do not have time for that, we should first get this menu system to work.

 

I agree that we should have a submit button. I guess that should be implicit, and the server should not have to send it (the client would add it by default whe needed).

 

And yes, please define a draft for the protocol, then I'll see if we can improve it, or if it needs changes.

As soon as the draft is done and approved, I will add some server support so we can do some tests.

 

The persistence is already in the popup code. Just a few lines.

 

Do you prefer to use the CHAT_POPUP (255) channel for this or shall I set up a new command ?

 

Either way, I'll start defining it. I have to get this ready by thursday, I'm getting married saturday, and then I'll be out for a few weeks for my honeymoon.

 

I'll commit the code to berlios when it's ready so that some one can pick it up if needed after I leave. There is already a patch there that I need for the popup implementation (some additions to linked list support).

 

Álvaro

[alvieboy]

Preliminary:

 

 Server to Client Protocol definition:

Sizes are in bytes. Byteorder is preserved.

Variable sizes are depicted by capital letters.

Main header:
+------+--------+------------+--------------------------------------+
| Size | Type   | Name	   | Description						  |
+------+--------+------------+--------------------------------------+
| 2	| Uint16 | PopupID	| Unique ID for this popup.			|
| 1	| Uint8  | Flags	  | Popup flags. Reserved for expansion. |
| 1	| Uint8  | Title Size | Size (in chars) of popup title (*)   |
| A	| char[] | Title	  | Popup title.						 |
| 2	| Uint16 | SizeHint   | Hint of the desired popup width	  |
| 1	| Uint8  | Text Size  | Text size in the popup (*)		   |
| B	| char[] | Text	   | Text to be displayed by the popup.   |
+------+--------+------------+--------------------------------------+

After the main header comes the options. Any number of options
can be present.

Option Header

+------+--------+------------------+------------------------------+
| Size | Type   | Name			 | Description				  |
+------+--------+------------------+------------------------------+
| 1	| Uint8  | Option Type (**) | The option type.			 |
| 1	| Uint8  | Group ID		 | Group ID for this option	 |
| 1	| Uint8  | Text size		| Size of text (*)			 |
| C	| char[] | Text			 | Option text				  |
+------+--------+------------------+------------------------------+

For value options, follows this after each option header:
+------+--------+------------------+------------------------------+
| Size | Type   | Name			 | Description				  |
+------+--------+------------------+------------------------------+
| 1	| Uint8  | Value ID		 | Value to be sent back (***)  |
+------+--------+------------------+------------------------------+

Text options do not include anything more than the option header.

(*) Text do not include terminating \0.
(**) Option types <8 are text types, all others are value types.
 Defined types:
 TYPE_TEXTENTRY	0x00
 TYPE_TEXTOPTION   0x08
 TYPE_RADIOOPTION  0x09

(***) Value IDs range from 1-255. Value ID 0 is reserved.


Client to Server protocol:

Main header:
+------+--------+------------+--------------------------------------+
| Size | Type   | Name	   | Description						  |
+------+--------+------------+--------------------------------------+
| 2	| Uint16 | PopupID	| Unique ID for this popup.			|
| 1	| Uint8  | Flags	  | Popup flags. Reserved for expansion. |
+------+--------+------------+--------------------------------------+

Follows one or more entries:

+------+--------+------------+--------------------------------------+
| Size | Type   | Name	   | Description						  |
+------+--------+------------+--------------------------------------+
| 1	| Uint8  | group	  | Group ID							 |
| 1	| Uint8  | Value ID   | Value ID for this option			 |
+------+--------+------------+--------------------------------------+

If value ID == 0, then this is a textual entry option, so the text follows:

+------+--------+------------+--------------------------------------+
| Size | Type   | Name	   | Description						  |
+------+--------+------------+--------------------------------------+
| 1	| Uint8  | Text size  | Size of text entered (*)			 |
| D	| char[] | Text	   | Option text						  |
+------+--------+------------+--------------------------------------+