I'm doing a script that works in three parts. It's essentially just hiliting part of a line, but it can't be done any other way because of the way the line is sent. It's complicated.
But, in essence, what's happening is that I do, say,
world.colourtell "gray", "black", "Blah! "
in one 'sub' called by the first trigger. Then it turns on the second trigger.
Then,
world.colourtell "magenta", "black", "Magenta! "
with the second trigger. Which then turns itself off to wait for the first one again. Or that's it in essence, anyway. (Vastly simplified, but I have pretty much verified that the problem isn't related to the more complex bits.)
If I end the first colourtell with a vbCRLF or use colournote instead, the colors are done properly. And if I use multiple colourtells in the same trigger, it's fine.
But if I use them in multiple triggers, it goes back and converts the entire line to the color of the second colourtell.
Pretty much. I have several lines arrive at once, that I want to be merged, but with one part highlighted. And they do properly show up on the same line, but somehow it seems to be screwing the colors up.
Although I haven't reproduced this bug, or possible bug :) , I suggest that what you are trying to do won't work, as such.
The problem is that I presume you are omitting the original lines in question, taking stuff from them and merging them into a new line you actually see with world.colourtell?
What will go wrong here is that the new line(s) (line B in my earlier post) are not omitted immediately, but placed in the output window, until a newline arrives, then the trigger omits them. What this means is that any partial line with world.colourtell will be terminated.
What I suggest you do is collect the prospective new line that you are assembling in variables, without displaying it yet, and then when it is all ready (eg. after 3 lines arrive) then display the whole lot - with consecutive world.colourtells if it is using different colours. That way the colourtells are all in one sequence, and should display OK.
But, see, the tells themselves work. It merges into one line perfectly. (All the multiple lines arrive at the exact same time; it's one set, the game just inserts line breaks.) The colors are the only thing that don't work properly.
Really, I swear, the only problem with it is that the colors for some reason aren't showing up right. The tells all happen perfectly. But for some reason, when done by separate scripts, the colors just don't work right.
I'm amending this now, because I've been playing with other scripts, to see just where things are going wrong, and I'm beginning to come to the conclusion that world.ColourTell is just busted in general.
I.e.:
sub Test1 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "red", "blue", "Test."
end sub
Use that, match it to anything you like, and what I get (in 3.32) is 'Test.'--in plain output colors.
Yet if I substitute 'colournote' for 'colourtell', it does in fact send the colors properly.
Then, I take it one step further.
sub Test1 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "yellow", "blue", "Test."
world.colourtell "red", "blue", "Test."
end sub
This produces the first tell in proper colors... but the second in standard output. It's not, in effect, coloring in whatever shade it's supposed to be until it receives either another world.colortell or a linebreak. Where the *expected* behavior is that no matter what it contains, no matter what it follows or precedes, the colors should appear as requested.
Get any more complicated than that, and I start running into behavior I can't even possibly explain.
sub Test1 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "yellow", "blue", "Test1."
end sub
sub Test2 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "blue", "yellow", "Test2."
end sub
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.
Every single one of these examples works as expected using colournote instead, with the obvious addition of a line break in between. Yet not one of them works as expected using colourtell.
Sorry, was doing other things for a couple of days. I'll take your test data and see if I can reproduce it, and if so, fix it, so it can go in the next version.
re the colour tells, if this helps, I've found that if you're doing a series of mixed colour tells in one line like that, the last one in the 'series' needs to be a World.ColourNote, the previous ones all scripted as World.ColorTell. It appears that the same applies if you're doing 2 separate routines where there is no activity between them being run, if that makes sense. Try that.
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
sub Test1 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "yellow", "blue", "Test."
world.colourtell "red", "blue", "Test."
end sub
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:
sub Test1 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "yellow", "blue", "Test1."
end sub
sub Test2 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "blue", "yellow", "Test2."
end sub
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.
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..
On my way offline, but another thing worth trying, how about putting a short delays on all the subroutines, so in my example the mud spat out
demon saved.
items saved.
the trigger saw 'demon saved.' and tried to spit out 'colourtell Test1', but this was then follwed by the script seeing 'items saved.' so it basically spat the dummy.
This may not work but try having a delay on all of the triggered subroutines, so the other lines of triggered text have a chance to come out (even if it seems like they are all at the same time, they are still spearate lines nevertheless)
so in above mud would spit out
demon saved.
items saved.
(which would hopefully be omitted by the triggers), and the first triggered routine sees 'demon saved.' and waits 1 second.. during that 1 second delay, the next trigger sees 'items saved.' and it's corresponding subroutine also waits for 1 second.. then 1 second later the first routine sends out 'demon saved.' as a colourtell followed immediately by the 2nd routine sending out colournote 'items saved.' ..so nothing inbetween, if you get me.. maybe that works? I doubt it, but ya never know.
sub Test1 (sTrigName,sTrigOutput,aWildcards)
world.colourtell "yellow", "blue", "Test."
world.colourtell "red", "blue", "Test."
end sub
OK, I think I see the problem, but am not absolutely certain what is the best solution. :)
Here is what is happening, I think. :P
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
Due to this "bug" (sorry, Neva) the B is not put on a new line, *and* bleeds the default output colour backwards to the "Y". This I think describes what is happening. (Note to myself: see function SetNewLineColour).
There could be two fixes:
Fix this backwards bleeding.
Make "B" start a new line. I am leaning towards that, as technically "B" is not a note and should therefore not share a line with a note/tell.
In other words, one or more world.colourtells would automatically be terminated (eg. a new line started) when a non-note/tell is received.
Any comments?
Quote:
No such luck; what you get is:
Test2.
in plain output colors, no "Test1." anywhere to be seen.
I think my evaluation explains this as well. By merging notes and MUD output onto one line, the "omit from output" actually omits the line with the colourtell in it as well.
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?
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. :)
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. :)
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:
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.
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.)
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.
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.
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.
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.
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
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...)