09 Nov, 2011, Rarva.Riendf wrote in the 161st comment:
Votes: 0
Just a question as I started to get into the process of customizing Mushclient.
First I saw that in the plugin yuo provide on your webpage the msdp parsing is different in GW and in the newest Plugin as Sloth (both work for me though)
Is it a result of the MSDP array thing ?
09 Nov, 2011, KaVir wrote in the 162nd comment:
Votes: 0
The MSDP specification has undergone a number of changes, however the current version of both the snippet and the generic plugin follow the latest specification (to the best of my knowledge).

I've not updated the version on my own mud for a while, as many of my players are using older versions of the plugin (or have written their own plugins or scripts). I've not yet decided whether I should make a clean break, or try to maintain backward compatibility.

Likewise, many people have added older versions of the snippet, and few of them update once they've added it. So you'll encounter some variation.
10 Nov, 2011, Rarva.Riendf wrote in the 163rd comment:
Votes: 0
On another note, I use LunarEclipse for editing the lua script, before pasting it in the xml files. I have outlined methods and variable, but no auto-competion nor indexing, it is quite painful to develop this way in 2011. Am I missing some configuration, any other editor that would work better for it ? What did you use ?
10 Nov, 2011, KaVir wrote in the 164th comment:
Votes: 0
Personally I just use PFE (Programmer's File Editor), but you can use whatever you like. A google search for "lua editor" brings up various suggestions. LuaEdit and Zeus both sound quite good.
10 Nov, 2011, Joseph Locke wrote in the 165th comment:
Votes: 0
Notepad++ is my preferred text editor for Lua.

That said, Lua for IntelliJ IDEA (https://bitbucket.org/sylvanaar2/lua-for...) offers a number if features, including (growing) support for auto/keyword completion. LuaForWindows ships with a Scite based editor that has a number of desirable features. If neither of those strike your fancy, you might try looking at Zeus (though I have not really used it) or Vim (highly recommended).
18 Nov, 2012, KaVir wrote in the 166th comment:
Votes: 0
Finally decided to get back to my plugin and add a couple of features I wanted. The first is the big map, which I added over two years ago (wow, it's really been two years?) - it can now be opened using a small circular icon in the top left corner of the top map, and you can use it to plot a course:



When my laptop broke, I used a netbook for a while, but the screen was really small - too small to properly display the maps. My new laptop is better, but it's still a tight fit, so I thought it might be nice to have resizable maps. That's where the second icon comes in (the arrow in the top right corner of the top map):



The big map only works in the realm plane, which is why the circle icon isn't visible in the above screenshot. I'll probably extend it to other locations as well, but I'm still trying to decide how I want to handle it.
13 Dec, 2012, ForgottenMUD wrote in the 167th comment:
Votes: 0
I thought I would reply here. I wanted to ask Tavish for the plugin that he posted on page 9 because it looks awesome. He was unreachable so I made my own and posted the code here: http://www.gammon.com.au/forum/?id=11859...

I only added menus (WindowMenu) today. I thought it was the most useful feature. Players can now click everything instead of learning obscure and difficult commands.


(Landscape only used as demo.)

Edit: Not sure why the image is small, but you can follow the link.
13 Dec, 2012, KaVir wrote in the 168th comment:
Votes: 0
ForgottenMUD said:
I thought I would reply here. I wanted to ask Tavish for the plugin that he posted on page 9 because it looks awesome. He was unreachable so I made my own and posted the code here: http://www.gammon.com.au/forum/?id=11859...

Tavish's plugin was based on an older version of mine (1.13 I believe), and I already gave you a link to my current version, were you not able to use it?

Also, as I explained to you on the MUSHclient forums, because you're doing everything in-band you won't be able to reproduce the same functionality - if you add energy bars below the avatars, they'll only update when new messages are sent to the text window. If you're waiting for your party to heal before moving on, for example, you'll have to keep hitting enter to refresh their energy bars.
13 Dec, 2012, plamzi wrote in the 169th comment:
Votes: 0
KaVir said:
ForgottenMUD said:
I thought I would reply here. I wanted to ask Tavish for the plugin that he posted on page 9 because it looks awesome. He was unreachable so I made my own and posted the code here: http://www.gammon.com.au/forum/?id=11859...

Tavish's plugin was based on an older version of mine (1.13 I believe), and I already gave you a link to my current version, were you not able to use it?

Also, as I explained to you on the MUSHclient forums, because you're doing everything in-band you won't be able to reproduce the same functionality - if you add energy bars below the avatars, they'll only update when new messages are sent to the text window. If you're waiting for your party to heal before moving on, for example, you'll have to keep hitting enter to refresh their energy bars.


I think KaVir may have a point, but the point should be rephrased a bit: Since you're using MUSHclient, you should consider making use of its built-in support for so-called 'out-of-band' so-called 'mud protocols'. Otherwise, you'd lose out on leveraging parsers that can save you some time (and if your client is not super-fancy, meet all your needs). If you need to pick, go with GMCP.
13 Dec, 2012, KaVir wrote in the 170th comment:
Votes: 0
plamzi said:
I think KaVir may have a point, but the point should be rephrased a bit:

No, the part of my MUSHclient plugin he wished to copy cannot be properly done in-band.

plamzi said:
If you need to pick, go with GMCP.

Bad choice. GMCP doesn't even have a specification, fails to adhere to its own data format, and is implemented inconsistently across muds and clients. It was created behind closed doors by Zugg (who is known for failing to follow his own specifications, and whose clients are no longer being actively developed) and IRE - and the IRE GMCP modules cannot be implemented out-of-band.
13 Dec, 2012, plamzi wrote in the 171st comment:
Votes: 0
KaVir said:
plamzi said:
I think KaVir may have a point, but the point should be rephrased a bit:

No, the part of my MUSHclient plugin he wished to copy cannot be properly done in-band.


If all he wants is to copy stuff, then I agree he should copy all the parts for it to actually work.

KaVir said:
plamzi said:
If you need to pick, go with GMCP.

Bad choice. GMCP doesn't even have a specification, fails to adhere to its own data format, and is implemented inconsistently across muds and clients. It was created behind closed doors by Zugg (who is known for failing to follow his own specifications, and whose clients are no longer being actively developed) and IRE - and the IRE GMCP modules cannot be implemented out-of-band.


The only part I like about GMCP is JSON. That alone makes it far better than other offerings because JSON is an actual standard. GMCP should have been called Loose JSON, just like MCCP should have been called zlib. The name is just pretense on the part of whoever came up with the TELOPT sequences to wrap them.

Show me a 'MUD protocol' that is not 'implemented inconsistently across muds and clients' :)

I'm not sure what IRE GMCP modules are or even what 'out-of-band' means when you use it, or why what IRE does would matter to ForgottenMUD's project.
13 Dec, 2012, KaVir wrote in the 172nd comment:
Votes: 0
plamzi said:
The only part I like about GMCP is JSON. That alone makes it far better than other offerings because JSON is an actual standard.

JSON has the advantage of being a standard, although it does also add bloat. GMCP uses "Kind of JSON". It has most of the bloat, without the advantage of being a standard.

plamzi said:
GMCP should have been called Loose JSON, just like MCCP should have been called zlib. The name is just pretense on the part of whoever came up with the TELOPT sequences to wrap them.

No, it's not that simple, there's more to the mud protocols than just a data format.

plamzi said:
Show me a 'MUD protocol' that is not 'implemented inconsistently across muds and clients' :)

MCCP2. But there are degrees of inconsistency, MSDP is far more consistently implemented than GMCP.

plamzi said:
I'm not sure what IRE GMCP modules are or even what 'out-of-band' means when you use it, or why what IRE does would matter to ForgottenMUD's project.

ForgottenMUD wants to copy the avatars with health bars for nearby people from my plugin. That requires the data to be sent out-of-band, otherwise you have to keep hitting enter to see the health bars refill.

IRE defines messages such as Comm.Channel.Start which "informs the client that text that follows is something said over a communication channel". That means you need to know the order of the GMCP messages relative to the normal data stream - they cannot be sent out-of-band.
13 Dec, 2012, plamzi wrote in the 173rd comment:
Votes: 0
KaVir said:
plamzi said:
The only part I like about GMCP is JSON. That alone makes it far better than other offerings because JSON is an actual standard.

JSON has the advantage of being a standard, although it does also add bloat. GMCP uses "Kind of JSON". It has most of the bloat, without the advantage of being a standard.


To the degree that GMCP is like JSON, it is great :) Especially if on the client side you have a JSON parser all done for you.

To the degree that MSDP adds less bloat, it is great. Especially if you are only building for one MUD client, and that MUD client has an MSDP parser all ready for you.

KaVir said:
plamzi said:
GMCP should have been called Loose JSON, just like MCCP should have been called zlib. The name is just pretense on the part of whoever came up with the TELOPT sequences to wrap them.

No, it's not that simple, there's more to the mud protocols than just a data format.


Yeah, there are three bytes to negotiate, three bytes to start and two bytes to end. The rest is stuffing a potentially very long arbitrary string (that's very much in-band) inside a TELOPT wrapper that was never meant to carry more than short sub-negotiation message data.

KaVir said:
plamzi said:
Show me a 'MUD protocol' that is not 'implemented inconsistently across muds and clients' :)

MCCP2. But there are degrees of inconsistency, MSDP is far more consistently implemented than GMCP.


Of course! That's because it's not a protocol, it's a 20-line implementation of zlib compression. You either get it right or it doesn't work at all. If there was any wiggle room at all, I'm sure some MUD would have taken liberties.

KaVir said:
plamzi said:
I'm not sure what IRE GMCP modules are or even what 'out-of-band' means when you use it, or why what IRE does would matter to ForgottenMUD's project.

ForgottenMUD wants to copy the avatars with health bars for nearby people from my plugin. That requires the data to be sent out-of-band, otherwise you have to keep hitting enter to see the health bars refill.

