MXP Image

Is there any possibility that image will be supported in a future implementation of MUSHClient's support of the MXP protocol? As in, actually displaying images?

I suppose it is possible. MUSHclient is supposed to be a text-based MUD client, and as such, supporting images is a bit off-topic for it.

I have never really agreed with the idea of having inline graphics for a text MUD, it seems to me that whoever invents it really wants a graphical MUD and are trying to slip graphics in "by the back door" so-to-speak.

Personally I've always thought that if used correctly, images could add that extra touch. Not true pictures, but rather little icons e.g. to tell apart weapon types (sword vs. blunt vs. bow etc.)

Also, I'm not sure what's wrong with enhancing the traditional telnet experience. After all, that's what MXP is all about, and MUSHclient is also meant to make it all more enjoyable.

In any case I don't think it's a major issue but it would be nice to have around. Not if it means sacrificing a lot of speed, however. :)

Wanting a 100% graphical MUD, and wanting to be able to simple things like a humanly tolerable non-ascii tileset for an overland map are pretty drastic differences.

Some MUD concepts just work better as images instead of text, and the more clients that support this fact, the better MUDs are as a whole.

Even adding your own character portrait (like a forum avatar) is a nice understated usage of images that in no way diminshes the fact you're playing a MUD.

I hate ZMUD passionately, bug fact is, it's the only client right now that can show my MUDs overland maps in their nicest format.

Do you have any idea how hard it is to cram 115 different terrain types into combinations of ANSI colors and symbols? Even with Mushclients HTML color it leaves the player trying to figure out of if they're looking at jungle green, forest green (and does that symbol mean confierous forest or deciduous forest?), plain green, swamp green, and on and on and on.

The more complex a MUD gets, the more limited ASCII alone gets. Adding Pop-Up menu's and HTML color can only do so much to help that.

To me MXP images make more sense than MSP ever did. At least images are still viewed, as opposed to suddenly making the MUD audible. People mudding via JAWS might disagree with me on this, but I doubt they appreciate sound effects interrupting JAWS any way.

Yeah, such a complex map system is a real good example. However, I also considered what happens with certain complex puzzles. Most puzzles end up being a sort of "find item A, insert in tab B, which opens C, where you find item D, which needs to be...." Can anyone say "Yuck!". After the 43rd time of doing one of these puzzles, especially when you can't tell what the proper syntax is in some cases, it just gets redundant. The only attempt I have seen that 'sort-of' worked involved discs you had to rotate to spell out a word. And that only just barely worked.

Point is, that an image is often not merely worth a thousand words, sometimes those thousand words can't describe what is going on effectively at all, so puzzle designers tend to resort to the same old formula. It is nearly impossible with pure text to do anything else. At least not without it collapsing into an insane guessing game. If they don't make you play "guess the word", then they end up basically handing the answer to you instead. With a picture, you can 'see' if the item is supposed to be twisted, turned, pulled, pushed or whatever. Text just can't manage that without giving the whole game away.

MUSHclient's support of the img tag lets you click on an image and have it opened in your web browser, a program designed to support showing images. Thus, your maps can still be viewable, and you can Alt+Tab back and forwards to see the map when you want to.

Maybe with the new windows that I am currently adding into MUSHclient there could be support for showing images in them.

Well, youre already going to have a background image. So, in certain cases that "background" could be the main purpose of the window. Or used, with text overtop, or whatever other permutations.

Mushclients support for the image tag lets me do squat.

THIS is what an overland map looks like via zmud:

http://www.auricmud.com/images/terrain/twilight-map.html

Updating and changing everytimg a player moves, to show where they are in the map, and others around them.

Row upon row upon row of "click me" does nothing of any use and is simply not comparable.

The only way MUSHclient as is, would be able to do anything is if the MUD output a temporary composite link for the player to the MUDs website, showing an entire map if they clicked on it, and frankly it's not worth the bother or the time it would take both for the MUD to create such an image, or for the player to go through the hassle of loading it. The point over overland is to cover large areas quickly not to have to continually pause and refer to a webpage to figure out where you are.

This subject has been beaten to death for over a year now.

Requiring a secondary application to view something that's IN the MUD is useless. It requires the player to turn their attention away from the client if they want to see what they're being shown. It's not a realistic solution. It's not a useful solution. It's not how the feature was meant to be implemented. Please stop treating it like it has any useful value, or is any way comparable to what it's really supposed to be. It's not even apples and oranges. It's apples and asparagus, and I've heard every excuse you've used and don't really want to hear them again in this thread.

I paid for Mushclient. I encouraged many many others to pay for mushclient. My entire staff uses mushclient. We would like for it to actually support MXP the way it's supposed to, so we're not forced to migrate to the eye-sore that is ZMUD. Bottom line. I want for myself, and for my players, the client that will give them the best, richest MUDding experience.

Speaking as a longtime and very oldschool mudder, what you've done no longer looks like a mud Eos. I understand that what YOU want is full MXP compliance in a client and quite frankly, Nick never claimed full compliance. MXP was created BY Zugg, FOR zMUD. As a courtesy to the rest of the mudding world he released the specs as open source. This in NO WAY mandates every other client support EVERY feature of the protocol. To be perfectly honest, I think you've been rude as fucking hell in coming here demanding Nick implement something specificly to support YOUR mud. There are ways you can accomodate even the most rudimentry client support of MXP if you do the codework to support the features you want.

Ok, ok, Nicks extra windows ARENT another application. Theye other windows that will show an image as a background. Im sure something can be worked out to display a map just like that one IN one of those windows. They WILL be a part of the MC program, just a seperate window. You can read about them...
http://www.gammon.com.au/forum/?bbsubject_id=4286

This discussion has been going on for over a year. Nearly three years. In fact:

"Posted by Nick Gammon Australia (6,206 posts)Date Fri 27 Jun 2003 03:16 PM
Message
I am actually working on the display routines right now, with a view to fixing up some other problems - one being the inability for a script to access the contents of a line that is "omit from output".

I will bear these comments in mind, but at present it is a text client with custom-written output routine, it isn't a simple task to "plug in" a Rich Text control. In any case, they are quite slow.
"

I assure you my MUD is every inch a MUD, and having one feature that looks better graphical than ascii does not change the more than 300 full text areas in it, or the textual aspects of this feature. It's called an enhancement.

