Gammon Software Solutions forum

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

Entire forum
MUSHclient
VBscript
*Backwards* color bleeding using world.colourtell?

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

(New message)

Subject:	Backwards color bleeding using world.colourtell?
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Demonsurfer] Nick said in reply to above: "I think the problem is, you don't necessarily know which is the last colourtell." I don't know if that was the issue when I reread this thread.. I think Neva knows what 'order' the trigger lines were coming in (Neva: "All the multiple lines arrive at the exact same time, it's one set, the game just inserts line breaks"), even though they were all 'at once' so to speak, if I read it correctly, there still is an order to them? I mean with this example Neva gave [code] sub Test1 (sTrigName,sTrigOutput,aWildcards) world.colourtell "yellow", "blue", "Test." world.colourtell "red", "blue", "Test." end sub [/code] just change that last bit to colournote instead of colourtell and it's fine. ..although, if Neva means that the above is one subroutine and then he wanted a separate subroutine to add on to the SAME line produced by the above one.. yeah then I see the problem. As I see it, World.ColourNote basically ends the line, anything following would be on a new line, right? Whereas World.ColourTell is waiting for another bit of script to follow it (whether it's world.ColourTell or World.ColourNote does not matter) before it will spit out the desired piece of that line in the correct format. If that's the case, then this becomes something like multi-line triggering which is an entirely different matter. Am I on the right track here? addon: yeah rereading this thread again, and I think I'm on the right track. Nick you suggested on Thu 06 Feb 2003 04:09 PM what I would too, to use variables. Neve replied "But, see, the tells themselves work. It merges into one line perfectly. ..The colors are the only thing that don't work properly" and that's because the last one that is sent is a World.ColorTell and not a World.ColorNote. In this example Neva gave: [quote] [code] sub Test1 (sTrigName,sTrigOutput,aWildcards) world.colourtell "yellow", "blue", "Test1." end sub sub Test2 (sTrigName,sTrigOutput,aWildcards) world.colourtell "blue", "yellow", "Test2." end sub [/code] If Test1 is a Trigger that matches 'Blah1', and Test2 is a trigger that matches 'Blah2', both omitting from output, and each string arrives on a separate line one after the other, like so... Blah1 Blah2 ...then you'd expect that at the very least, you'd end up with the two colourtells on separate lines, but working otherwise. No such luck; what you get is: Test2. in plain output colors, no "Test1." anywhere to be seen. [/quote] if you changed the second one to World.ColourNote, does it work as desired? Guess I should try it for myself. ...( a few minutes later) no it doesn't work, and that does not surprise me. They are still separate triggers and separate subroutines and the example above will only work if both are world.colorNote and then they display on separate lines. The reason only Test2 came out in the above example is not immediately clear to me, I guess MC had to do something and that was it :) but it still sounds like multiline triggering as far as I can see. For example, on the mud I play if I type: save demon what comes back is: demon saved. items saved. both arrive 'at the same time', but they are still separate lines. Neva you said "But, see, the tells themselves work. It merges into one line perfectly. ..The colors are the only thing that don't work properly" I don't see how it worked, because you then gave the example above which clearly doesn't work. Are you saying that somehow you already have 3 seperate subroutines that are each doing worldnotes and they all merge onto one line? Maybe I'm just confusing myself here, but I didn't think that was possible. When I tried my example using your script above and 'save demon' from the mud I use as above, although I had omit from output selected, I still saw the output.. what I got was demon saved. Test2. items saved. since you are repeating the same line but trying to repeat them in colour, maybe you thought it was merging the lines when in fact it wasn't. See what I mean? It's just spitting out whatever it can.. [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2 3

Posted by

Demonsurfer USA (256 posts)

bio

Date

Sat 15 Mar 2003 06:53 PM (UTC) [ quote ]

Message

gratz :)

top

Posted by

Neva USA (117 posts)

bio

Date

Sat 15 Mar 2003 06:40 PM (UTC) [ quote ]

Message

Version 3.34 is officially the most beautiful thing I've ever seen.

It works. 100%. Yay!

Now, I *think* I can be quiet for awhile. ;) You have no idea how much this *one* thing makes my life easier. Thankyouthankyouthankyou!

top

Posted by

Neva USA (117 posts)

bio

Date

Sat 15 Mar 2003 06:00 AM (UTC) [ quote ]

Amended on Sat 15 Mar 2003 06:03 AM (UTC) by Neva

Message

There will be great rewards for you in the hereafter, Nick. Love. And cookies. Many cookies.

(Edit: I really did mean to capitalize your name. It's 1am here and my laptop keyboard isn't particularly fond of me sometimes. Like I *mean* to get it all full of crumbs or something...)

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Sat 15 Mar 2003 05:46 AM (UTC) [ quote ]

Message

Neva, I am trying hard to make this work for you. :)

I have added an extra check, so that if you do a colourtell, omit a line, and then do another colourtell, they will now run together onto the same line. Hopefully this will let you do what you are attempting.

Whether this has adverse side-effects for thousands of other users, let us see. :P

- Nick Gammon

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

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Sat 15 Mar 2003 05:34 AM (UTC) [ quote ]

Message

OK, another couple of fixes. The colour bleed should be fixed for good now. Where I was forcing the colour to be the normal text colour I now check for a non-zero length style run, and if found, start a new one.

Also, fixed the problem where if you omitted from output it wouldn't start a new line (eg. for user input, or MUD output) if you had done a colourtell.

- Nick Gammon

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

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Sat 15 Mar 2003 05:08 AM (UTC) [ quote ]

Message

Quote:

sub Test1 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "yellow", "blue", "Test."
world.colourtell "red", "blue", "Test."
end sub

It worked for me when I tested it, but I didn't check "omit from output". I see what you mean.

- Nick Gammon

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

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Sat 15 Mar 2003 05:04 AM (UTC) [ quote ]

Message

Quote:

the client should pretty much be treating the omitted text as nonexistant the moment it's omitted

The problem is that writing a MUD client is more complex than that.

For one thing, text arriving from the MUD is not guaranteed to arrive in neat lines, rather the nature of TCP/IP is that data arrives in packets, whose size cannot be predetermined.

Thus, a "line" (ie. something ending in a linefeed) may take one or more packets, and indeed one packet might contain multiple lines.

Say MUSHclient gets a packet, with no linefeed it has to do something with it, and what it does is put it into the output "buffer" which is then displayed on your screen a moment later. Then later on when the linefeed arrives it goes through trigger processing, and if a trigger matches, runs scripts. However the fact that it was put into the output buffer can not be simply treated as if it never happened.

What used to happen was that the colourtells, which did not terminate a line had the output text "run onto" the end of them, and due to the fact that I had not anticipated this, you got the colour bleeding. Now, what is happening is that the newly arrived line terminates the colourtell, even if the line is subsequently omitted.

Colourtells were designed to allow you to build up a line, like a world.note, but consisting of different coloured words, which you would eventually terminate by doing a colournote, or something similar. My test of your example test1 sub shows that it now works as designed, even if you omit the final colournote.

Now I'm not saying that 3.33 perfectly fixes the problem, because further testing after I uploaded it seems to indicate that it clashes somewhat bizarrely with your own input. Perhaps further tests are required for terminating a colourtell after a command is typed. I will investigate that.

Quote:

If a 'tell' isn't supposed to add a line break, it *shouldn't* be adding a line break.

The tell isn't adding the line break, the arrival of a new line from the MUD triggers a new line. Otherwise we have the issue of what "sort" of line is it. MUSHclient marks lines in the buffer as input, MUD text, or notes. (You can see this by hovering the mouse over any line). Various functions, like the recall window, let you filter on whether a line is input, note etc. If the colourtell and the MUD output share a line, then the line is a hybrid line which doesn't fit too well into other parts of the system.

- Nick Gammon

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

top

Posted by

Neva USA (117 posts)

bio

Date

Sat 15 Mar 2003 05:00 AM (UTC) [ quote ]

Message

Specific tests:

sub Test1 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "yellow", "blue", "Test."
world.colourtell "red", "blue", "Test."
end sub

