[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

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

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  MXP and Pueblo
. . -> [Subject]  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:
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)  [Biography] 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();}
[Go to top] top
Posted by Erendir   Germany  (47 posts)  [Biography] bio
Date Sun 06 Apr 2008 09:17 PM (UTC)  [ quote  ]
Message
Quote:
As a side note, if there were scripting hooks into MUSHclient's MXP parser, so we could write handlers for MXP tags that MUSHclient doesn't support, then writing a plugin that popped up a new window with the image would be fairly straightforward.

Python has a decent http client in its standard library and the PIL (Python Imaging Library) has a free version and supports the most important image types (jpg/png/gif -- though not gif animation).


Quote:
However what you could do is intercept the tag using OnPluginMXPopenTag. Then that interception could do what you suggest.



do somebody made this plugin?..
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Mon 18 Jun 2007 07:12 AM (UTC)  [ quote  ]
Message
Well, MUSHclient supports the <img> tag- to an extent.

However what you could do is intercept the tag using OnPluginMXPopenTag. Then that interception could do what you suggest.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Isthiriel   (111 posts)  [Biography] bio
Date Mon 18 Jun 2007 06:35 AM (UTC)  [ quote  ]
Message
As a side note, if there were scripting hooks into MUSHclient's MXP parser, so we could write handlers for MXP tags that MUSHclient doesn't support, then writing a plugin that popped up a new window with the image would be fairly straightforward.

Python has a decent http client in its standard library and the PIL (Python Imaging Library) has a free version and supports the most important image types (jpg/png/gif -- though not gif animation).
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Mon 18 Jun 2007 03:57 AM (UTC)  [ quote  ]

Amended on Mon 18 Jun 2007 04:07 AM (UTC) by Shadowfyr

Message
On an interesting note, I decided to pop into Dr. Dobbs, to see if they had a forum. They do, but I can't get it to work right using IE-Tab *or* Firefox.. However, I did find this:

http://www.ddj.com/dept/cpp/184401825
Edit: http://www.ddj.com/dept/cpp/184401852 <- Second article on it.

Its a GUI library for C++ that allows you to code windows, attach items, etc., **like you do in other languages where is makes facking sense**. There isn't any complicated ATL templates that bloat code, obscure BS from MFC, and it can be used "on top of" either one. It might even provide the event management we need to let us fire script functions when an object does something, maybe. If the added size isn't too bad, it might be interesting to look at. Its got to be smaller than cramming wxlua into the client and still not being sure if it will work right. Its an interesting find, and maybe another piece in the puzzle (or maybe not).
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Mon 18 Jun 2007 03:06 AM (UTC)  [ quote  ]
Message
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.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Mon 18 Jun 2007 02:32 AM (UTC)  [ quote  ]
Message
Quote:

well, would it be hard to supply BASIC levels of image parsing?


Yes, that would be the hard bit. It is not so much parsing the image, but displaying it.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Bobbiac   USA  (3 posts)  [Biography] bio
Date Mon 18 Jun 2007 01:35 AM (UTC)  [ quote  ]

Amended on Mon 18 Jun 2007 01:36 AM (UTC) by Bobbiac

Message
well, would it be hard to supply BASIC levels of image parsing?

that is, to replace some of the ascii art in a mud i frequent, without click-through tags?
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Mon 18 Jun 2007 01:15 AM (UTC)  [ quote  ]
Message
I don't see why we risk a fork. If somebody is willing to make the changes and does them well, and without breaking other things, I think chances are high that their work might get integrated into the main distribution.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Sun 17 Jun 2007 11:29 PM (UTC)  [ quote  ]
Message
As I have tried to indicate, I think it would be an incredible amount of work to make that possible.

However, as it is now open source, someone who is keen to do so, is welcome to make an "image enabled" version.

Admittedly, most of the client wouldn't change. However you would need to alter the way lines are stored (as some lines would really be images and not text), obviously change the way they are displayed, make provision for obtaining the image in the first place, and change the way that it translates a mouse-click in the window to a line in the output buffer.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Bobbiac   USA  (3 posts)  [Biography] bio
Date Sun 17 Jun 2007 10:40 PM (UTC)  [ quote  ]
Message
I understand it would be a lot of work to change MUSHclient to do this. But being "open source" you are risking a fork if enough people want pictures.

