MUSHclient : MXP and Pueblo : MXP Image

Gammon Software Solutions forum

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

Entire forum
MUSHclient
MXP and Pueblo
MXP Image

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

MXP Image

Reply to this subject Start a new subject Refresh page

Pages: 1 2 3 4 5 6 7

Posted by

Flannel USA (1,230 posts)

Date

Reply #60 on Thu 17 Jun 2004 04:36 AM (UTC) [ quote ]

Amended on Thu 17 Jun 2004 04:37 AM (UTC) by Flannel

Message

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.

~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Reply #61 on Thu 17 Jun 2004 05:00 AM (UTC) [ quote ]

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Flannel USA (1,230 posts)

Date

Reply #62 on Thu 17 Jun 2004 05:16 AM (UTC) [ quote ]

Amended on Thu 17 Jun 2004 05:20 AM (UTC) by Flannel

Message

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.

~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.

Posted by

Poromenos Greece (1,037 posts)

Date

Reply #63 on Thu 17 Jun 2004 10:42 AM (UTC) [ quote ]

Message

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?

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!

Posted by

Eos USA (52 posts)

Date

Reply #64 on Thu 17 Jun 2004 01:13 PM (UTC) [ quote ]

Amended on Thu 17 Jun 2004 01:14 PM (UTC) by Eos

Message

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

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.

Posted by

Shadowfyr USA (1,774 posts)

Date

Reply #65 on Thu 17 Jun 2004 07:05 PM (UTC) [ quote ]

Message

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.

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

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Reply #66 on Thu 17 Jun 2004 10:34 PM (UTC) [ quote ]

Message

Quote:

It being optional doesn't change the fact mushclient was incorrectly saying it did it.

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.

Quote:

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.

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.

Quote:

I personally don't want to see the feature removed, ...

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Shadowfyr USA (1,774 posts)

Date

Reply #67 on Thu 17 Jun 2004 11:06 PM (UTC) [ quote ]

Message

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.

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

Posted by

Eos USA (52 posts)

Date

Reply #68 on Thu 17 Jun 2004 11:45 PM (UTC) [ quote ]

Message

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.

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Reply #69 on Fri 18 Jun 2004 01:50 AM (UTC) [ quote ]

Message

Quote:

This is almost exactly the same result as removing the feature completely. Was just pointing that out.

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Eos USA (52 posts)

Date

Reply #70 on Fri 18 Jun 2004 02:04 AM (UTC) [ quote ]

Message

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.

Posted by

Skeetre (1 post)

Date

Reply #71 on Sun 15 Aug 2004 10:32 PM (UTC) [ quote ]

Message

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

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Reply #72 on Mon 16 Aug 2004 06:18 AM (UTC) [ quote ]

Message

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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Posted by

Eos USA (52 posts)

Date

Reply #73 on Mon 16 Aug 2004 10:44 AM (UTC) [ quote ]

Message

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

Posted by

Belgarath (2 posts)

Date

Reply #74 on Mon 01 Nov 2004 10:43 PM (UTC) [ quote ]

Message

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.

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,587 views.

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

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )