Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, 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.
Entire forum
➜ MUSHclient
➜ Suggestions
➜ Plugin autoinstaller
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| KaVir
Germany (117 posts) Bio
|
Date
| Fri 26 Aug 2011 09:38 AM (UTC) Amended on Fri 26 Aug 2011 09:39 AM (UTC) by KaVir
|
Message
| Aardwolf offers a custom version of MUSHclient that automatically installs its own plugins, and that's really nice for new players, as it keeps things simple. For my mud I just provide step-by-step installation instructions, but it's still an extra hoop for newbies to jump through, and despite making the instructions as clear as possible, some people still manage to make a pig's ear of it. Thus I've been planning to create my own package, similar to what Aardwolf has done.
But there are now 20 other muds that support MSDP, 17 of them using my protocol snippet, and most of them want to create their own MUSHclient GUIs (I've heavily promoted the snippet with screenshots, so that's probably the reason most people added it). Furthermore, those I've spoken to have all expressed a strong desire to make their plugins as easy as possible for newbies to get working, which suggests to me they may end up following Aardwolf's example.
It's one thing for Aardwolf to offer its own customised version of MUSHclient, but do you really want 20 muds doing it? I also firmly believe that we'll see an increasing number of muds developing their own GUIs in the future, so we could potentially reach a point where dozens of muds each offer their own prepackaged version of MUSHclient, and players end up downloading a separate version for each mud.
Mudlet have introduced a simple alternative - an autoinstaller:
Server: IAC DO ATCP
Client: IAC WILL ATCP
Server: IAC SB ATCP "Client.GUI <version> \n <path and filename>" IAC SE
When the player connects, the client automatically downloads the file, unzips it, and installs it. It can contain only one xml file, but any number of graphics, sounds, etc. The files are placed into a folder specific to that mud, so they won't interfere with the files used by other muds.
I realise that MUSHclient doesn't natively support ATCP, but the same general approach could be handled in other ways - perhaps an MXP tag, or even a (very simple) custom protocol. The next version of my snippet will include code and instructions for triggering the Mudlet autoinstaller, I'd be more than happy to include an option for MUSHclient as well if one were made available.
If security is a concern, you could open a dialog informing the player that a custom plugin is available, and ask if they wish to install it, with a "Don't ask me again for this mud" checkbox. People are going to be creating their own custom GUIs regardless, so players will download them one way or the other.
| Top |
|
Posted by
| Fiendish
USA (2,533 posts) Bio
Global Moderator |
Date
| Reply #1 on Fri 26 Aug 2011 09:44 AM (UTC) Amended on Fri 26 Aug 2011 09:45 AM (UTC) by Fiendish
|
Message
| I'm pretty sure this can already be done with a plugin, since plugins can already download files, move them around, and load other plugins. Given the extreme customizability that people seem to demand on Aardwolf, though, I question how good of an idea it is to let the server force install things on the player that the player may not want. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
Posted by
| KaVir
Germany (117 posts) Bio
|
Date
| Reply #2 on Fri 26 Aug 2011 10:08 AM (UTC) |
Message
|
Fiendish said: I'm pretty sure this can already be done with a plugin, since plugins can already download files, move them around, and load other plugins.
But that doesn't solve the problem - either the player has to manually install the plugin, or the mud has to distribute a version of MUSHclient with the plugin preinstalled.
I will distribute my own version of MUSHclient if that's the only option, but my question is do you really want to see 20+ muds each distributing their own version of MUSHclient, with players downloading one copy of MUSHclient for each mud they play?
Fiendish said: Given the extreme customizability that people seem to demand on Aardwolf, though, I question how good of an idea it is to let the server force install things on the player that the player may not want.
The dialog proposal would handle that - ask the player if they want to install the custom plugin, and include a "Don't ask me again for this mud" checkbox.
| Top |
|
Posted by
| Nick Gammon
Australia (23,061 posts) Bio
Forum Administrator |
Date
| Reply #3 on Fri 26 Aug 2011 11:38 PM (UTC) |
Message
| I think I see the general problem. Without providing a custom client (and then keeping it updated) the player has to:
- Download the "GUI experience" zip file
- Unzip it
- Copy it to the correct location (possibly confronting messages about "folder already exists")
- Run some sort of in-client procedure, like loading one or more plugins
- Save changes
- Possibly restart the client
For this to be automated however, some sort of non-intrusive "GUI file/update check" would need to be performed for everyone that downloads the client.
The ATCP sequence might be the way to go, but that sort-of means that the client has to briefly enable ATCP (enough to see this sequence) for all users.
Or, perhaps, another telnet protocol? (Like MCCP, ATCP, MSP etc.). This could be specifically for "the file xxx will enhance the client experience" (and include versioning etc.). That at least wouldn't clash with existing implementations, and modern clients should ignore telnet codes they don't recognize. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| KaVir
Germany (117 posts) Bio
|
Date
| Reply #4 on Sat 27 Aug 2011 12:38 AM (UTC) |
Message
|
Nick Gammon said: Or, perhaps, another telnet protocol? (Like MCCP, ATCP, MSP etc.). This could be specifically for "the file xxx will enhance the client experience" (and include versioning etc.). That at least wouldn't clash with existing implementations, and modern clients should ignore telnet codes they don't recognize.
The easiest approach would probably be an MXP tag, similar to <VERSION> or <SUPPORT>, as MUSHclient already supports MXP natively. The server could simply send the tag to the client after negotiation.
However it could also be done through a specialised OOB protocol. That would be a bit more work, but it would allow two-way communication, which might make some things easier (for example, after installing the plugin the client could ask the mud to renegotiate any plugin-specific protocols such as MSDP or GMCP - as otherwise the user would need to reconnect).
| 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.
16,496 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top