IRE defines messages such as Comm.Channel.Start which "informs the client that text that follows is something said over a communication channel". That means you need to know the order of the GMCP messages relative to the normal data stream - they cannot be sent out-of-band.


Are you talking about out-of-band as in a separate socket that you connect to in parallel to get data independently of what's going on in the normal game session? Because if not, you will always know the order of GMCP messages relative to the normal data stream. That is, unless you are using a client that doesn't report the order to third-party plugins.
13 Dec, 2012, KaVir wrote in the 174th comment:
Votes: 0
plamzi said:
Yeah, there are three bytes to negotiate, three bytes to start and two bytes to end.

No, there's a lot more than that. I suggest you read the MSDP and ZMP specifications, and the documentation that's available for various GMCP implementations. You'll note that they cover a lot more than a handshake and a data format.

plamzi said:
Are you talking about out-of-band as in a separate socket that you connect to in parallel to get data independently of what's going on in the normal game session? Because if not, you will always know the order of GMCP messages relative to the normal data stream. That is, unless you are using a client that doesn't report the order to third-party plugins.

The point of out-of-band data (referred to as "urgent data" in TCP) is that it's sent ahead of any data that's already queued for transmission. MUSHclient and Mudlet don't report or track the order (nor should they). Nor does my snippet. Related thread: Is MSDP out-of-band?
13 Dec, 2012, ForgottenMUD wrote in the 175th comment:
Votes: 0
KaVir said:
Tavish's plugin was based on an older version of mine (1.13 I believe), and I already gave you a link to my current version, were you not able to use it?

Also, as I explained to you on the MUSHclient forums, because you're doing everything in-band you won't be able to reproduce the same functionality - if you add energy bars below the avatars, they'll only update when new messages are sent to the text window. If you're waiting for your party to heal before moving on, for example, you'll have to keep hitting enter to refresh their energy bars.


Hey KaVir, I'm sorry, I didn't understand that your plugin contained a monster list. I thought that Tavish only used your protocols to make one. Anyway, my plugin doesn't require the player to press enter, it sends an invisible MXP tag that is not necessarily a response to player input. I will update to a more efficient protocol once I understand them.
14 Dec, 2012, Tavish wrote in the 176th comment:
Votes: 0
ForgottenMUD said:
Hey KaVir, I'm sorry, I didn't understand that your plugin contained a monster list. I thought that Tavish only used your protocols to make one.

The plugin didn't have a mob list at the time I started using it, IIRC it wasn't even an actual snippet at that time just what he had released for GW2. That was enough to get my head wrapped around how to get started with negotiating the handshake and some basic lua and MUSHClient functions that pointed in the right direction.
14 Dec, 2012, Scandum wrote in the 177th comment:
Votes: 0
plamzi said:
To the degree that GMCP is like JSON, it is great :) Especially if on the client side you have a JSON parser all done for you.

To the degree that MSDP adds less bloat, it is great. Especially if you are only building for one MUD client, and that MUD client has an MSDP parser all ready for you.


MSDP is much more granular than GMCP, so it's definitely the better protocol for MUDs wanting to provide data and let players figure out the interface, so the developers can spend their time on actual game development.

The advantage of GMCP is that you can use predefined packages, though it's anyone's guess if this results in consistent behavior between clients. It's also much bulkier, which is a drawback as this can in theory double or even triple your bandwidth usage compared to MSDP. Needless to say that MSDP supports packages as well, though MSDP parsers capable of parsing nested data are slow to emerge.
160.0/177