Using your Photoshop analogy, they did start out somewhat primitive. However, their consumer base demand evolution and Adobe responded.


Mr. Gammon please don't let your baby run away.
[Go to top] top
Posted by HR-Trevor   USA  (5 posts)  [Biography] bio
Date Wed 21 Dec 2005 11:50 PM (UTC)  [ quote  ]
Message
Thanks for the explanations. I wasn't aware MXP had such underlying problems. I have to say that even just having a window or frame images went to would be nice though.
-- Rich
http://www.haelrahv.com
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Wed 21 Dec 2005 10:56 PM (UTC)  [ quote  ]
Message
Of course, some of those could be avoided by treating an image as having a newline both before and after the image, even when none is explicitly given, but I have to agree. MXP, while it does provide a neat feature that *could* be used well in some cases, its imho actually too limited and is little better than a hack. This is why most people build custom clients to add such graphics. MXP is the Mosaic of MUD protocols, doing some things that do pretty neat tricks with HTML, but its no Firefox, or even an IE, if you get my meaning. For it to be widely used it will require:

1. Clearer specs about what to do in some cases, like when you get and error.
2. Additional and better features.
3. If at all possible, am open source library for *correctly* implimenting those things.

Instead we have a spec that its own developer's client doesn't "quite" follow properly, features that should, but never actually are used, like full colors, and the ones that do get used are used badly, or, in the case of ones like images, only in maybe one tenth of one percent of the muds that exist. Maybe if/when Nick builds a true Linux version it can happen, but even then its probably easier to redo the existing system than try to add code to handle the images, despite how much I wish it did support some of these things.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Wed 21 Dec 2005 10:20 PM (UTC)  [ quote  ]
Message
I hear what you are saying about needing to move with the times. However the problem for me is that it is basically a rewrite of the entire outputting section, which has ramifications through a lot of the code. Banging an inline image in affects things like:


  • Where the cursor is when you click (ie. what word on what line)

  • Highlighting words when you do a find

  • Clicking and dragging the thumb to scroll.

  • Things like "omit from output" - what if the output line you are omitting had an image in it?

  • Trigger highlighting of words in lines.

  • The "info window" that pops up when you hover over a line

  • Caching the images

  • Emptying the cache sometime

  • Drawing different formats

  • Allowing for people who might be using 256 colours

  • Handling malformed images (eg. a GIF image that won't decomprses)


It could be done, especially if I wrote the client again from scratch.

However I'm inclined to think this is a bit of a hybrid solution. If you really want games with images, play an MMORPG - their graphics are fantastic these days. However if you like straight text, well that is the market MUSHclient is addressing.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by HR-Trevor   USA  (5 posts)  [Biography] bio
Date Wed 21 Dec 2005 08:00 PM (UTC)  [ quote  ]
Message
Oh, I wasn't by any means implying it to be easy. I was responding to comments by Nick that interpreted to mean that he wasn't sure inline images had a viable role in the client.

But I will say that even the issue of performance should be carried in great part by world developers. I suppose this is a matter of opinion, but I don't personally see a fast text only interface versus a moderately paced mixed media interface as a reflection on the client used so much as a reflection on the game using them. Certainly there are also measures world designers can take to minimize impact too, including using formats and specifications for images that allows them to be rendered more quickly. I don't think Nick should feel obligated to bear all of that on his shoulders.

I saw a mention of the many image formats, for instance. While it would be nice to support all of those, I think that it's quite reasonable for MUSHclient to only support select common and efficient formats. I wouldn't even bother with BMP's for example, because they're ridiculously huge, if this is a matter of time/dev and we're looking for fat to cut. But then again, going back to my previous statement, if Nick did allow bmp's and world designers opted to use them when other formats may have been more efficient, that's no reflection on MUSHclient nor on Nick, it's a reflection on the world builder.

As it is now, MUSHclient is, in my opinion, the best and most versatile telnet client available - hands down. I've been using it for years. But, I still recognize the viability, and in my opinion, need for image support, and inline image support. But don't mistake my support for trivializing the actual technical aspects of implementation, that's an issue I'm not going to even begin to get involved in.
-- Rich
http://www.haelrahv.com
[Go to top] top

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.

34,589 views.

This is page 1, subject is 7 pages long: 1 2  3  4  5  6  7  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]