Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUDs
➜ General
➜ Suggested protocol for server to client "out of band" messages
Suggested protocol for server to client "out of band" messages
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1
2
3
4
5
6
7
8
9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #120 on Tue 09 Feb 2010 02:34 AM (UTC) |
Message
| I spotted a problem with the negotiation, if you have multiple plugins it was previously assuming that, if you didn't have any OnPluginTelnetRequest callback, that it DID have one, and it returned true.
This would really throw out negotiation, as the first plugin on its list might not have the OnPluginTelnetRequest callback, it responds true, but doesn't actually do anything.
Try the latest GitHub version, or wait for version 4.49 to fix this. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #121 on Tue 09 Feb 2010 06:54 PM (UTC) |
Message
| Version 4.49 is now released, in case anyone who does telnet negotiation plugins would like to try it. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Orik
USA (182 posts) Bio
|
Date
| Reply #122 on Sun 14 Feb 2010 01:57 AM (UTC) Amended on Sun 14 Feb 2010 02:01 AM (UTC) by Orik
|
Message
| How does t.combat work? I am putting my victim hp bar into an envy codebase and it's not knowing when I'm in combat. When I do the debug, I get a proper victim name, victim level, victim hp, and victim maxhp, but it doesn't show up on victim bar because of my ifcheck for t.combat.
EDIT______________
Nevermind, I think I figured it out. I took out the combat check in show_status. Put it back in and going to play with it a bit. | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #123 on Sun 14 Feb 2010 02:01 AM (UTC) |
Message
| In my code:
(ch->fighting && ch->fighting->who) ? "true" : "false",
... the flag was true if the character was marked as fighting, and fighting a non-null victim.
If this is always false you may need to look at where that boolean is set up. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Xtian
(53 posts) Bio
|
Date
| Reply #124 on Tue 16 Feb 2010 08:59 AM (UTC) |
Message
| The real might in this protocol is the way the server tells the client to generate a data structure. I am rather enthusiastic about this.
But I think you are not pushing the possibilities this allows us (us being MUD-admins and the client developer) far enough.
As you know, I am campaigning for a better world, where a MUD-player only has to install the client, enter his server-address and play. Now, this protocol allows us for the first time to present any player in _any_ MUD a generic GUI that is automatically adapted to that MUD. Without needing the player to perform additional configuration/installation.
How can this be achieved? Well, you're plugins are nearly there. You'd need to:
1.) Modify some of your more generalizable aardwolf plugins,like the health-bar, not to display the contents of 'tt.hp' and 'tt.maxhp' but for example the contents of the sub-elements in: 'tt.bar.' and 'tt.maxbar' (like 'tt.bar.hp' and 'tt.maxbar.hp' or it could be 'tt.bar.beer', 'tt.maxbar.beer' ...). The functionality stay the same, but the health-bar plugin adapts to the contents the MUD-server is sending!
2.) Package this (and maybe other) generalized plugins with the installation of mushclient! This is important. Your protocol is great for this because it is downwards and upwards-compatible. We will not have compatibility issues.
From this we gain:
- the user can have a "wow! a health bar!" reaction directly after installing Mushclient.
- I can tell my users to upgrade their old Mushclient versions and they will immediately see the mini-windows and health-bar without them changing a thing in the client.
- we reduce the workload of MUD-admins and invent the wheel only once for the whole community. Mud-admins needn't write plugins any more, just send the data they want over the protocol channels. The plugin was already written: One health-bar-plugin to rule them all.
- the plugins will be automatically updated with every upgrade of the client.
In effect I am able to present and change a GUI to all my players without them needing to do anything.
Please seriously consider this (packaging the plugins with the install / making the health-bar plugin adaptable), as I see much potential with it. I will gladly work to help you test and implement this.
Xtian
ps: To the other readers: Please don't forget that most readers here are Mushclient-Fanboys and as such experienced MUD-players, and probably consider themselves techies. Most of my players, on the other hand, don't even try to stay up to date with new Mushclient versions and many find it difficult to search for and install an additional plugin by hand. They're that kind of users. | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #125 on Tue 16 Feb 2010 07:12 PM (UTC) |
Message
| Thank you for your enthusiastic comments. Until now most of the replies on this thread had been about the flaws in my system, without much appreciation of the benefits.
I see what you mean about the generalized bar, I might do a bit of work in that direction. For example recently I had been adapting the health bar that works from ordinary prompts to show "hp", "endurance", "guile" rather than "hp", "mana", "move".
Your suggestion I gather is to send something like:
t.bar.HP = 40; t.maxbar.HP = 100;
t.bar.Move = 10; t.maxbar.Move = 50;
t.bar.Guile = 500; t.maxbar.Guile = 600;
... and so on, so that the bar automatically displays (in this case "HP", "Move" and "Guile". And if you added a fourth item the box would just get bigger.
To make this work generically we would have to agree on some keywords, so that the plugins would work with any generic MUD (in this case, the keywords bar and maxbar).
For example:
t.combat = true; -- or false obviously
t.dead = true;
t.status.blind = true; -- status afflictions (debuffs)
t.status.stunned = true;
Combat info might be usefully represented as a separate status box (much like in WoW) which might only appear if you are in combat. Something like:
t.target.name = "Large Naga";
t.target.percent.HP = 40;
t.target.percent.Mana = 30;
I'll put a bit of work into generating some ideas along these lines, and post more shortly. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Twisol
USA (2,257 posts) Bio
|
Date
| Reply #126 on Tue 16 Feb 2010 07:25 PM (UTC) |
Message
| Just to briefly note, ZMP has a sort of "subwindow" package that hasn't had much use yet, and was designed for something like the MUD-controlled windows youy're suggesting.
Also, I think this protocol is very cool on one level, given that it's simply Lua; the possibilities are endless. Yet on the other, there are some criticisms that should be brought up, for the good of the protocol. If I never got any criticism on my ideas, I'd think something was wrong, because nothing is perfect the first time through. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #127 on Tue 16 Feb 2010 09:27 PM (UTC) |
Message
| It's a Very Hard Problem (tm) to write a generic data passing protocol such that clients can automagically draw an appropriate GUI. It's hard enough when you have a subwindow package that handles presentation (as opposed to semantics), but far harder when you want to pass semantics instead of presentation. A simple reason is precisely that you need all users of the protocol to agree on what the data mean, which is a very difficult task.
My previous comments were made under the assumption that this was always meant to be a general purpose, generic protocol that could be plugged into servers and clients. I later found out that this was meant to be a custom job of sorts that one server and one client (via plugins, perhaps) would agree upon. That changes things considerably. But if the idea has again become to make a generic protocol, then I think that many of the points brought up are rather legitimate and should be reconsidered.
So basically it's not just a question of passing some data around. That's the easy part, really (and even then it is not clear that the protocol proposed here is the "best" way of passing data around for a generic protocol). It's what comes next that is considerably difficult; I've seen many protocols attempt to and then fail to solve this problem. This is why I am somewhat wary of claims to simplicity. Don't get me wrong, though, of course I am extraordinarily excited to see something like this come about. I just don't think it's quite a simple as has been made out.
For example, to enforce semantics, you will eventually be reimplementing a lot of what ZMP did, perhaps in a different way w.r.t. data separators or whatever, but the initial argument given in favor of this protocol was that it is "simple" (assuming Lua environments on at least the receiving side). That argument very rapidly goes away when you want to start discussing semantics -- even if those semantics are not data semantics, but semantics for calling presentation functions. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #128 on Tue 16 Feb 2010 11:26 PM (UTC) |
Message
| You both make good points. :)
I was excited about what Xtian said, because I think fundamentally he is correct - it would be fabulous if, for small effort, MUDs could have XP bars, gauges, status information (eg. blindness, death) shown more or less as "default" behaviour you get with a standard client.
I am experimenting purely privately right now to see where these ideas may lead us. Already a couple of interesting points have arisen. It is a nice idea to have an automatic health-bar window appear with generic bars like hp, mana, move, guile, rage, endurance and so on, but ...
- Given that the client is automatically displaying these bars, what order do they appear in? Alphabetic? Random? Server-defined? Alphabetic happens to work quite nicely for HP, Mana, Move, because that is the order they normally appear in.
- What colours should they be? If the client doesn't really know that HP should be green, and mana blue, how do we tell it?
- Once we get past a few bars of numbers that go up and down, what else what we might want to see? Eg. player name / class / race / level. Where would they go? In what order?
I can see the general point - the basic idea was simple, partly because it didn't try to automate too much. Once you start saying "I want the level in green in the bottom RH corner" you start introducing complexity.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #129 on Tue 16 Feb 2010 11:34 PM (UTC) Amended on Tue 16 Feb 2010 11:35 PM (UTC) by Nick Gammon
|
Message
| So far I am trying this:
"bar":
"Mana":
"max"=94
"cur"=94
"HP":
"max"=43
"cur"=23
"Move":
"max"=110
"cur"=90
"level"=2
"xp":
"max"=6509
"cur"=2691
In other words, everything in the "bar" table is intended for your health bar. Inside that are subtables, one for each line (mana, HP, move). Per line, you get the current and max. So you can easily add guile, endurance etc. by simply adding more subtables.
Also we see our player is level 2.
Also we see his experience is 2691 / 6509 - this is used to draw the experience bar.
What the server actually sends is:
IAC SB 102
bar={HP={cur=23;max=43}; Mana={cur=94;max=94}; Move={cur=90;max=110};}; xp={cur=2691;max=6509}; level=2;
IAC SE
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #130 on Wed 17 Feb 2010 02:57 AM (UTC) |
Message
| Here is an example of the generic health-bar plugin I have been working on:

