19 Oct, 2010, Rudha wrote in the 1st comment:
Votes: 0
Tavish said:
Nothing major, but I changed the login screen to an image splash instead of the ASCII login. The image isn't public domain so I'm just using it as a stand-in for right now. The final version would have the mud name set against the image.



I actually want, at some point, to have little images like that for each screen and room in the gameworld, its been something Ive been playing with in my head whether it would be feasible or not.

Maya/Rudha
19 Oct, 2010, Tavish wrote in the 2nd comment:
Votes: 0
Rudha said:
I actually want, at some point, to have little images like that for each screen and room in the gameworld, its been something Ive been playing with in my head whether it would be feasible or not.

Maya/Rudha

Its definitely feasible, although there are some major downsides to it. Download size being the minor one (unless you are going browser-based and even that could get hairy depending on the quality/size of the art), getting the actual artwork is the major one. Its a pretty big struggle to get decent art for just 20 or so mob types, so I couldn't even imagine how difficult it would be to get art for each room.
19 Oct, 2010, Rudha wrote in the 3rd comment:
Votes: 0
Tavish said:
Rudha said:
I actually want, at some point, to have little images like that for each screen and room in the gameworld, its been something Ive been playing with in my head whether it would be feasible or not.

Maya/Rudha

Its definitely feasible, although there are some major downsides to it. Download size being the minor one (unless you are going browser-based and even that could get hairy depending on the quality/size of the art), getting the actual artwork is the major one. Its a pretty big struggle to get decent art for just 20 or so mob types, so I couldn't even imagine how difficult it would be to get art for each room.


Thankfully, I have no end of talented artist friends. I don't have a problem with actually producing it - what I'm more having a problem with, as you pointed out, the distribution. Theres a few ways I could go about it and Im not sure how keen I am on them. I could bundle a big 'elvenblade art package' which I already know some people would miss downloading and Id have to be fielding a lot of WHY IS ART NOT WERKING questions, or I could have it simply with the browser client, though that would make for a fairly larger bandwidth footprint.

Maya/Rudha
19 Oct, 2010, KaVir wrote in the 4th comment:
Votes: 0
Rudha said:
Thankfully, I have no end of talented artist friends. I don't have a problem with actually producing it - what I'm more having a problem with, as you pointed out, the distribution. Theres a few ways I could go about it and Im not sure how keen I am on them. I could bundle a big 'elvenblade art package' which I already know some people would miss downloading and Id have to be fielding a lot of WHY IS ART NOT WERKING questions, or I could have it simply with the browser client, though that would make for a fairly larger bandwidth footprint.

I had the same issue with avatars - you might find this thread of interest:

http://www.gammon.com.au/forum/bbshowpos...

Right now I just distribute a new avatar package with each new version of the plugin, but that's only a short-term solution. Eventually I'll probably add some means of downloading the data directly from the mud, and using it to create images at the client end.
19 Oct, 2010, Rudha wrote in the 5th comment:
Votes: 0
It would be nice if there was a MSP-ish way of specifying a download URL for graphics to display. I suppose you could do that with MSDP if the client was able to interpret it as to download and display it. Im not sure of the capability of clients to do that.

Maya/Rudha
19 Oct, 2010, KaVir wrote in the 6th comment:
Votes: 0
I'll probably just do it through MSDP, to be honest. I'm already using MSDP to pass the avatar IDs to the client, so if they don't support MSDP then they wouldn't be able to do anything with the avatars anyway.
19 Oct, 2010, Rudha wrote in the 7th comment:
Votes: 0
I guess what Im trying to get my head around is how its feasible to use MSDP to get the picture to the client. I suppose, if I really wanted to, I could even just pass the picture itself in the MSDP packet, though that would probably be misusing MSDP just a little.

Optimally, I'd like to send a packet something like:
Quote
IAC SB MSDP
MSDP_VAR "ROOM"
MSDP_VAL MSDP OPEN
MSDP VAR "UID" MSDP VAL "room0001"
MSDP VAR "proto" MSDP VAL "room@prototypes"
MSDP VAR "pic_id" MSDP VAL "generic_room.jpg"
MSDP VAR "dl_loc" MSDP VAL "http://www.elvenblade.ca/client_pictures..."
[…other room stuff…]
MSDP_CLOSE IAC SE