(One trigger.)
-- Still broken. Exact same performance as before. If you don't manually tack the vbCRLF on the end, it doesn't color. I suspect this has *something* in common with the other problem--because it's not properly recognizing where it's supposed to start and stop coloring.

sub Test1 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "yellow", "blue", "Test1."
end sub

sub Test2 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "blue", "yellow", "Test2."
end sub
(Two triggers, one line right after the other.)

-- Still same result as before.

About *is* displaying 3.33.

I'm going to try to clean up my actual code soon to make it semi-readable--try to get a reproducing version that doesn't use all the control characters and regexp editing and junk and just shows off the bleeding I'm experiencing.

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Sat 15 Mar 2003 04:37 AM (UTC) [ quote ]

Message

Quote:

My codebit works exactly the same way it did before; it uses the ending color, ignores the earlier ones.

Whether the other examples now work properly, I dunno. I may have to post the full code I'm using, but it's a bit on the complex side, seeing as it uses three different triggers and some mildly weird game output.

Your posted example works for me, can you confirm that it does for you? Otherwise maybe you aren't using the new version.

- Nick Gammon

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

top

Posted by

Neva USA (117 posts)

bio

Date

Sat 15 Mar 2003 04:28 AM (UTC) [ quote ]

Message

Upside: In actuality, no, it doesn't break anything, really.
Downside: It doesn't fix anything, either.

My codebit works exactly the same way it did before; it uses the ending color, ignores the earlier ones.

Whether the other examples now work properly, I dunno. I may have to post the full code I'm using, but it's a bit on the complex side, seeing as it uses three different triggers and some mildly weird game output.

(I've considered switching to their other client format, which uses XMLish stuff, but I don't think I can render that useable any easier, although I think it'd wipe out the funky line breaks and control characters in weird places--but that's presuming I could find any documentation on it, and I don't know that I can.)

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Sat 15 Mar 2003 02:15 AM (UTC) [ quote ]

Message

Neva,

3.33 has been released, see the forum posting in the news and updates section.

I suggest you try it first, and see if it fixes the problem.

I will reply in more detail shortly about why the fix is the way it is.

- Nick Gammon

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

top

Posted by

Neva USA (117 posts)

bio

Date

Sat 15 Mar 2003 01:53 AM (UTC) [ quote ]

Message

In reading that again, I'm not sure it addresses my problem at all, and as far as I can see, it *will* break my existing code.

I've got no problem with it turning back to the 'default text color'. It's changing to the color of the last colourtell used. If I make it yellow, the whole line turns yellow. If I make it blue, the whole line turns blue. The default text color is not involved.

Omitted text shouldn't be having any effect whatsoever on anything. That's why it's omitted. If there's omitted text in the middle, it should be no different than if I just type:

/colourtell "red", "black", "Test"
/colourtell "blue", "black", "Test2"

But it is, *solely* with the fact that it for some reason turns the entire line blue instead of just the string it's telling. That's the bug.

This 'fix' is in fact not going to fix anything, and is going to break my existing code--which makes the bug irrelevant, true, but I didn't think that *removing* functionality was the preferable way to deal with such things. Omitted text shouldn't be having any effect in any manner. If a 'tell' isn't supposed to add a line break, it *shouldn't* be adding a line break. Likewise, the tell should be coloring only the text which it's telling, and not anything else. Running stuff specifically prior to the omit--via trigger sequencing, etc--is one thing, but the client should pretty much be treating the omitted text as nonexistant the moment it's omitted. Pretending it never happened, as far as the output's involved.

top

Posted by

Neva USA (117 posts)

bio

Date

Fri 14 Mar 2003 11:33 PM (UTC) [ quote ]

Message

I'm thinking this may actually break my code. But I guess we'll see...

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Fri 14 Mar 2003 10:29 PM (UTC) [ quote ]

Message

See point 6 in MUSHclient version 3.33 release notes

- Nick Gammon

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

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Fri 14 Mar 2003 09:35 PM (UTC) [ quote ]

Message

I will try to have a new version within 4 hours of this posting.

- Nick Gammon

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

top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

8,455 views.

This is page 1, subject is 3 pages long: 1 2 3

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

top

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