Re: Pueblo's inline images

Is there a particular reason you do not wish to support inline images?

It feels a bit disingenuous to say you support Pueblo, only to then pick and choose which parts you wish to support. This is only an opinion, however.

Damn XP and it's Pueblo-killing ways!

As I understand it this is an issue with the way the output window works. i.e. the type of window is much different for mere color display and the inclusion of inline images. The same for fonts. The issues involved are:

1. Being able to correctly calculate the line to move to using the scroll bar.
2. Correctly positioning such lines in the window with different sized pics and fonts.
3. Speed
4. Speed
5. Others I may not be aware of.

The problem is to support such you need to either code something that handles all this correctly or use an existing control like the RichText control, which is notoriously slow. For reasons of speed and complexity Nick chose to postpone support for the relatively minor things like Font types/sizes and inline images until most of the other things that are used by everyone where working right. As to when these things will become available.. I'll let him answer. ;)

Perfectly reasonable answer. Thanks! As long as Nick [i]ever[/i] hopes to code in support for inline images, and hopefully, Pueblo-like pop-up windows, then I don't need to re-invent a better wheel. ;D

Shadowfyr has answered pretty accurately. RichEdit windows are nice and pretty but slow down considerably even on smallish amounts of data, particularly images. I remember Word used to be a dog when it had imbedded images. Maybe it still is. :)

I hope I said somewhere that the support is for "Pueblo MUDs" rather than "full Pueblo support" which I never attempted to do. There are other things that Pueblo does like inline forms that I have not attempted. The full Pueblo tries to turn a MUD into some sort of web browser, which I personally think is taking the concept of text-based MUDs a bit far.

The partial support of images in MUSHclient at present is intended that if, say, an important map is presented, then at least you can view it, and - handily - move it out of the way to keep viewing it.

Ah. Could you mention somewhere on the main MUSHClient webpage, then, that you never intend to fully support all or even most of Pueblo's more "exotic" functions? I originally paid for MUSHClient thinking one day you'd support everything Pueblo does and now feel a bit misled.

I know you didn't intentionally mislead anyone, but it'd be a good idea.

The main MUSHclient web page (http://www.gammon.com.au/mushclient/mushclient.htm) does not now mention the word "Pueblo" at all. It was fairly recently revamped to make it clearer and easier to read.

The earlier version said "Supports Pueblo-enabled servers (partially).". This was a pretty clear indication that there was not full Pueblo support.

The Pueblo support was never intended to be a big feature. What it does do is support most of the MXP protocol, and after I did that a couple of users wrote saying that I may as well do Pueblo as well as they were similar. So, to the extent that it was easy to interpret Pueblo codes using much the same code as the MXP codes, I did so. The release notes for version 3.11 mention "Added some support for Pueblo-enabled worlds (versions 1.0 and 1.10).". Looking through the release notes this is about the only mention Pueblo gets, apart from some bug fixes.

So, it is now a bit of a hidden feature. It isn't mentioned in the main web page, and is provided as partial support. Some MUSHes use Pueblo and MUSHclient works reasonably well with them.

Hi folks...

I'm new to these forums, and only just recently registered MUSHclient.

I have to admit that being able to display images could be neat - really, really neat. Sure, it might break with the classic text-based adventure, but having little sword and armor icons next to the items in the equipment list could be a nice little touch.

I understand the speed issues, and to be honest have never much liked the RichText control either. I'm wondering, though, how hard it would be to give the user a choice between the current text display - without images and variable font sizes, but fast - and a RichText control - with images and fonts, but slower. I'm not sure how MUSHclient was designed and it's actually very probably that since it was never meant to have TWO displays, this sort of thing might be really hard... but, in the slim chance that it's not that hard to do, could this be an option? While waiting for a faster solution, using the display you have now (and addressing the issues that Shadowfyr mentioned above.)

In any case, MUSHclient is great, I love it. Keep up the good work! :)

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.