(formatting not part of the negotiation, obviously, just for readbility's sake)

And then have the client look for a 'generic_room.jpg' image on the clients working directory, with the option to load it from the web url provided if they dont have it on the drive, and have enabled downloads.

I know that Mud Sound Protocol does something like this intrinsically, but Im unsure if the capability is implemented separately which would allow me to do the same for a MSDP implementation.

Maya/Rudha
20 Oct, 2010, chrisd wrote in the 8th comment:
Votes: 0
Rudha said:
It would be nice if there was a MSP-ish way of specifying a download URL for graphics to display.

Rudha said:
I know that Mud Sound Protocol does something like this intrinsically […]


MXP has an <IMAGE> tag which supports downloading images from URLs on the fly. That being said, both MXP and MSP are in-band, so sending images using MXP would make it difficult to display said images in a separate pane as KaVir and Tavish are doing.

I think sending info over MSDP and then having the client/plugin fetch the image from the web is the best bet. Nonetheless, I would be interested in seeing whether the user encounters any hiccups when the image itself is sent using MSDP. I can't imagine that a 100x100 PNG would cause too much trouble unless the connection is relatively slow.

EDIT: Fixed quote.
20 Oct, 2010, Rudha wrote in the 9th comment:
Votes: 0
You can send images with MSDP easily. The problem is saving them. I know MushClient has a fairly restrictive sandbox when it comes to file writing. I'm not sure about zMud, but I don't even have zMud, so that's a moot point to me. And I suppose I can make my own client do whatever, so that leaves MC, since the other client compatible with MDSP wont be able to display images anyways (TinTin)

It's important to note that I not only want to send the file, I want to save the file to the client's hdd, if they've chosen to allow downloads.

The forum thread KaVir posted suggests using a database, which is a possibility, though I'd prefer to just write the actual files, if possible.

Maya/Rudha

[edit]: As regards sending the URL, I've reconsidered that in light of Nick Gammon's words in that thread. Its probably best to just send it in the main OOB stream, as opposed to having to go HTTP as well. The real question becomes the data retention so I dont have to send it every time that they 'hit' that image.
20 Oct, 2010, David Haley wrote in the 10th comment:
Votes: 0
chrisd said:
I think sending info over MSDP and then having the client/plugin fetch the image from the web is the best bet. Nonetheless, I would be interested in seeing whether the user encounters any hiccups when the image itself is sent using MSDP. I can't imagine that a 100x100 PNG would cause too much trouble unless the connection is relatively slow.

Interestingly enough, this was a major point of contention for ATCP2. Some people wanted to be able to send binary data down the line for reasons similar to this, without adding too much overhead as you might find with Base64 encoding or something like that. Other people were adamant that Base64 was sufficient, and that you shouldn't be sending binary data in the first place. Since Zugg happened to be one of those people, the ATCP2 protocol as it stands makes no special provision for binary data.

Base64 has the advantage of naturally fitting into protocols that allow all text characters too appear naturally, this removing the need to escape special characters like field delimiters. But clearly, it has the disadvantage of introducing a lot of overhead, which kind of defeats the purpose here of compactly sending data down the line. The roughly 37% overhead makes it much more interesting to use standard web downloads, but that requires more effort for all involved – and furthermore, not all MUDs actually have web space in the first place and so would not be able to provide URLs.

This also brings up the issue of caching, and there was some pretty heated disagreement there too. Clearly, you wouldn't want to send around the whole image every time.

By the way, people were asking in some other thread about why new protocols keep cropping; this is a pretty good example. If your requirements are such that binary data is important, and you want to use ATCP2, you must accept the ~37% overhead, which might in fact be unacceptable.

Rudha said:
I know MushClient has a fairly restrictive sandbox when it comes to file writing.

No, not necessarily, at least not in Lua (which is the sandboxed language anyhow). The sandbox is user-configurable… Furthermore, Nick has spent a lot of work getting SQLite databases working as part of the normal API, so you could just store the data there.
20 Oct, 2010, Rudha wrote in the 11th comment:
Votes: 0
Reading from http://www.gammon.com.au/forum/bbshowpos...:

Nick Gammon said:
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.


My primary concern with this solution is that its the non-optimal solution for me, the optimal one being able to dynamically update the users filesystem with new graphics without having to require them to download the newest graphics images.

I suppose that a workaround could be keeping all of the images in the database, which would also have the benefit that the end user would not have to download any graphics packs to begin with. My problem with -that- workaround is that I would want the users to be able to control the amount of data I'm putting on their hard drive. In my past experience people can get frustrated and angry if they feel that a program is downloading appreciable amounts of data outside of their direct requests.

I suppose it just comes down to the tradeoffs I want to make.

Maya/Rudha
20 Oct, 2010, chrisd wrote in the 12th comment:
Votes: 0
If it's just MC you're worried about, why not go with the MC-recommended solution? :smile:

My concern wasn't really the ease with which you can send images using MSDP, but rather the player's experience. Depending on the image size and the speed of the connection, a player might enter a room which requires an image download, find that nothing happens for a second and then a new image pops up along with several "you are being attacked!" messages. This is unlikely to happen unless the image you're sending is fairly large, but it's obviously something to bear in mind. That being said, I don't know if fetching if from a URL would make any difference in MC's case.
20 Oct, 2010, David Haley wrote in the 13th comment:
Votes: 0
Rudha said:
My primary concern with this solution is that its the non-optimal solution for me, the optimal one being able to dynamically update the users filesystem with new graphics without having to require them to download the newest graphics images.

I'm a little confused here. What Nick described was in fact a way to dynamically update the client filesystem behind the scenes without requiring user intervention to go download something.
(Obviously, this assumes a plugin that takes care of this, but I think that's a given at this point – it must be either a plugin or a custom client, if we're doing things like this.)

Rudha said:
My problem with -that- workaround is that I would want the users to be able to control the amount of data I'm putting on their hard drive. In my past experience people can get frustrated and angry if they feel that a program is downloading appreciable amounts of data outside of their direct requests.

You could always have the plugin provide a cache size parameter such that it only stores that much data before discarding older entries. Of course, you've now significantly increased the complexity of this whole scheme, because the client plugin needs to track which files have been used more recently than others.

It's not like you would be giving them control if you forced them to download a bundle with all the images ahead of time. They'd still have to accept the whole bundle or not be able to play properly. As long as the files are stored in some easy-to-delete place, I wouldn't think this would be a big issue. I've not encountered players who'd get actually angry about a game doing something that allows them to play, though, and many people seem to put up with it when modern online games update themselves or download additional context (like new maps, avatars, items, whatever).

chrisd said:
My concern wasn't really the ease with which you can send images using MSDP, but rather the player's experience. Depending on the image size and the speed of the connection, a player might enter a room which requires an image download, find that nothing happens for a second and then a new image pops up along with several "you are being attacked!" messages. This is unlikely to happen unless the image you're sending is fairly large, but it's obviously something to bear in mind.

I don't think it would be that bad if you were ever so slightly clever about it. If you were able to identify the most common images and send them ahead of time, then you wouldn't run into this problem unless the player was running around faster than graphics could be downloaded – and even then it'd be a one-time cost.

An example of how you'd do this would be a server sending the "starter bundle" of images over the out-of-band channel. Of course, since you don't want to make them wait for a while at first connection (or maybe you do?? with a "please wait while we load the images…" message) you could send the images in pieces. This increases plugin complexity, because it now needs to track a message spanning several subnegotiation boundaries. But it will reduce the visible impression of "lag" because the server would be sending just a few segments at a time meaning that the delay might be about a tenth of a second, or even less, before you return to the normal output channel.

chrisd said:
That being said, I don't know if fetching if from a URL would make any difference in MC's case.

I think you could download in a coroutine using a separate connection object, for instance, which would make it non-blocking.
20 Oct, 2010, Kaz wrote in the 14th comment:
Votes: 0
KaVir said:
Right now I just distribute a new avatar package with each new version of the plugin, but that's only a short-term solution. Eventually I'll probably add some means of downloading the data directly from the mud, and using it to create images at the client end.


I don't know the capabilities of the plugin language that MUSHClient has (can it save data?), but you might be able to adapt and adopt the MFTP protocol I dropped on MudStandards a while back. That was designed for this very problem.
20 Oct, 2010, David Haley wrote in the 15th comment:
Votes: 0
Kaz said:
I don't know the capabilities of the plugin language that MUSHClient has (can it save data?)

Yes it can, fortunately. Specific details were covered in some of the recent posts. :smile:
20 Oct, 2010, KaVir wrote in the 16th comment:
Votes: 0
Note to moderators: Would it be possible to split this into another thread about downloading images? Starting with post #143 perhaps, including #144 and #145, then skipping #146, but copying #147 onwards. This is already a long thread and it's going to get difficult to follow two discussions at once. I could split from here, but I'd rather a moderator did it retroactively so that we've got the full discussion in one place. This comment can be deleted.

chrisd said:
MXP has an <IMAGE> tag which supports downloading images from URLs on the fly. That being said, both MXP and MSP are in-band, so sending images using MXP would make it difficult to display said images in a separate pane as KaVir and Tavish are doing.

I don't think MUSHclient natively supports <IMAGE> anyway, you'd probably need another plugin for it.

Rudha said:
You can send images with MSDP easily. The problem is saving them. I know MushClient has a fairly restrictive sandbox when it comes to file writing.

My thread about saving avatars stirred up a bit of a hornets nest, and resulted in the sandbox being changed for later versions of MUSHclient. Previously the user had to add exceptions (at least for Lua), but that's no longer necessary in later versions. Although I didn't yet get around to testing it, you should now be able to write files without any problem. If the image is quite large, there's no reason why you couldn't download it a bit at a time - depending on the format, you could even show the user the partial image, so that they'd see it slowly appear.
20 Oct, 2010, David Haley wrote in the 17th comment:
Votes: 0
Agreed re: thread split.

KaVir said:
I don't think MUSHclient natively supports <IMAGE> anyway, you'd probably need another plugin for it.

Correct. Having another plugin would be a very difficult task because the main rendering window simply doesn't support images, though – in fact, it might be basically impossible unless you're willing to rewrite the main input window. It would be better to just write plugins that use separate rendering windows like people have been doing here.

KaVir said:
Previously the user had to add exceptions (at least for Lua)

Lua is the only scripting language that even has/had a sandbox, really. In fact, you can make the stronger statement that Lua is basically the only supported language that is really "sandboxable" in the first place.
20 Oct, 2010, Scandum wrote in the 18th comment:
Votes: 0
A MUD ftp protocol would be an option, but I don't think zmud/mushclient would implement it unless it was their idea, which would create the same situation as with MSDP.
20 Oct, 2010, David Haley wrote in the 19th comment:
Votes: 0
I'm replying to Rudha's comment from the other thread here, since I think it was made there by mistake (and it is relevant here, and in reply to posts here).
Rudha said:
David: what he described is writing blob fields in a database, not writing image files to the filesystem

If you have access to the file system to write to a database file, and the sandbox is removed in the first place, do you not have access to writing files? I don't understand what the difficulty is…

Anyhow, what's the big difference between storing the blobs in a database and as individual files? In both cases they live on the filesystem and the goal of not downloading files again while being able to dynamically update them is accomplished.

Scandum said:
A MUD ftp protocol would be an option, but I don't think zmud/mushclient would implement it unless it was their idea, which would create the same situation as with MSDP.

Fortunately, with an open client like MUSHclient, it doesn't matter if Nick doesn't want to do it because you can do it yourself either in the C++ source code, or as a plugin by reading the telnet subnegotiation channel.
20 Oct, 2010, Rudha wrote in the 20th comment:
Votes: 0
If you read the thread that I was quoting that from, the problem is that file access is restricted by the sandbox. Using the database, however, is not, and therefore provides a work-around, though not entirely an optimal one.

I really shouldn't have to explain the difference between having the data stored as files in a filesystem and having them as blob fields in a database.

Maya/Rudha
0.0/23