At no point have I demanded anything. I've stated facts. The fact is what Nick has for image support, is not useful to me in any way shape or form, and is no different from sending the link to them in the first place. Mushclient has had "go to url" for years, and being able to send clickable ones is really not much of an improvement.

A person asked for this to be added in.
I provided a list of reasons why someone would want this feature, based on my own experience.
Nick as usual leapt forth to proclaim it unneccesary and explain how very useful his own version of it was.
I clarified WHY Nick's implementation was not useful for the purposes I listed.

Rude I was, and am, because I'm sick to death of beating this dead horse since day 1 of MXP being added to mushclient. Three years of seeing the samr argument is bound to make anyone begin to twitch.

As for Flannel, The client windows were not what was being discussed. Nicks: "MUSHclient's support of the img tag lets you click on an image and have it opened in your web browser, a program designed to support showing images. Thus, your maps can still be viewable, and you can Alt+Tab back and forwards to see the map when you want to." is what I was referring to, and it was a very clear 'maybe' following that line about what those new windows will and won't do.

If anyone else feels like sharing their highly enlightened opinion of me, do so via the email address in my bio, not in the forum. The thread should at least try to remain on topic.

Personally since it's come up quite so often, I think Nick should consider a poll of some sort to see what percentage of his userbase really want this feature the fully inline way or at least give some announcement that resolves it one way or another for people. A simple "yes it will be added eventually" or "no, this is a feature I will never support" so that people who can't live without it know to move on.

Looking at that screenshot I can't see the text of the MUD output, the chats, the inventory, the room description or anything. It just looks like a secondary "image" screen.

I'm not a big user of zMUD, for obvious reasons, perhaps it is easier to use that map than is obvious from what you have shown, but it seems to me that it must be in a separate window that you turn your attention to when you want to.

Perhaps I should emphasise on the MUSHclient web page that it is a *text-based* MUD client? In any case, the whole idea of shareware is you download the program, and if you like it you pay for it. You may also request bug fixes or make reasonable suggestions for enhancements.

However, I think the idea of making a text-based client into a graphical client is possibly outside the bounds of "reasonable".



You have to ask yourself, if inline graphics, HTML tables, proportional fonts etc. are so wonderful, how come Pueblo seems to be pretty dead? It is no longer being actively maintained as far as I can see, and I don't know of many servers that attempt to require its use.

Perhaps the idea of trying to combine graphics with a text-based MUD is fundamentally flawed? If not, then Pueblo should have been a great success and all the other clients dwindled into well-deserved oblivion? However that doesn't seem to have happened.

To support inline graphics would be such a major change that I cannot see it being done without a great deal of work, and even then I still can't envisage how it would work properly.

• Say you move around the map, does the image change? So if you scroll back, do you see the earlier maps before the move or where you are now?
  
• Do I support GIF, PNG, JPG, BMP, TIF or what else?
  
• Do graphics get downloaded on demand? From a HTTP proxy server if necessary?
  
• What happens if you select some text with inline images and do a "copy"? Do they end up on the clipboard?
  
• What if the image is too wide for your screen? Does it get resized?
  
• Do we have horizontal scroll bars?
  
• What happens if I get a "bad" GIF image (eg. bad compression)?
  
• What happens if the image isn't where the link says it is?
  
• What happens if the image requires 32-bit colour and you have 256 colours (8-bit colour)?
  
• Do the images get cached? If so, where? What happens if the disk is full?
  

You can see that it isn't a question if "just adding inline images".

To answer your question, MUSHclient is a text-based client, and I do not envisage supporting inline images in the future.

Perhaps when it is rewritten to support Unix, Mac etc.

Maybe.

It just occured to me, since what you have is a bunch of square pictures, the easiest way to support pictures would be to have each line be the same height as the text, this way nicks scroll routines and such would still work. Since thats a large problem is the spacing of a large picture and lines and buffers and crap.

However, it THEN occured to me that since were just making the pictures be the same height as whatever font, you COULD use a special font for "images", for a terrain, it would be easy to make a charset with a "letter" for each terrain. This would be sent from the mud with color, and that would work mighty fine. Without any changes to the bloat of MC.

That is really what this is all about. Nick custom built the output routine, like he said in that post, and he cant "just" add support for pictures without going over a large portion of it, if not all.
Yes, this discussion has been going on and off for however long, but in the past weve deemed it really not nessisariry, and used in such moderation that it wouldnt be worth the bloat and lag.

I begin to suspect some of you have no clue what overland mapping is, and that is half the reason you're not getting what I'm saying, So here is a webpage explaining in the hopes it helps:

http://www.auricmud.com/Sample/overland.html

As can be seen, with image support, comes out much nicer.
Also, as visible, still text based, just has visual references for those who can't mentally orient themselves based on text.

I already tried the font idea. The flaw in that is:

A) Everyone has to have the font (not so hard)
B) Mushclient can only display 1 font at a time (harder to overcome when the map has text as well).

Now if mushclient could handle switching fonts/multiple fonts that would be a viable solution.

the new windows will be able to display multiple fonts. So youll be able to have a "map" window, as well as normal output.

However, Im wondering how the "clear" works, it just scrolls a bunch of lines? Do they set the scroll? or what.

Pity the person who has a slower connection. Especially with the pictures downloading.

But yes, this will be able to be done Id assume in the new windows.

Why hasn't Pueblo taken off? Simple answer - I takes skill that most story writters don't actually have to make graphics that doesn't look totally lame, so it is easier to not bother. This doesn't mean it was a bad idea, just that it is harder to do than producing pure text. Something like Eos' map though is actually easy to do, from the perspective of the mud, since it only replaced single letters with images. There is no need to design a special graphic for every room, just make several dozen small ones and overlay them on the world. This is imho really an iteresting idea, though like you I have no clue how the heck it works in the client with other things happening, unless it uses something similar to the text based games of the old BBS days, where only the 'visible' region was redrawn and then only those letters corresponding to the areas explored. This was quite common.

As for the use of a special font.. That would require actually supporting extra fonts, which is currently not an available option either, but it is quite similar to what appears to be happening with the images in this case. It is also very limited, in that it can only use one color. Oh, and good luck managing to create the font without shelling out a chunk of cash for the software to make it.

To cover your points nick:


I expect that the image changes, but I may be wrong. It is how most muds and the like handled it, only changing the part of the image that actually differed, unless a redraw of the whole thing was actually needed. This saved bandwidth, but is probably less of a concern now than it was before. However, it also means that Mushclient's non-support of positioning codes would kill it too.


