Frankly, I think at some point the "easiest" solution isn't to inline at all, but use a separate window for images. But, obviously this adds more code to the mess. And while FTP/HTTP support is a must (BTW, if done **please** try to find decent code that handles server resuming properly, instead of the garbage in most software and browsers, which is too stupid to tell the difference between a "failure" to complete and a finished file...), since it needs to operate in a separate thread, so as not to muck with client/script operation. Oh, and it needs bandwidth throttling. Some people might not mind waiting an extra 30 seconds or more to "see" an image, if displaying it over dialup didn't also make playing completely impossible while waiting. Most FTP/HTTP systems assume you are using the "full" bandwidth to get it as fast as possible, which isn't too helpful if you don't "have" that bandwidth.
In terms of script operation, obviously you would have something like:
world.download("http://bigfiles.com/mybigfile.dat", "c:\mydocu~1\mushstuff\)
sub OnPluginFTPComplete (name)
if name = "mybigfile.dat" then
'do some stuff...
end if
end sub
Assuming you allowed some means to get other data through the script. A must if the data isn't and image, or is a format you can't handle internally, so do want to use some external system to deal with. You might also want to display existing images from your system, so functions for that could be useful. And, so things work well, you need to a) cache images in a scrollable window, so you can view any you may have missed, and b) have a pending download system, so if someone moves from one room to the next, either the prior one is halted, then shoved down the queue, or allowed to finish *before* the new one is shown. Which one is likely to depend on the player. Of course, there would be a cache for all images on disk, but the internal one would be X number from this "session" or "all from this session". Probably as a list, so they can be reloaded from disk, or resumed if you move back into the prior room.
My only real issue with the whole thing is, this adds more code to the client, without adding code that helps solve the problem I have always wanted to. Hear me out. What makes more sense, a window that supports objects, which just *happens* to be used to be used by the new feature for images, but whose same "image" code can be use in a script generated one to say, display you inventory graphically, or one that is hard coded only to deal with the images, requiring yet "more" code to be added to the client to handle the next trick we want pulled from the hat? The later is bound to bloat things far faster than a universal window which can be scripted to do other things.
Just saying, since, if this makes sense to people, maybe it would encourage them to look for how to do it too, not just leave me as the only one trying to find a solution. We want to avoid bloat, but every time we add new windows or features, without more generic support "for" them, we add even more code to the client, which we wouldn't necessarily need, if we had something more generic that could be adapted readily to do it. Just a thought. |