Gammon Forum : MUSHclient : General : Autodownloading images

Register forum user name Search FAQ

Gammon Forum

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

General

Autodownloading images

Autodownloading images

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by

KaVir Germany (117 posts)

Date

Wed 11 Aug 2010 01:38 PM (UTC)

Amended on Wed 11 Aug 2010 01:39 PM (UTC) by KaVir

Message

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.

Posted by

Worstje Netherlands (899 posts)

Date

Reply #1 on Wed 11 Aug 2010 03:24 PM (UTC)

Message

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.

Posted by

Fiendish USA (2,533 posts)

bio Global Moderator

Date

Reply #2 on Wed 11 Aug 2010 03:28 PM (UTC)

Amended on Wed 11 Aug 2010 03:30 PM (UTC) by Fiendish

Message

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.

https://github.com/fiendish/aardwolfclientpackage

Posted by

Twisol USA (2,257 posts)

Date

Reply #3 on Wed 11 Aug 2010 04:10 PM (UTC)

Message

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.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Worstje Netherlands (899 posts)

Date

Reply #4 on Wed 11 Aug 2010 04:28 PM (UTC)

Message

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

Posted by

Twisol USA (2,257 posts)

Date

Reply #5 on Wed 11 Aug 2010 04:41 PM (UTC)

Amended on Wed 11 Aug 2010 04:42 PM (UTC) by Twisol

Message

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. ^_^)

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

KaVir Germany (117 posts)

Date

Reply #6 on Wed 11 Aug 2010 07:25 PM (UTC)

Message

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?

Posted by

Worstje Netherlands (899 posts)

Date

Reply #7 on Wed 11 Aug 2010 08:02 PM (UTC)

Message

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

Posted by

Twisol USA (2,257 posts)

Date

Reply #8 on Wed 11 Aug 2010 09:49 PM (UTC)

Message

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

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #9 on Wed 11 Aug 2010 11:15 PM (UTC)

Message

KaVir said:

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?

...

Twisol said:

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #10 on Wed 11 Aug 2010 11:46 PM (UTC)

Message

Worstje said:

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.

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

KaVir Germany (117 posts)

Date

Reply #11 on Thu 12 Aug 2010 02:41 PM (UTC)

Amended on Thu 12 Aug 2010 02:42 PM (UTC) by KaVir

Message

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.

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #12 on Thu 12 Aug 2010 08:57 PM (UTC)

Message

KaVir said:

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.

Template:function=PlaySound

PlaySound

The documentation for the PlaySound script function is available online. It is also in the MUSHclient help file.

See the Lua notes: PlaySoundMemory

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Worstje Netherlands (899 posts)

Date

Reply #13 on Fri 13 Aug 2010 12:15 AM (UTC)

Message

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

Posted by

Nick Gammon Australia (23,042 posts)

bio Forum Administrator

Date

Reply #14 on Fri 13 Aug 2010 12:28 AM (UTC)

Message

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

- Nick Gammon

www.gammon.com.au, www.mushclient.com

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.

41,106 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )