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 ?
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 ?
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).
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ?