Autodownloading images

My plugin displays an avatar of your current opponent. The problem is I only have a few avatars so far - I plan to add more, but it's going to be an ongoing project. Rather than asking the players to redownload the latest avatar pack every few days, I'd like to have it done automatically.

Now what I could do is have a "missing avatar" image that provides a clickable link to the new avatar, so that if the mud tells the plugin to display an avatar that hasn't yet been downloaded, the player can just click on the "missing avatar" image to open a browser directed to the appropriate webpage, and then click "save as".

However that's quite a bit of a hassle for the player, particularly if they have to keep doing it for each monster they encounter...is there any way that it can be automated? Perhaps some way that I can just pass the plugin a URL and local destination, and let it handle the download automatically?

The only other option I can think of is to send the avatar directly from the mud using a binary protocol, and write it out to a file at the client end. But presumably that's going to require people to modify their sandbox settings?

I'm trying to keep this as simple for the players as possible. Any advice or suggestions would be appreciated.

The only way to do it without messing with the Sandbox is to use a language like VBScript which doesn't have a Sandbox in the first place.

It's the ugliest solution that I really don't want to advise, especially since I hate VBScript (or JScript for that matter), but it is the only real option. Python needs the user to install a rather sizeable thing first, Lua has the sandbox preventing you from writing anything to disk / downloading stuff without modifying the sandbox, other languages aren't available by default.

The sandbox is a good idea, but in the end, the fact that MUSHclient supports other scriptiong languages that have no such feature means that in reality, it ends up with a serious usability gimp for your users.

Automatic downloading is an issue that I haven't thought about in a long time, and I certainly haven't thought about it in the context of MUSHclient or Lua, but maybe this information will help you...

Back when I used zMUD, I made several scripts in VBScript that were executed through the microsoft script control service that used MSXML2.ServerXMLHTTP objects to automatically grab files or other data from the web and then do something with them.

An example of one can be found at:
http://www.not-porn.com/Aardwolf/ScriptInstaller.txt

It's supposed to download a script file from a server and then execute the contents to install the script into the user's local session.

Not sure if there's a way to port this concept to MUSHclient, but I'd be interested to know if anything similar can be done.

You could ship with an external program that communicates with your plugin via a UDP port and UdpListen(). If possible, you can write a shell script to launch it at the same time as MUSHclient, and use that as the MUSHclient shortcut.

Twisol, that's an even uglier solution than using VBScript. I salute you for your ingenuity.

Heh heh. If you want to support Linux you can't use any of the WSH-based languages, so my way is probably the only way aside from just dealing with the sandbox.

(Off-topic: Happy birthday to me.... I'm now 18. ^_^)

Many thanks for all the suggestions (and happy birthday Twisol)! I'd rather not ship the plugin with a separate program, so it looks like a VBScript plugin may be the best solution for me.

Could I create a simple VBScript plugin containing a function for writing the image, and then call that directly from the main (Lua) plugin? Or would the VBScript plugin need to handle its own negotiation with the mud? If the latter, can I assume OnPluginTelnetRequest() and OnPluginTelnetSubnegotiation() work with VBScript as well?

I believe pretty much all plugin callbacks should work just fine from VBScript and other non-Lua languages, although I seem to recall there might be one or two that are Lua only for some reason.

If you are content using a proxy plugin for the saving stuff, you could simply have the main plugin use LoadPlugin to load the proxy, and then CallPlugin() the VBScript function using the stuff you want to have free of the sandbox. Hell, if it doesn't happen often, you could even unload the plugin in the same batch, making the proxy plugin fully invisible to the user.

....

Which only demonstrates my arguments against the sandbox in the first place. There's a dozen ways to circumvent it, and even if one were to close the loadplugin loopholes by making those rules part of the whitelisting in the sandbox, there will always the simplest way to avoid things, which is by writing a plugin in VBScript. No user will ever wonder what language a plugin has been written in, so all in all, there is only a false sense of security. The only thing the sandbox succeeds in is making things more difficult for the honest scripters - the people with malicious intentions have a dozen ways around it which are unfeasible to 'fix'.

Can we get rid of the sandbox already, please? :)

