Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
MUSHclient
MXP and Pueblo
MXP Image

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	MXP Image
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Shadowfyr] 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: [code]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[/code] 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. [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2 3 4 5 6 7

Posted by

Shadowfyr USA (1,774 posts)

bio

Date

Mon 07 Apr 2008 06:16 PM (UTC) [ quote ]

Amended on Mon 07 Apr 2008 06:18 PM (UTC) by Shadowfyr

Message

Afraid not Erendir. Until/unless someone redoes the internals of the client to provide controls for these things, there isn't any way to make such a plugin work anyway. Even something as simple as a window "needs" support to handle close events, or other things, which the script system can't receive at the moment. Until we fix that issue, somehow, most any plugin that tries to provide such a feature is going to be "forced" to call some external program. And that isn't any different than right now, where it shows the link and clicking it will open your browser.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}