Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

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

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2 3  

Posted by Guest1   USA  (256 posts)
Date Reply #15 on Fri 14 Mar 2003 04:38 AM (UTC)

Amended on Fri 14 Mar 2003 04:43 AM (UTC) by Guest1

Message
yup something like that :) ..except
Quote:

Say you get two lines "A" and "B". You have a trigger matching "A" that sends "X" and "Y" in two different colours using world.ColourTell.

What actually happens is this is displayed:

A
XYB

that is again just a matter of changing "Y" to a colourNote. Line "B" isn't really anything to do with it in this case other than it gets included in the same line as XY because there is nothing to terminate the line after "Y" is sent.. but I didn't think that was really the issue.

I think Neva was wanting this:

Say you get two lines "A" and "B". You have a trigger matching "A" that sends "X" and a trigger matching "B" that sends "Y" in two different colours on the same line using world.ColourTell.

That's multiline triggering and is not supported, although Neva says the messages appear 'all at once' over 3 lines, with line breaks inserted by the mud. Well.. that's still 3 lines, not 1 ..see where I'm coming from?

*raises an eyebrow and looks a bit confused*
Top
Posted by Neva   USA  (117 posts)  Bio
Date Reply #16 on Fri 14 Mar 2003 02:51 PM (UTC)
Message
I'm not *trying* to do a 'multiline trigger' as it is not supported--that's *why* it's multiple triggers. Multiple triggers to trigger on multiple lines *is* supported.

But, in this case, anyway, really the only actual problem is the bleed. The code I've got *works* just fine, except for the bleed. (Other people could have trouble with the places where it actually omits both, that's the only reason I included it, but I can see why it does that.)

It's the bleeding that's an issue, because once again, if the color's left out, the code I'm actually using works just fine. It doesn't *do* much, because I can have the *MUD* do that and remove the hiliting that it's trying to do and live without it entirely, but in terms of the client, the code itself is functional. It's just when you switch from tells to colourtells that the colors start getting odd and hiliting the entire line instead of just the pieces they belong to.

I just need the damned things to remember which parts are supposed to be color A and which parts are supposed to be color B, and not just completely turn into one of them, and I'll be a happy camper. The rest was just in case it would be of any use in obtaining what I want. :)
Top
Posted by Guest1   USA  (256 posts)
Date Reply #17 on Fri 14 Mar 2003 03:17 PM (UTC)

Amended on Fri 14 Mar 2003 03:25 PM (UTC) by Guest1

Message
Ok I gotchya. I was kind of meaning it compiles multiple triggers (or results of multiple subroutines) into one line rather than being a single multiline trigger itself, if you follow my drift. I never realised that a series of (for example) 'colourtell colourtell colourtell colourNote' would (or should) work on the same line when they each come from separate routines. Kinda kewl that it does, even if it's a bit screwy atm.

Maybe another option Nick would be to add a new tag to MC that basically overrides any prior command and tells the client to not start a new line when this tag is displayed, so in Nevas case they could all just be sent as if they were individual separate (new) lines, but each would have this tag at the end so it wouldn't start a new line. Kind of a patch but it would work probably, since the current coding appears to mess up the colours.

I think I'll leave it up to you 2 since you know what you're talking about far more than I seem to hehe. :)
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #18 on Fri 14 Mar 2003 09:35 PM (UTC)
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
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #19 on Fri 14 Mar 2003 10:29 PM (UTC)
Message
See point 6 in MUSHclient version 3.33 release notes
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Neva   USA  (117 posts)  Bio
Date Reply #20 on Fri 14 Mar 2003 11:33 PM (UTC)
Message
I'm thinking this may actually break my code. But I guess we'll see...
Top
Posted by Neva   USA  (117 posts)  Bio
Date Reply #21 on Sat 15 Mar 2003 01:53 AM (UTC)
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 Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #22 on Sat 15 Mar 2003 02:15 AM (UTC)
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 Reply #23 on Sat 15 Mar 2003 04:28 AM (UTC)
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  (23,133 posts)  Bio   Forum Administrator
Date Reply #24 on Sat 15 Mar 2003 04:37 AM (UTC)
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 Reply #25 on Sat 15 Mar 2003 05:00 AM (UTC)
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  (23,133 posts)  Bio   Forum Administrator
Date Reply #26 on Sat 15 Mar 2003 05:04 AM (UTC)
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 Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #27 on Sat 15 Mar 2003 05:08 AM (UTC)
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  (23,133 posts)  Bio   Forum Administrator
Date Reply #28 on Sat 15 Mar 2003 05:34 AM (UTC)
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  (23,133 posts)  Bio   Forum Administrator
Date Reply #29 on Sat 15 Mar 2003 05:46 AM (UTC)
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

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.

87,453 views.

This is page 2, subject is 3 pages long:  [Previous page]  1  2 3  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home