Excellent point. I'm for removing the sandbox at this point, too.

...



If we can stick to the initial question at first, that would be good. If you want to open a new topic about removing the sandbox, I am happy to discuss it.

I think you can pretty easily simply download an avatar as a binary sequence. For one thing, the recent changes to the telnet negotiation makes that practical, as the binary sequence could contain any character including binary zero. The only proviso would be that the IAC character (hex FF) would need to be doubled, which would provide a slight overhead.

I would envisage an "avatar ID" being sent, and if the client can't find it, it requests that avatar image to be sent, and then save it under its ID.

Say the avatar was 32 x 32 pixels, and 3 bytes per pixel (RGB) then that is only 3072 bytes, and that is before compression. You could send a PNG file which would be convenient to set up at the server end, and MUSHclient could simply do WindowLoadImageMemory to take the binary representation of that image and load it into a miniwindow. And of course the PNG file would be smaller, as it is compressed.

The sandbox concerns don't really come into it here, because you could readily set up a SQLite3 database (which is allowed anyway), and a "blob" type, to store images under. So you simply save each avatar as a database record, and load them when required. Simple and quick.

I honestly think that setting up web servers to serve up the images, and then starting HTTP sessions (one way or another) is just more complex. At the end of the day the data still has to be downloaded one way or another, so the 3072 bytes (or whatever the length is) may just as well come into the main client stream as through a HTTP stream. Yes, there may be a slight delay, but that is like under a 3 Kb download, and only once per image, and with modern web connections most people would be used to downloading that amount every few seconds. Just as an example, the Downloads button on this page is is 2.5 Kb in size.

As for the sandbox, let's talk about that separately. I think I have shown that this particular issue can be easily resolved without even worrying about it.

Ah, I think I see the solution. De-implement support for the other languages. Then the sandbox does what it is designed to do - protect you.

Transferring the avatar should be easy, it's dealing with it at the client end that I'm not so sure about. However from what I gather, I should be able to do something like this:

1) Attempt to load the image from the images/avatars folder. If this fails:

2) Attempt to load the image from an SQLite3 database. If this fails:

3) Display a default avatar, and attempt to download the official avatar from the mud.

In theory I could skip step 1, but I'd rather keep an up-to-date avatar pack with the plugin download, so that players only need to download new avatars as they're introduced. I'd also like to make it as easy as possible for players to view and replace "official" avatars with their own if they wish - this is particularly important when running multiple sessions, if you want to add custom avatars for your characters so that you can better distinguish between them.

Is there an equivalent of WindowLoadImageMemory() for PlaySound()? This isn't as urgent as the avatars, but it would be rather nice if sounds could be downloaded on-demand as well.

Another option I'm considering is just to offer a prepackaged version of MUSHclient with the io library enabled. From reading the documentation, it seems that I could enable io for ONLY my own plugins, which should avoid putting the user at unnecessary risk from any other plugins they might install. I keep planning to offer a single-download option at some point anyway, so if I'm going to do that it's no hassle to configure the sandbox beforehand. This would also avoid the need for storing the images in two different formats.

However I think I'll have a play with the SQLite3 approach first - thanks for the suggestion.

See the Lua notes: PlaySoundMemory

Is there a reason PlaySoundMemory is not supported in other languages? I believe the COM type used for buffers is a BSTR, which can be upto 2GB in size if I recall properly, thus I don't see a technical reason why only Lua would be able to load stuff from buffers.

(Not that I am using this functionality at present, but if I end up downloading files from a webserver asynchronously using Python, I can imagine wanting them in a buffer only, rather than having to save them and then needing to delete them at a later stage.)

At present the internal prototype for strings is const char *, not BSTR, but maybe that could be made to work.