Well.. Usually jpg, bmp and gif. Though png is a good idea too. The other formats will never be used anyway, even by other clients. Personally I wouldn't even include bmp, if for no other reason than because only idiots would use an uncompressed format.


If not available in the local cache, then yes they are FTPed on demand. Most sites provide a .zip or the like with most, if not all, of the needed images you can save into the cache to start with though.


Yes, no, maybe... If the client uses the standard and slow RichText control, then this is likely a yes. Imbedded images is part of the RichText controls copy function. Imho, I would have it copy the link, so if posted as HTML it will still display the right image.


Umm. I would say optional. There may be cases where a too big image is intentional, but it is not a good idea to use anything bigger than a few hundred pixels. I doubt most places would exceed a reasonable size, or that people would keep playing if they got hit by a 800x600 image a lot. I don't think anyone would scream to badly if some same limit was placed on it or images that didn't fit got resized.


Probably not necessary.

Mushclient crashes? lol Seriously, if some compressed file types are damaged, or even incorrectly named, then some decompression libraries for them have been known to buffer overflow. A concept I find totally stupid, since you would think they would have put something in to check that the decompression never attempts to exceed the actually data loaded...


Take a page from most browsers and display an image that is sort of indented looking with a red box, with a white x, in it.


Planing to write the entire graphics library for it yourself too? This is something the OS is 'supposed' to deal with. Admittedly it usually does a crappy job at it, but it is supposed to do the conversion itself anyway.


Yes. See above. If the disk gets close to full, you stop caching. However, this is Windows we are talking about here. If the disk space starts to gets that low, the OS will likely crash long before Mushclient needs to worry about telling you it is running out of space. ;) lol But in any case, I wouldn't allow caching to exceed some set size, just like browsers or anything else that caches data. Unless some mud went totally nuts, odds are this wouldn't be a big issue though.

In any case. This is one thing I suspect isn't going to happen anyway, unless someone else comes up with a output system that they can show Nick, which works and does the things Nick insists he just doesn't understand how to make work. Most importantly, one that does it reasonably fast. He would need to drastically rework the existing system anyway and it won't help him *or us* to complain about what it missing, if we have even less clue than he does how to make any of it work.

This is why, when I can, I try to describe how I think things could work in some detail or provide him with links to things that appear able to solve a percieved problem. He is only one person, not an entire staff dedicated to finding ways to add every thing we want. This means that we often get a better product, but it also means he can be obstanant, short sighted or even clueless about how to solve something. I don't see a whole lot of the rest of you actually suggesting actual solutions. If I had one for this, you can be sure I would be posting it.

1) This is up to the MUD. Your program doesn't support screen redrawing anyhow, so I assume most MUDs will find their own answer for that. In my case I use 50 or so linefeeds so the previous information remains in place.
2) BMP and GIF, as per the protocol specifications.
3) Yes, As per the protocol specifications.
4) I'd say no. Really up to you though.
5) I'd reasonably assume yes.
6) Shouldn't be neccessary if screen width is limited by a character limit and images are resized to fit within the available limit (or in the case of multiple images on a single line, wrapped to next line as per text)
7) Standardized image placeholder indicating bad image, Sized and positioned per IMAGE tag specificications if any were passed.
8) See #7
9) You lose image quality. Last I looked that wasn't exactly a crashable bug, and is generally handled by the users display drivers/video card.
10) Yes. I'd recommend caching in worlds/worldname/images/ myself. But then I tend to keep all my worlds in their own directory anyhow, so they don't interfere with each other and I don't have to bother with unique filenames for all their scripts, etc. In the event of disk capacity an erorr message generally would be appropriate, as well as #7 in place of the image.

On most clients a simple: "\x1B[;H\x1B[2J"
Does it, however since mushclient does not support that I use a more drastic combination of that and many \n\r so that all clients come out with the same results.



If done to protocol, the pictures should be installed to begin with. Otherwise the pictures will only download once not every time viewed, and being relatively small tiles are not sufficient to slow even a 28.8 modem.

Speed is something I considered early in my MUD, players are able to set the speed at which the MUD sends them information, any where from 512 bytes per second to 5kbps, aside from the built in pager and the choice between html and non html views.

Hmm. Just looked at the other link. Yep, this is a non-scrolling mud. I.e., it uses, at minimum, the clear command. This has also been hammered to death, mainly due to it being one of those things I mentioned that Nick can't wrap his head around. We need to give him a good old pre-telnet client and point him at something like Land of Devastation. ;) Though where you would find either one...

If I remember right. Anything 'on the screen' is updated in memory by such clients, while they log what changes as it happens. The actual scroll back buffers treated each page as completely seperate events. I.e., it only 'saved' the state of the screen into the scroll back if a) a 'clear screen' command was recieved or b) as each line passed off the 'visible' area. This was generally expected to be 25 lines, since most client couldn't show more than that in the old days. Most non-scroll muds probably still use that standard. But it doesn't matter, since as soon as you got a clear command, it would buffer the current state anyway. The only big issue is keeping track of things that change *on screen* in cases where you are looking at the contents of that back buffer.

Same situation in that case though. The current 'visible' area gets updated (which is to say the current screen, not what the user is looking at), until one of its lines scrolls off that area or it is cleared and the whole thing needs to be shoved into the buffer. This meant that you couldn't watch the buffer to see what or how something happened, but if you reloaded the logged ansi later on, you could literally 'play back' everything as it happened. I am pretty sure existing clients that support those positioning commands do the same thing now. Trying to allow all the changes to play back as you scroll up isn't all that practical or even really preferrable.

Actually it is a scrolling mud.
It just has some sections (account login, profile management, and overland) that are non-scrolling sections.

Just a comment about font software:

http://fontforge.sourceforge.net/
http://doubletype.sourceforge.net/

downloaded them both, played with them a bit, no idea what Im doing yet, so I cant suggest one or the other, there are plenty more on sourceforge, but these are the most active. I just didnt want to have tons of them, many of which are underpar or not useful, or whatever.

So there you go Shadowfyr, maybe youll redo your modterm font now, I remember when you did it you were complaining about something or other.

Edit:
Oh yeah, some of those pages have links to other font utilities, I havent explored much, but theres plenty there to chew on.
It also looks like fontforge is the better of those two, I couldnt get doubletype to do much.

OK, I see from the example page what you are talking about. It is really a map made up of special font characters, not a GIF image as such.