|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #131 on Wed 17 Feb 2010 03:02 AM (UTC) Amended on Wed 17 Feb 2010 03:19 AM (UTC) by Nick Gammon
|
Message
| What that illustrates is:
- Player name (Nick)
- Player level (14)
- HP, Mana, Movement, Endurance (any number can be shown)
- The box adjusts to how ever many stats are desired
- In combat the background colour changes
- Buffs (positive affects) shown under (if any), grouped (eg. Bless(2)) and in alphabetic order
- Debuffs (negative affects) shown (if any)
- Order of bars can be specified by "seq" parameter (only needed once)
- Suggested colour of bars can be specified by "clr" parameter (only needed once)
- Bars can be specified by cur/max or percent (eg. to handle case where you want to say enemy is at 40% but not give out actual HP)
- Mouse-over any bar shows more detail (eg. HP 18/43 (41%))
- Window can be dragged around
- The server does not need to re-specify each value every time. For example, the level might only be specified when it changes, and the max_hp similarly.
The player name probably only needs to be mentioned once, when you log in.
Server code to generate the box:
IAC SB 102
name="Nick";
bar={
HP={cur=18;max=43;seq=1};
Mana={cur=42;max=94;seq=2};
Move={cur=90;max=110;seq=3};
Endurance={pct=80,clr="chocolate",seq=4};
};
xp={cur=2691;max=6509};
level=14;
combat=false;
buffs={"bless", "bless", "armor", "swim", "fly", "stealth"};
debuffs={"blind", "sick", "sick", "poison", "stunned"}
IAC SE
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #132 on Wed 17 Feb 2010 03:10 AM (UTC) |
Message
|
David Haley said:
A simple reason is precisely that you need all users of the protocol to agree on what the data mean, which is a very difficult task.
This is still only a suggested protocol, I don't have to convince anyone, although it seems Xtian is enthusiastic.
At the lower level, you can still just use the new telnet subnegotiation handling to manage anything you want, such as ZMP, ATCP or whatever.
Any MUD admin can choose to do:
- Nothing at all regarding these suggestions
- Use them unaltered, in which case they get some free, working plugins
- Use another protocol such as ATCP
- Devise their own improved protocol
Something like the plugin which generates the box above could indeed be distributed with MUSHclient. There is no harm if no-one uses it, and it is general enough that by adding a small amount of extra code to the server they can get the nice status box for very little work. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #133 on Wed 17 Feb 2010 03:31 AM (UTC) Amended on Wed 17 Feb 2010 03:32 AM (UTC) by Nick Gammon
|
Message
| If you want to play with this, the health bar is at:
http://github.com/nickgammon/plugins/blob/master/Health_Bar_Miniwindow_Telnet.xml
The experience bar is at:
http://github.com/nickgammon/plugins/blob/master/Experience_Bar_Telnet.xml
You need the new "gauge" module:
http://github.com/nickgammon/mushclient/blob/master/lua/gauge.lua
The "show status" code in SmaugFuss is now:
void show_status( CHAR_DATA *ch )
{
if (WANT_TELNET_INFO (ch))
{
CHAR_DATA * victim = NULL;
if (ch->fighting)
victim = ch->fighting->who;
char * pPlayerName;
pPlayerName = fixup_lua_strings (ch->name);
char buf[MAX_STRING_LENGTH];
snprintf(buf, sizeof (buf),
"\xFF\xFA\x66" // IAC SB 102
"tt=\"status\";" // transaction type: status
"name=%s;"
"bar={" // status bar info
"HP={cur=%d;max=%d};" // hp points
"Mana={cur=%d;max=%d};" // mana
"Move={cur=%d;max=%d};" // movement
"};" // end bar table
"xp={cur=%d;max=%d};" // experience
"gold=%i;" // gold
"level=%d;" // level
"combat=%s;" // in combat or not
"dead=%s;" // dead?
"poisoned=%s;", // poisoned?
pPlayerName,
ch->hit,
ch->max_hit,
IS_VAMPIRE( ch ) ? 0 : ch->mana,
IS_VAMPIRE( ch ) ? 0 : ch->max_mana,
ch->move,
ch->max_move,
ch->exp,
exp_level( ch, ch->level + 1 ) - ch->exp,
ch->gold,
ch->level,
(ch->fighting && ch->fighting->who) ? "true" : "false",
TRUE_OR_FALSE (char_died( ch )),
TRUE_OR_FALSE (IS_AFFECTED( ch, AFF_POISON ))
);
free (pPlayerName);
if( ch->first_affect )
{
AFFECT_DATA *paf;
SKILLTYPE *sktmp;
char * pAffectName;
strncpy(&buf [strlen (buf)], "buffs={", sizeof (buf) - strlen (buf));
for( paf = ch->first_affect; paf; paf = paf->next )
{
if (sktmp = get_skilltype( paf->type ))
{
pAffectName = fixup_lua_strings (sktmp->name);
snprintf(&buf [strlen (buf)], sizeof (buf) - strlen (buf),
"%s;", pAffectName);
free (pAffectName);
}
} // end for loop
strncpy(&buf [strlen (buf)], "};", sizeof (buf) - strlen (buf));
} // end if any affects
// combat info
if (victim)
{
const char * p = "You";
char * pName;
if (ch != victim)
{
if (IS_NPC( victim ) )
p = victim->short_descr;
else
p = victim->name;
}
pName = fixup_lua_strings (p);
snprintf(&buf [strlen (buf)], sizeof (buf) - strlen (buf),
"victim={name=%s;" // name
"hp=%d;maxhp=%d;" // hp points
"level=%d;" // level
"};",
pName,
victim->hit,
victim->max_hit,
victim->level
);
free (pName);
}
// finish telnet negotiation after the combat info
strncpy(&buf [strlen (buf)], "\xFF\xF0", sizeof (buf) - strlen (buf)); // IAC SE
send_to_char( buf, ch );
}
}
That handles code for buffs (but not debuffs yet).
In read_from_buffer I added a couple of lines to suggest bar colours:
write_to_descriptor(d, "\xFF\xFA\x66 tt=\"version\";version=1.0;\xFF\xF0", 0);
// define bar colours
write_to_descriptor(d, "\xFF\xFA\x66 bar={"
"HP={clr=\"darkgreen\"};" // hp
"Mana={clr=\"mediumblue\"};" // mana
"Move={clr=\"gold\"};" // movement
"};" // end bar
"\xFF\xF0", 0);
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Twisol
USA (2,257 posts) Bio
|
Date
| Reply #134 on Wed 17 Feb 2010 03:35 AM (UTC) |
Message
|
Nick Gammon said: Something like the plugin which generates the box above could indeed be distributed with MUSHclient. There is no harm if no-one uses it, and it is general enough that by adding a small amount of extra code to the server they can get the nice status box for very little work.
Pardon the departure from the main subject, but I'd rather see very few plugins distributed with MUSHclient. It's excess clutter for everyone, on the off chance that someone might want to use it (and it's entirely possible that their MUD can't support it without modification). I can also honestly say that I've never used any of the standard plugins, and while I'm sure they're quite useful, I don't need them.
As a very brief aside, this is also one of the reasons I'd love to have a good online repository of plugins, which you can easily download other plugins from. Your GitHub repository is definitely a great start, but it's also a bit difficult to search and sort. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
767,914 views.
This is page 9, subject is 23 pages long:
1
2
3
4
5
6
7
8
9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
It is now over 60 days since the last post. This thread is closed.
Refresh page
top