And, I presume, it needs to be in its own non-scrolling window with the text underneath, so you see in the map where you are, and the rest of the text (chats etc.) scroll by underneath.

MUSHclient doesn't currently support different "panes" (non-scrolling map, with scrolling text underneath). You could probably write a standalone window in VB, like Poromenos has done for his extra windows. Then using a trigger you could capture the map data and send it to the extra window.

It isn't a 'pane' Nick. The mud, as near as I can tell from the description does what I described about the clear screen command. It blanks the existing page of text, then redisplays a new one, with the updated text and images. In this case, each 'page' would get saved in the buffer in the clients that support them. In the old days of BBS systems, such games would save bandwidth by repositioning the cursor and changing one character. The buffer space kept the last 'state' of the display, but each change would be saved into any ansi log file. So, if you page-up, it would show the last 'page' in the final state in had, just *before* the clear screen command.

This is what his does in a way. The difference is that badwidth is not as critical for telnet, so it clears the entire screen (which a client would then save in that state in the buffer), then redraws everything, including the text underneath. It simply places a graphical map into the window, instead of printing the ordinary text that is usually there. It doesn't use any sort of panes, windows, etc., just a direct replacement of the text with the small images. The scrolling happens only in the sense that all of this 'scrolls' off the screen if a lot of things happen before the player moves from the room and causes the entire screen to redraw.

Understand now?

Shadowfyr, Eos said (see above) it "has some sections ... that are non-scrolling". Since he is talking about the "overland" part (the map), I take it, that he is talking about a non-scrolling section (pane) that is the map.

I understand about cursor addressing and telnet apps, I used to use "dumb" terminals that didn't scroll at all, you could only address 80 X 24 characters.

However from the screen shot on the link above, it seems to me he is describing a separate map section (pane) that doesn't scroll, and draws a map in a different font.

I think he was talking about there are parts of the MUD that arent scrolling, not the map.

The only scrolling sections are those three, Id assume things like chatting arent scrolling and such, I think thats what he was talking about.

But that is in a way scrolling, he redraws a scrolled picture every time, on MC, and Z. So, every time someone moves, the mud sends:
(a zillion blank lines) /*This is instead of a CLS*/
(a map with the current position of everything)
(Your little description thing)
(your stats)
He WANTS to be able to send a bunch of pictures, instead of the map. (basically a picture for letter conversion, which if he could get different fonts, he could do with a custom font. Perhaps he could write his own font with special characters being the map. Anyway, with the new windows, he can switch fonts, yes? So, that WILL work with what he wants to do, the person just needs to catch that, and throw it to the window in the "land" font.

He also wants a CLS, which is what shadowfyr has been talking about with buffers and such, which would save the need for a million lines. However, I think the new windows will work better from a users perspective, since theyll be able to have the writing underneath the map in the map window, or still on the world window with the map up in a corner, or whatever, and they can omit a bunch of the newlines, and plenty of other configurability.

Point being, the new windows and a custom font is all he needs.

Also, the different font, is in Zmud I assume, he "wants" it in MC, but the new windows will handle that. And the non scroll thing, isnt true, because you can see the line info (mouse over) with the fourth version, about a quarter of the way down the screen. And I think the symbols on that screen are photoshopped, or else he'd be able to do what he wanted already.

Itd be nice to see what its "supposed" to look like in Zmud. Or what it looks like in Zmud, or whatever. So we do infact know what hes asking for.

Yeah, let's see the whole enchilada, not just bits of it.

No Nick, Shadowfyr is 100% correct and you are the one over complicating and confusing things.

This is a feature I and several muds have had for months/years. How on earth could be doing this if it required your theoretical non-existant panes?

Our login menu is non scrolling.
Our areas work exactly like any other MUD. You walk around in them. You read. Entirely non visual.

Overland is purely connective. Think world maps in final fantasy games, or any other RPG, where you exit a town/dungeon and you're on a map. Thats overland.

When you leave the overland entering a town/city/tower/dungeon/area in general you go back to standard mudding.

Overland is non scrolling.
Standard MUD is scrolling.

Therefore my MUD does both.

Things stop scrolling when you go overland. Things resume scrolling when you go back into a real area.

Overland itself is nothing more than interactive virtual rooms connecting real areas.

A custom font doesn't really fix it, since a) it is a whole heck of a lot easier to make pictures than making a font. Believe me, the FON are merely bitmaps and are a major pain, I don't even want to think about the stuff you can screw up developing a .TTF font... Also, his example shows several cases which are not simple colored images on a color background. In fact, a few use multiple colors in the individual pictures.

I do still think Nick is partly missing my point. He says that he previously used fixed sized clients for telnet that had text positioning. However, I used one called Telemate, which you can still find if you look really hard. It was the Mushclient of BBS clients, having support for scripting, full ansi logging, zmodem file transfer *and* a back buffer that works exactly like Mushclient's, with 5000+ lines, or whatever your memory could handle. However, it worked with *both* scrolling content and paged content, by buffering lines that scrolled of *or* 'freezing' the last known state of a page, then storing that in the buffer. Page-up and page-down actually jumped to the start or end of the 'current' page, then directly to the top or bottom of the 'next' page when pressed again. It worked extremely well and handled both types of content.

There is no need for a scrolling and static client to be mutually exclusive. The whole buffer issue was solved before with a lot of clients. Trying to keep track of every tiny little change and back into or out of them is way overthinking the needed function of the buffer.

the worlds ARE scrolling thought, they just scroll in larger chunks. THAT is what is confusing him. While in overland mode, you scroll at 100 lines, or whatever, at a time, yes?

<off topic>
Also, shadowfyr, (this is completely off topic) you have any sort of scripting client for messaging stuff? I want to be able to have MC-like ability for my messages stuff, putting up messages with triggers, setting away at times, and such. Go ahead and email me if its an affirmative, if its not, ignore this completely.
</off topic>

WRQ Reflection does the same things.
http://techlibrary.wallstreetandtech.com/data/detail?id=1063999758_819&type=RES&src=TOPRES

As for Nick


http://www.auricmud.com/Sample/overland.gif

Yes, that is basically what he does, 'because' Mushclient lacks the clear command support. If it did, then the visible text would get shoved into the buffer and Mushclient would start displaying new lines on a blank page, starting at the top down, as though you had just reconnected. Sending a mess of lines to 'simulate' this is a cheat and isn't technically right, since it doesn't start the new 'page' at the top of the display area, as the real command does.

A bit of trivia, the original 'clear' command on some machines, like the Apple II actually cleared the screen by executing a series of memory shifts. the last 80 characters in the video memory where always 0s, so by executing a special 'pagefeed', which scrolled the entire content 25 times, it cleared the screen. You would then execute a clear, which really only moved the cursor to the top left. In effect, the Apple II systems did what a primitive telnet client would likely do. lol

We were talking about on Zmud. And he meant screen shots with the "whole enchilada" bit, as opposed to just the world output bit.

And also, in that one, when youre mapping, your mud sends a bunch of newlines? or no? On MC You send a lot, what about Zmud.

Im just trying to get a sense of what youre trying to get, in Zmud, and how we can possibly work around in MC.

In all fairness, keep in mind I do both a clear, and a mass-linefeed, so it pushes all clients to the same place, just in a more unpleasant manner for those that ignore the clear directive.

I've been very clear what I want.
I want inline image support, so that every visible coordinate of an overland map can be displayed as an actual image.

Does it not bother you, Eos, that to add in-line image support would basically be a complete rewrite of the output system (if not more)?

The problem here isn't one of usefulness; the problem here is that you guys are asking Nick to invest a truly huge amount of time for something that is probably just as infrequent.

Also, some technical corrections:
- BMPs can be compressed (e.g. RLE)
- the only reason it's useful to have the client set the speed is because the SMAUG networking code is... well... crap. It will loop endlessly until the buffer is written, which obviously on a slow connection means that the MUD hangs. The reason that modern games let you set the connection is to limit the information they send you so that you only get the essentials - not to adjust the speed at which it is sent.


Since you used the term "standard mudding" you are basically admitting that what you are doing is not standard. You've made half (or a portion, whatever) of your game non-text - graphical.

Regardless, given how much Nick charges for MUSHclient, given how relatively few people register it compared to how many use it, given that he doesn't charge for any upgrades (major or minor), given the generosity of free support, given the generosity of the endless trial, given all the rest; to be honest if I were Nick I wouldn't really even want to spend the time on such a large project so that such a small group could see images in a text game.

Yeah, I definitely think it would be neat to have them. And to be frank I've wanted them for a map as well (though not a non-scrolling thing like you have.) I already gave an example that I think would be very neat, like little weapon icons. That being said, I don't want it enough to give Nick shit about it. If it'd be hard to do - and I know that it is certainly not trivial - and since it's not a common feature (you basically admitted this yourself) it doesn't even make business sense to make this change.

Basically you're asking for a different product and not really an extension to a product. Would you be willing to pay for a new version of MUSHclient that had image support? Perhaps that would be motivation for Nick to spend so much time working on it.

From that GIF, it seems you are not talking about inline images (like pictures of dragons) but a font-based "map" of the ground. And, I gather, you want a different font than is used for text.

Putting aside the "screen clear" issue, which you seem prepared to work around by sending linefeeds, basically you just want the ability to change fonts? Is that it? Or is there more to that image than meets the eye?

I have used Reflection in the past, I understand it supports full-screen addressing. It is not a MUD client, it is a telnet client. They aren't the same thing you know. If Reflection is so good, why not use it?

No. Fonts have nothing to do with this, regardless of what Flannel keeps insisting. A font is a single character in a single color, with a background color, which I already have and in no way shape or form is an improvement on what I have.

Do you remember this page?
http://www.auricmud.com/images/terrain/twilight-map.html

I want to be able to do that, with inline images, in my MUD.

Instead of each cell of the map being represented by an ugly garish ascii character (regardless of font) in an ugly single background/foreground color scheme, I want to be able to use an actual gif, for each tile of the map (The real tiles are a bit smaller than on that page though, it was enlarged for the website sample).

Hence the term, tileset, as used on page 1 of this thread.

You've already said you have no interest in making this possible, so the point is moot, though it would be nice if you understood now as Shadowfyr seems to.

Oh, I see. That image was not a single image but a tiled collection of hundreds of small images, one for each piece of the terrain.

I do not plan to allow lots of inline images, as I said, however it probably is not too big a stretch for someone to make a COM object that would do it on a side screen.

Yes.



Already tried a similar route.

It just does not work as well because it's in a separate window. It's like driving in reverse without a rear view mirror; you have to constantly turn and look at the other window to see where you are.

Best compromise was making the additional window always on top floating in the far right away from where the MUD itself is, but because the player is not always on the map it comes down to them having to minimize/restore the map window everytime they exit/reenter a map.

Since you seem to be the only one who cares passionately about this over the three year period, perhaps you should consider writing your own client that uniquely addresses your needs? Your mud sounds very interesting and innovative. You should not be surprised when clients don't hop onto the bleeding edge with you.



So, you can be as rude as you like in public, and no one should call you on it? I don't think so. In general, this forum is congenial. There are a few condescending people, but your posts in this thread really take the cake. I applaud Nick for being able to ignore your condescension and outright rudeness. If I got an RFE like yours on one of my projects, it would go immediately to the circular file.

I agree with Ksilyan:



Except that, since you're asking for Nick to join you on the bleeding edge where very few mudders go...it would make more sense for you to fund development than have to buy a new copy of the software.

Dub

Bleeding edge...? Lol Muds have not changed significantly since back when you dialed a single computer using a 1200baud modem and the most exciting game around was Food Fight. Numerous attempts have been made over the years to improve this, from custom clients for Lands of Devistation that could display images of the mutants you got attacked by, to using something like the DOS Basic's PLAY command to generate sound and music. There was even a RLE encoding graphics method used to show simple images. This is hardly bleeding edge. Unsupported, because it is easier to make a simple client that ignores certain possible features, than one that is does support them, but hardly bleeding edge...

However, since sanity, both with images and 'correct' support of text positioning isn't going to win out... (would be nice at least to see the later fixed, since it is actually more common.) Here is an idea Eos. How about an option specific to Mushclient?

Make a plugin that uses several special triggers and a overlay window. The overlay window would use the getframe command and some simple code to return the Musclient window size. It would be a frameless window, that simply floats (always on top) over the output area in Mushclient. (You may need to look at the 'child' windows of the one you get from getframe to find the right size.) When you need it, you display it, when you don't, you minimize it.

As for the triggers.. You would need to send out something that Mushclient will trigger on, like [map-on] to display it, [map-off] to hide it and then maybe a [map-data (width, height): data] for what you are going to show. All the normal text will still scroll, but the map will appear in this window. Its not a great solution, but it is better than trying to parse the text map and rebuild the correct image.

Of course.. You may also be able to intercept the MXP tags for those images and pass on the info to the window, then cancel processing of the tag. This would have the effect in Mushclient's output of making the map (and the million links) not appear, while displaying the map in the window. The major trick is just setting it up to position itself, and hide/show as you need it.

Note.. The child window you need has a class name of AfxFrameOrView42s. It is the child of the main frame like so:


The trick is to allow just enough lines visible 'below' your phantom map window for it to still display the text underneath correctly. Though.. You may need to add something to look at the font size and 'guess' the right number of pixels to shorten it to fit. Anyway, it is an idea... You could always cheat, grabbing the device context for the output window and directly writing graphics into it, but that wouldn't probably work too well. lol

You said that you had made a COM program that displayed the MUD but the user had to minimize/restore it all the time. Couldn't the program detect when the user entered/left the dungeon and get minimized/restored on its own?

Yep. Thats what shadowfyr was saying. Or maybe not minimize, but you could at least toggle always on top or not.

Not sure what good that would do Flannel. The idea is to avoid having to switch between them. In fact, I would use 'always-on-top' *and* set it so if you click on the map it automatically returns focus to Mushclient. That way you could even impliment the newer 'image map' function that zMud apparently supports in such an image. Click on it and it sends the coordinates, but immediately passes control for user input back to the client.

Its a smaller window, you wouldnt need to switch between them. It would pop up when it got something from the mud, and go away after it got something else.

At least, thats what I got out of it. Still, another application would work. Thats the important part.

What I meant it turning off the always-on-top does not change which window is 'on top', it only determines 'if' a window will appear over or under others. You could give it a command to force it to always be 'under' the others, but that is what the desktop uses, so the behaviour would be unpredictable. It is better to completely hide/unhide it as needed.

The problem with MXP and its frames is that (to the extent that it works in zMUD, which I don't know) zMUD supports frames within the main window anyway, so it wasn't too hard to add it to the MXP spec (for him - Zugg, that is). Basically he added into MXP support for something his client already did.

However for me to support the MXP frames idea would be a major rewrite in MUSHclient.

It is interesting to see a similar discussion in the ZuggSoft forum. I quote in brief from a posting from Zugg here, I hope he doesn't mind ...



Note he acknowledges that images are very hard to implement in a text-only client. When I designed MUSHclient it was intended as a text client. I don't know about the "good design framework" bit, I suppose if I had allowed for images earlier it would be easier to change now.

To give an analogy, when Photoshop was first released, it was designed to process graphics. For a long time its text support was pretty rudimentary (you typed text into a separate dialog box).

It's the same general idea. When I sat down to design a text MUD client, I don't expect to be supporting sound, inline images, web browsing etc.

With the benefit of hindsight, and newly released standards (things that didn't exist to my knowledge in 1995 when I started) like MCCP, MXP, MSP, scripting, and so on, I would design from scratch differently.

Look, I think the overland map idea is nice, and I was thinking if I ever did another client I would look at things like status bar panes, map panes, inventories, separate chat windows etc.

However backwards fitting stuff like that, and still supporting existing users (scripts etc.) can be a heck of a lot of work. You know that builders charge more to add a room to an existing house, than to build the same room in a new one? It is the same idea, you are working around existing infrastructure.

I am sorry MUSHclient doesn't meet your needs, Eos. The idea of shareware is to pay for it *after* you have found that it is what you want, so I presume you do not believe you have been misled in that respect.

I am starting to form the opinion that *no* client does what you want. I gather zMUD won't work for you? You also mentioned WRQ Reflection and Telemate, so it seems that none of them are quite right for you, or you wouldn't be posting here?



I'm starting to see why I got so confused. First you say multiple fonts would be "a viable solution" and then when I attempted to confirm that giving you multiple fonts is what you want you reply that "fonts have nothing to do with this".

I'm sorry, you have lost me here. Fonts are a viable solution, but have nothing to do with it?

No wonder I can't get my head around what you want.

I'm curious to know what is so wrong with zMUD? After all, Zugg says he has a "good design framework".

I'm pleased you prefer MUSHclient to zMUD, but have you considered that there is a danger that adding in these extra features introduces the very problems (whatever they are) that you have with zMUD in the first place?

Probably the same thing that has always been wrong with zMud. A lot more bugs then we ever see here and being insanely slow. lol

In any case, I don't remember Eos saying fonts where a viable option. I may have commented on that, as did the person who originally suggested it could be, but Eos never did that I remember.

I tend to agree though. Eventually freezing this client once it has 99.9% of the features, then doing a complete redesign that does take into account the sorts of stuff that people are starting to use may be nice to see in the future. Especially before someone else beats you to it. lol Frankly I have been slightly tempted myself, then I broke out the C++ book, thumbed through the pages and thought, "bah... let someone else figure it out." ;)

First message in page 2 of this thread.

Perhaps the "good design framework" that permits inline images makes it slow?

It was viable. Until actually tested. Then it was just the same repulsive thing as it already was. At best its a poor compromise between what exists and what I want.

Regardless of intentions, mushclient does not support images. Will you remove/modify the support tags claim that it does, so that a server actually has some way of identifying this fact?

Responding +image/+img indicates support, not workarounds and servers should not need to be bandaided with checks like "if supports( images) && user->client != mushclient" before sending an image. (or in my case 300 images)

This is particularly important considering your links don't use the right syntax:
As per protocol specs:
A 20000: ( 4939) MXP element: <Image fname="test.bmp" url="http://www.auricmud.com/" align=bottom>
Output in MC comes out as:
[http://www.auricmud.com/]

Formatted against specs:
A 20000: ( 4940) MXP element: <Image fname="test.bmp" url="http://www.auricmud.com/test.bmp">
Output in MC comes out as:
[http://www.auricmud.com/test.bmp]

So mushclient agrees it can view images then displays nothing but a hyperlink to the root directory of the image.

Unless of course you add in another bandaid sending the URL in a different format specifically for MC.

(your own example from post: http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=2424 comes out wrong if sent from the mud)

Ah OK, that sounds like a bug. Funny no-one noticed.

The spec says:

URL:

The URL of the path for the graphic if it should be downloaded on the fly.

For me the term URL means "the thing you type into your web browser" which in the case of a graphic usually includes its file name.

However the spec goes on to say "The classname is appended to the URL, along with the name of the graphics file itself.".

I missed that bit, and will fix it.

Well for one thing I doubt anyone else is nearly as obsessive compulsive (or anal retentive, depending on view point) as I am about this particular feature. Or pretty much anything else.

Its not funny, it just demonstrates how few people (servers, whatever) use inline images. Since if anyone really did use it, it wouldve gotten picked up quickly, Im sure.

And exactly how *would* anyone who wanted to use it have done so when the entire point of this thread is that only one client on the face of the earth supports it right now?

In order for supply and demand to function properly there has to be a supply to demand to, otherwise demand itself is an invalid reference point.

This ranks with telling the wright brothers how obvious it is noone wanted airplanes invented because noone had bought any before they were invented.

Yes, I can take that out. It supports the <image> tag in the sense that it recognises it and does something (albeit buggy at the moment) with it, that the user can use to see the image.

I tested that on a PennMUSH implementation, I think, and indeed saw the local "map of the world", so they must have formatted the URL *with* the filename in it. Shows that not everyone reads the spec.

Sounds like your overland maps are going to be supported by exactly one client, zMUD, which you "hate passionately", still, that's life I suppose.

---

I have changed MUSHclient to not claim support for the <image> tag, and to append the fname argument, as you suggested. This will be in version 3.51.

BTW, I see from the MXP spec page the following:


Optional Tags

• MSP Compatibility <SOUND> <MUSIC>
• Using Entities <GAUGE> <STAT>
• Frames <FRAME>
• Cursor Control <DEST>
• Cross-linking Multiple MUD Servers <RELOCATE> <USER>
• <PASSWORD>
• Images <IMAGE>
• File Filters <FILTER>

So, MUSHclient's limited support for inline images is entirely consistent with the spec. It is optional.

is 3.51 also going to support the new windows?

Just a thought, but if youre writing a completely new thing for the new window (which you may or may not be doing), you COULD (although Ive no idea if youre going to want to, or whatever) include inline images.

Not that Im holding my breath, but it is an area which hasnt been coded yet (which, it might or mightnt have) which you could (in theory) code in inline images.

Ive no idea how it would actually work, but its a thought, and only a thought.


Edit:
Now that I think about it more, If the new things include a background image, then you could write a small script to mesh together the images (locally) and make that the background image. It would be a viable workaround. Even without the inline images.

It is largely coded, however I have an issue with sending data to it. It is more complicated than it looks, simply because there is no standard way of imbedding colour information into text.

I can copy the text across (from the main window), retaining colours, which is working, but how do I do something like this:

Match: * goes *
Send: You see %1 going %2

What colour is "You see" and "going" in? They aren't coloured (in the output window) they are in the trigger "send" box only. Or, if you are sending to script, where does the colour information end up (ie. the colour of wildcards 1 and 2)? In fact they may even change inside the wildcard.

As for imbedding images in the secondary windows, more issues arise there. There is still the display problem, which file types to support, how does copy and paste work, where do the images come from in the first place, and so on.

What about the background image? (as per my edit), with text overtop. Obviously the filetypes problem is still there, but not the copy paste one.

As for colors, Itd be ... natural, or something, to use ANSI colors. That would be easy enough to color something yourself. The only problem comes when youre trying to keep color info from the mud. But, we already have a routine to add ansi colors to things, so that would be, or I would think it would be a natural progression.

Then again, that would limit the ability to color, so perhaps a RGB coloration (like colornotes, et al). Or perhaps both?

The benefits of the first is its simpler, and the mud already uses it, so it would be easier (?) to send to from that output.
The benefits of the second is that there are more colors.
So perhaps it would use the second, but accept (and convert?) the former.
Probably using the same ANSI colors as MC is set to. Which would allow you to pipe output from the mud, and have it look exactly like it does in the mud.

I would expect it to work like sending to output, i.e. if you send something to it from a trigger it would be colorless, unless you use ColourNote/ColourTell... Of course maybe you could have an option to preserve the colours?

I'm aware it's optional. The keyword however, is inline. Your support tag says "yes i support inline images" when asked. external hyperlink != inline image. That was my point. It being optional doesn't change the fact mushclient was incorrectly saying it did it.

Hmm. A comment on the test you ran on the image tag Nick.. It is possible that zMud, due precisely to the inconcistency of how some people impliment the spec, may in fact now check to see if the URL is a complete link. If it contains a full link, including a file name with extension, it may simply use that, instead of appending anything to it. I assume the link from that mud did work in zMud or it wouldn't have still been that way, so this is probably how zMud actually handles matters.

As for the rest.. Sigh.. Guess I am going to have to design a plugin and window like I suggested, since no one else seems inclined to even consider it... Not that it will help in this case, since if Muchclient now says "no I don't do images", most muds won't provide an option to force them to be sent anyway. Basically, if they don't work as intended in the first place, they won't work at all, which has the side effect of completely disabling any and all methods that we might come up with to get around it. I personally don't want to see the feature removed, but I also don't see how it can work in any way at all if the client reports non-complience.

Sigh. It partly did it, so I claimed support for it. I have removed that claim. By "partly" I mean it recognised the tag and gave a way for the player to view an image.



I think I tested it with a Pueblo server, not an MXP server, as one of the PennMUSH implementations sent images, which gave me an easy test. However under Pueblo it uses 'src="blah"' which may be the full url, whereas under MXP it seems I have to concatenate the url and the fname.



The feature has not been removed, the claimed support for it has. Can't please everyone I guess. Thus, the <image> tag will be processed as before (with the fname at the end) however if you do <support> then it will not claim to support the <image> tag. Eos has a point, it is not fully supported.

Yes. I understand the distinction Nick. What I mean is that if a mud does a <support>, then it will now incorrectly say it is not supported at all, so even if a link would have been usable, the tags will never be sent in the first place, thus no link. This is almost exactly the same result as removing the feature completely. Was just pointing that out.

Actually I doubt most places will even bother to check whether or not the client claims support for images before they try to send images.

For most of my images it doesn't really matter.

Now for things where you HAVE to be able to see them to interact with the MUD such as tileset maps, it's essential to have the client admit it can't really see them.

For piddly little things like bios or whatever, not many will care enough to verify.

Sure, I understand. There isn't a feature for "partially implemented".

If I was writing a server, and this mattered to me, I would check the client type. I know Dawn Of Time does this, because he customises the output for the client, knowing the client's idiosyncrasies. Perhaps not perfect, but probably works OK.

I check the client type too (think I made the first publically available smaug snippet for it too http://www.auricmud.com/snippets/client-code.html), but it makes things a lot nicer to not have to do client specific formatting like that.

Rows upon rows of exceptions based on every possible clients ways of doing various are not a pretty thought.

Ok.. there's a whole ton of posts about it, but to save myself the time of reading through every single post...

Can someone tell me exactly what the syntax is for my moo to display an image using a URL?

I'm trying to code my moo to work with plain text clients, zmud, pueblo, and mushclient. Mostly I want to use the pueblo extensions with all clients that support the pueblo and mxp protocols.

Thanks,

Skeetre

http://mudz.org:6970
telnet://mudz.org:6969

I think it is the same as HTML:

<img src="http://someserver/somedirectory/somepicture.gif">

That works in MUSHclient, and I use the word "works" in the sense that it puts a hyperlink to the image in the output window, and if the player wants to see it, they click on it.

\x03Image fname="sample.gif" url="http://www.yoururl.com" align=bottom\x04

For the record, Pueblo will also do images. But the author releases on his own schedule. Note however that Pueblo is completely free - Mushclient is not. I am not a fan of Zmud because I think if it came to buying Zmud or playing my mud, I'd lose some players, and it has to come to that with Zmud's license.

I would love to see images in Mushclient, it is nice to be able to examine stuff and see a real image, or for icons for weapons and monsters. Each object on my mud has an icon, either a generic one or one specific to it.

I would also love to have some sort of background image (or image that can be overlapped with text) so that the room's layout can be seen as well as described. If the background image was in a seperate window then it would limit the effort that Mushclient has to put into it (I'm saying it'll be faster).

None of this really works that well with a clickable link,
though for a map perhaps it would work out all right.

I have managed some of this thru a browser interface, but it seems like riding a bull - it goes where it wants, changes when it wants, leaving you to fix the code.

For anybody who wants graphics, that is fine, please don't add them --- I like it when the new users come to my mud because it has graphics. For everyone else though, the world moves on.

Nick,

Images, at least with the Pueblo spec, are not as hard to implement as you might think. (it was one of the failings of Pueblo - loose control on the images. But it's biggest failing was to expect people to buy it - those people make their own graphic client for most control).

I am just brainstorming here, it might not match anything of what you are doing (but I have seen some simple clients that work this way).

First you get a good library for http connections, or you can write one. Find a good graphics library because writing one is an exercise in futility. It will determine which format you support (maybe snoop Pueblo's code and see what he is using - it does PNG).

When you do the http connection, if it fails (file not found, it's huge, it's not in a format you like) - you substitute a broken image icon, and make an entry in the MXP log. So you have an image, even if you don't.

If a size is defined, then reserve that space - this is where it might be hard, but usually you have to boil it down to pixels and that is what an image is. There are only three possibilities - left side of the screen at the cursor position, right of it, and center. Left means anything already there gets shoved to the right of the reserved space. Right means anything in the way gets booted to the next line. Center is a mix of those (I never use it anyway).

If the image was padding with the space a character occupies it would still be acceptable for most cases I am sure. Then you just make your text redraw routine not draw anything when it sees a special character in the text array (for example), and the image drawing is done after.

The only thing complicated is when the image size is not specified (caveat mud implementor!). However, depending on how the graphics routine is written, it may possible to just repeat the above bumping everything out of the way and then redraw.

I may yet have to put my money where my mouth is because I am thinking of writing a small Java text and graphic applet.
Are you interested?

Caching on disk can be done later. Run out of disk space? User dialog, don't write it. Heck, do like Windows and crash :P

So.. In other words Pueblo (and probably others) cheats and doesn't really do 'inline', which would imply text wrapped around the image, not just adjusted a bit for it... Makes things easier, though it would still require Nick redesigning his custom output window to work, so it isn't exactly easy.

We are up to page 6 of this thread, so I won't rehash most of the old arguments.

Basically, images may be easy to display per se if you have the appropriate snippet or code from somewhere, but my point is that the design of MUSHclient, as a text-only client, does not lend itself to easily incorporating images inline.

It would be a fundamental change to, say, how it calculates what line the mouse is on if you click somewhere, if there is not a direct relationship between pixels on the screen and lines. At present there is, say each line is 10 pixels high, you can easily work out what line is what.

I'd just like to say that with all due respect, resisting adding support for inline images is not a healthy thing for MUSHclient. I am sure that printers who believed books without pictures were purer made their job easier, and yes, it certainly allowed them time to devote to other aspects of text printing. But the truth is, versatility is key and just as a printer has a happier and wider client base if they are willing and capable of printing images alongside text, so would MUSHclient.

Having inline pictures doesn't detract from a text based game than having pictures in a book does. It's a matter of how the pictures are used, how often, how well placed and timed. In fact, this whole matter of "pure text" is really out of the scope of design as a whole. You wouldn't regulate MUSHclient by saying red is gaudy so the client won't display that color. You don't limit it from displaying certain font types or sizes. That's for the user (and in this case, the world creator) to decide.

I realize the bottom line here is, "Is adding pictures to a client that's been text-only from the start worth it?" but I think it should be looked as natural evolution and whether or not you choose to resist that evolution. A lot of things are being done in text games that weren't done in days past. More and more images, sound, context menus, specialty guages and controls -- just look at the emergence of XML based client applications for instance.

I can certainly respect if you, the author, feel it's not worth the time, but I can also say that it most definitely limits just how desirable and versatile MUSHclient is and can be to choose to exclude inline images. This isn't a very finite, specific request, this is a broad capability that could have a number of uses on many games worldwide.

Regards,

No HR-Trevor, the **main** issue is how to successfully impliment it at all, given the custom desing of Nick's existing output system, without sacrificing speed and the existing functionality. Images require extra processing, tests to make sure you don't get buffer over flows, adding in true HTTP support, or at least functional code to download with, which for many of us does equal lag anyway. Placing the code in a seperate thread doesn't help that last issue, since additional text can't be shown until the image loads anyway. Its not a simple case of, "Plug this in, and it will work." Or if it was that simple, someone would need to give a concrete example of it in code, so Nick could *see* how to do it without the above problems.

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.

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.

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.

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.

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.

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.

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.

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?

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

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:



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.

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

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

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.

do somebody made this plugin?..

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.