Gammon Forum : MUSHclient : Tips and tricks : Changing the output

Entire forum ➜ MUSHclient ➜ Tips and tricks ➜ Changing the output

Changing the output

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

Pages: 1 2

Posted by

Elvaago Netherlands (10 posts) Bio

Date

Tue 30 Sep 2003 09:05 AM (UTC)

Message

Hello,

This is a bit silly, I admit that. But people on the MUSH I am at insist on using the word 'boi' instead of 'boy'. And it annoys me. So is there any way I can change the output from boi into boy with triggers or something else?

Ruud

"We have such sights to show you..."

Top

Posted by

Poromenos Greece (1,037 posts) Bio

Date

Reply #1 on Tue 30 Sep 2003 12:15 PM (UTC)

Message

Hmm, I think it can be done, but you will lose colours. Or you need a script a bit more complex than I can write. I usually just yell at them though :P

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

Top

Posted by

Shadowfyr USA (1,792 posts) Bio

Date

Reply #2 on Tue 30 Sep 2003 06:04 PM (UTC)

Message

Yeah. Currently the only way to do this is using a trigger with 'omit from output', changing the stuff you want in script from the line recieved by the trigger and then using 'note' to put it back into output. Are have been arguing for some sort of 'pre-process' replacement function, like the OnPluginLineReceived to not just reject a line, but altern it before Mushclient processes it. This would work a great deal better, but convincing Nick that it is a useful thing is another matter.

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #3 on Tue 30 Sep 2003 08:00 PM (UTC)

Message

It's not a question of convincing him it's useful, it's a question of convincing him that the advantage gained is worth the headaches of completely re-working the way triggers and output are handled. :P

Reworking the way triggers work may also create extremely interesting (and perhaps undesirable) side effects concerning how previous triggers - ones that didn't know about this new feature - function. That could lose backwards compatibility, which is not good stuff.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Flannel USA (1,230 posts) Bio

Date

Reply #4 on Wed 01 Oct 2003 12:10 AM (UTC)

Message

Doesnt loose too much compatribility, Itd be all done before triggers, just like some of the other plugincallbacks (linesend, linerecieved) Itd just be another step to do before the stuff is sent to the trigger routines.

~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #5 on Wed 01 Oct 2003 12:26 AM (UTC)

Message

Well, two things:
a) never assume to be able to predict all possible consequences of a change that changes such fundamental things
b) see previous discussions on matching triggers before the line is complete and sent to the output window.

I agree of course that it would be nice to be able to do such things.

Instead of messing around with pre-processing and all that, which can be very icky, an alternative would be to be able to get the 'raw' line, and not just its contents; this way, any ASCII color codes would still be in there. You would perform substitutions on the raw text, and then just put it back.

e.g.

You see a (blue)pool of water(white) here.

TRIGGER:
replace pool with lake, in the raw text

Echo back to world:
You see a (blue)lake of water(white) here.

This way all coloring should be preserved.

You may also need to have the world.note function not echo using its own color, but rather whatever color is already specified by the MUD. Maybe you can already do that, I don't know.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Flannel USA (1,230 posts) Bio

Date

Reply #6 on Wed 01 Oct 2003 03:58 AM (UTC)

Message

The raw line is exactly what were talking about, I thought.

Much like was being discussed a ways back... Someone wanted raw text from mud, to do something very similar to this, if I remember correctly.

~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #7 on Wed 01 Oct 2003 04:39 AM (UTC)

Message

I thought that the idea here was to intoduce an additional stage of processing, i.e. a "pre-processor" stage before the normal trigger processing. I took that idea from this:

Quote:

Are have been arguing for some sort of 'pre-process' replacement function, like the OnPluginLineReceived to not just reject a line, but altern it before Mushclient processes it.

If that's not what was meant, well, sorry. :)

My idea was to not have a new stage, but to rather instead of retrieving the line of text, to have an option to retrieve the line of raw text.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Flannel USA (1,230 posts) Bio

Date

Reply #8 on Wed 01 Oct 2003 05:57 AM (UTC)

Message

Would seem to me that that would probably be more trouble than just giving a Callback access to the raw stuff from mud before it goes though. That way, could change things and make them how you want, before triggers.

This way, you could make one trigger for boy, and then if people still use boi, you could catch it before all your triggers resolve, since technically, thats what you want.

Otherwise, all of the sudden you will have boy on your screen (because it gets interp'd/changed by the raw at the last minute) but any trigger you had that was looking for something with boy in it, wouldnt have fired. Seems like not only would it be less effective (ie not being able to 'force' into reasonable spelling before trying to trigger on a thing) and cause problems because the trigger would look at one thing, but the Output would display another.
Let alone trying to figure out which is logged.

~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #9 on Wed 01 Oct 2003 06:15 AM (UTC)

Message

But that's my whole point, by introducing a new callback level you are introducing a new layer of complexity to the program, as opposed to an extended function call.

If you want to translate boi to boy, and then act on boy later on, all you have to do is put your triggers in the right order. You can handle the 'pre-processing' manually by simply making those triggers have higher precedence than the triggers that act on the semi-processed information. I believe that MUSHclient already fully supports this kind of action.

What advantage does introducing a new layer of complexity have over simply making one little function call that gives raw data? I'm not saying that the added callback is useless; I'm just saying that you can accomplish the same functionality in this case with a new function - which is considerably easier to implement than a new callback.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Shadowfyr USA (1,792 posts) Bio

Date

Reply #10 on Wed 01 Oct 2003 06:28 PM (UTC)

Amended on Wed 01 Oct 2003 06:30 PM (UTC) by Shadowfyr

Message

The thing is that there is already a pre-processing stage. You can capture the 'line' or even the 'packet' before triggers or any other events actually process it. However, the problem is that currently is doesn't actually give you the 'raw' line, it strips out ANSI, lets you process the line to see what it contains and then either allow Mushclient to process it normally or gag it before it is even seen by any other process.

The problem is two fold:

1. Since it strips the ANSI, you can't process it based on color information. Yes, it would be more complex for the user to deal with imbedded ANSI, but if you are doing something this low level and specific, this isn't a big deal. Also, a simple Replace(Old_Line,"boi","boy") isn't going to effect any of the ANSI or MXP, unless every single letter is a different color (so won't match) or some MXP tag just happened to contain the letters "boi". But what are the odds of that being " boi "?

2. You can't actually change the line at all. Instead of doing this:

Function OnPluginLineRecieved(ByVal Line As String ....) As String
OnPluginLineRecieved = Line
End Function

It is:

Function OnPluginLineRecieved(ByVal Line As String ....) As Boolean
OnPluginLineRecieved = vbTrue
End Function

You can kill the line, but to do replacement you need to pass the altered line as the function value, not just tell it to ignore the line. This was the original suggestion made prior to Nick adding these functions in the first place. Instead he got caught up in line style nonsense and the idea that ANSI and other things should be seperated out for the users convenience, decided it was too complicated and gave us something that does almost nothing. It certainly fails to come close to what was originally suggested.

Personally, I felt that the complications involved with raw ANSI where irrelevant. A good programmer could work around those things easilly. A bad programmer has no business modifying the raw data in the first place and should stick to standard triggers. As things stand, all we really have with these callbacks is a bizzare way to omit from output, before triggers can actually process the line.

As for the idea of using it in triggers, instead of the callback.... That is a worse mess. By the time triggers become involved in the process, the line is already in the output window. Omit from output doesn't prevent it from displaying, it erases it 'after' it has been shown. Changing the color of the line or a word doesn't happen before it gets shown, it occures 'after' it is already in the output buffer. Using triggers to perform a 'replace' function means altering a line that is already in the display and may have undergone a number of previous changes that would make simply ripping out a word and dropping a new on into it difficult at best. By the time triggers get a crack at things, it is too late to do anything useful.

Lets say for example that you are Red-Green color blind and you want to replace every case of <font color=Mint> with <font color=Blue>. By the time a trigger recieves the line containing this, the color has already been set. But Mint is also not a color that you can set a trigger to match, so you are stuck with mint lines that look exactly the same color as some shade of red. You literally can't perfrom a trigger based 'replace' function on this line, since the MXP is processed before any trigger gets a crack at it. The MXP callbacks can't do anthing about it either.

To do anything useful requires handling the raw line 'before' Mushclient processes it 'period'. Right now the only way you could manage this is by coding a proxy that would sit in between the mud and Mushclient and change packets before letting Mushclient have them. Are there any 'sane' people that would want to code such a thing, then recompile it everytime they needed to add or alter something it needed to watch for?

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #11 on Wed 01 Oct 2003 10:55 PM (UTC)

Message

So, as far as I can tell, the major limitations here are that:
a) you can't get the raw line
and
b) you can't change a line and then pass on the modified line to the next processing

This whole thing still has problems though. For one, you can't just go replace all occurences of boi with boy. You'll get words like boyl, boynk, and possibly other problems I can't think of off the top of my head. And you can't just make the assumption that no MXP tag will ever be named 'boi' - or have 'boi' in it. What if the MUD had a custom element called 'boil' or something?

I still think that people are getting a little caught up in bashing MUSHclient for not giving them complete control over everything; rather, one should say that yes, MUSHclient does have its limitations, but that we should examine carefully the problems being solved. For example, Nick's solution may be solving a problem completely different compared to the problem you yourself wish to solve; perhaps (and I don't know this) the problem he is solving is more general and has more applications than the one particular instance of what you're trying to do. Or it could be the other way around.

My point is that obviously MC has its limitations, but before getting carried away in listing them all and complaining about it, one should examine exactly what one is trying to do, and exactly what one would need to have in order to do it.

It seems that in this particular case, the only thing involved is being able to replace all text occurences of the word 'boi' (and this ignores the 'boil' problem) with 'boy'. Since a trigger ignores color, it seems that it suffice to have a trigger that when echoing back to the world, preserves the original coloring of the line, i.e. keeps the ASCII color codes.

Thus, to solve such a problem, one could perhaps specify in the trigger setting that you are dealing with the raw line, and not the normal line; therefore, when it gets echoed back, it keeps the ASCII color codes in it, but with any replacements done. The world.note (or whichever) function may need to be modified to be able to translate ASCII codes.

Obviously this isn't the most general solution to all the world's problems, but it solves the problem at hand without changing some fundamental aspects of the program. Nick probably had very good reasons for doing what he did... never forget that there are always two sides to a program's functionality. Sometimes, the design of the program simply makes it impossible (or nearly impossible) to add a feature; many people have been asking for things like cursor control, and this is a very good example of a feature that cannot really be done due to the design. Sure, this is a design 'flaw', but perhaps the original goal of the design was to provide an extremely fast window - and that, it certainly does. Sure, zMUD has a lot of fancy other features, but it certainly is not nearly as fast. So basically, you're going down to the whole premise of the design. The more fancy things you add - like pre-pre-processing and callbacks and whatever - the more you slow things down, and sometimes you can't add them without changing the way the whole program works.

To sum up: if a problem can be solved using a simple solution that doesn't change fundamentals of the program, then that solution should be adopted. If a problem needs the program to be completely (or even mostly or partially) redesigned, one should try to think about whether:
a) there is an alternative solution to solving the problem
b) the design changes implied by the solution are better, overall, than the current design in place. (e.g. a new design may slow down the system, just to add one feature.)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by Shadowfyr USA (1,792 posts) Bio

Date

Reply #12 on Wed 01 Oct 2003 11:45 PM (UTC)

Amended on Wed 01 Oct 2003 11:54 PM (UTC) by Shadowfyr

Message

Look. The point is that it won't work. Take this as an example:

<blue>Hello <red>boi <green>, how are you?

The resulting line info would be:

Line - Hello boi, how are you?
Styles>
  Position = 1
    Color = Blue
  Position = 7
    Color = Red
  Postion = 11
    Color = Green

For 'boi' = 'boy' this isn't a problem, but what it you where on a nautical mud and needed to make it bouy? Now you not only have to replace the letters, you have to change the 'existing' information about where on the line each color happens. Otherwise the 'y' will end up being green. This isn't impossible, but it is silly to make something this specific and general, then code a complex mess to deal with moving the colors around to match the new line. Worse, they may not in fact be what the user wanted, maybe they wanted the 'y' to be green for some reason. Or maybe they want to change several words that 'span' a range of colors on the line. There is no practical way to do this with the way lines are displayed and when triggers actually get hold of them.

Changing the existing function to let you make changes is far simpler and much more versitile. The problem of if some word that includes 'boi' might get changed is not imho an issue. First off, in this case you can include the spaces:

a = replace(line, " boi ", " boy ")

If you need to also deal with bois, then same thing. It is no different than designing a trigger that works properly. And as for whether or not the existing function for lines solves some problem I don't know about.... I was the one that made the original suggestion and then argued with Nick about what it actually did and why it didn't solve the problem I or several others actually had. His explaination was that you 'could' do what we intended by reading the line, coloring it, etc. using colournote and colourtell and then simply telling the client to not use the line. He was worried about possible problems that actually changing the line might cause. Like someone miscoding it to reject all lines except the one they changed (by for instance not returning the unchanged line). It was not a solution to a different problem, but an incomplete solution to one we saw and never got fixed to our satisfaction.

The fact is that as it stands, extending the existing function is easier than implimenting yet another limited and incomplete way to solve the problem, especially considering the very real complications involved with just what and how the line would need to be altered to make it work right through triggers.

There is only one way that this could be made to work with triggers, and the is by letting them operate on raw information and making it so that 'replacement' triggers get first crack at the line, even before the line is displayed. Even then, there may be cases where calling a function (instead of a sub) to do the processing would work better and be far more flexible.

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #13 on Thu 02 Oct 2003 12:08 AM (UTC)

Message

Quote:

The fact is that as it stands, extending the existing function is easier than implimenting yet another limited and incomplete way to solve the problem

Well, I thought it was pretty clear that I meant that you don't KNOW this, you just THINK this. Unless you have the source code, you really don't have any idea how easy or hard it would be to make ANY change. It completely depends on how Nick has set up the system. If it's really so trivial, send Nick the source code.

What would extending the existing function mean? Give a concrete example. Show exactly (*exactly*) what more you want it to do. Perhaps if you have to actually write it out, you'll find that it's not as easy as you think. Perhaps you won't. But in any case, it'll make it more clear what you're asking for, as my impression is that you're complaining about a lack of 'functionality' without actually specifying what functionality that is. Unless your only problem is replacing boi with boy, problem which I solved with a precise list of exactly what would need to be added to solve it.

Quote:

Now you not only have to replace the letters, you have to change the 'existing' information about where on the line each color happens.

You said yourself that if someone didn't know what they were doing, and didn't feel comfortable doing it, then they probably have no business doing this at all.

Quote:

It was not a solution to a different problem, but an incomplete solution to one we saw and never got fixed to our satisfaction.

Maybe the problem he is solving is, as I said before, more important or general than the problem you are trying to solve. You haven't yet phrased what exactly your problem is yet, though, so I don't know if that's the case.

For this kind of discussion to be at all productive you have to be specific about what you're asking for. So far, I have trouble determining precisely what you want to be different. I also have trouble with the fact that it seems many of the problems you bring up are not specific to the solution I suggested, but in fact specific to almost ANY solution (e.g. modifying words across a range of colors.) Unless of course you're expecting MUSHclient to do magic for you and somehow recolor it like you meant it to be displayed..... and we all know that's just not the way it works.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Shadowfyr USA (1,792 posts) Bio

Date

Reply #14 on Thu 02 Oct 2003 12:58 AM (UTC)

Amended on Thu 02 Oct 2003 01:01 AM (UTC) by Shadowfyr

Message

Hmm.. Looking back on it, it seems that it was implimented for some other use. However, one of the first suggestions was to extend it to provide such function. Much of what mushclient does is as versitile and useful because it places no limitations on what you can actually do with it. There have been exceptions, like how the line coloring only supported 16 colors until very recently, when an extension was added at the prompting of users. Fankly, the use of OnPluginLineRecieved never made any sense to me at all. There is nothing it can really do that triggers can't.

Well, there is one minor exception. If you had an MXP tag or the like you wanted to capture and handle yourself, then you could trap it there before MXP or anything else has a chance to deal with it. However, I didn't see this as all that useful either. Why not? Here is an example, from say some mud using a special set of commands.:

Trappable using OnPluginLineRecieved:
@sound ....;

Not trappable>
You hear a scream!@sound ....;

In the second case you can trap the result, but it doesn't matter if you use triggers or OnPluginLineRecieved. "You lose the entire line!" I have no idea what this was supposed to solve, but it simply can't work the way it is designed.

The fact is that instead of making something that only replaces part of a line, a much better solution is something that can let the user decide how and what it is going to do to the line. Triggers can do this, but only if a new type are added that execute well before ANSI, MXP or anything else handles them. The other choice is what you want, which can change boi to boy, but won't allow you to do something as relatively simple as adding commas to a number on the line. To do that requires scripting of some sort. Why do something wrong in order to solve a minor and limited problem when you can implement a solution that solves 'many' problems?

So, you want me to be clear. I want:

1. To be able to replace boi with boy or the like.
2. Add commas to numbers, or other things that a simple replace "can't" do.
3. In some cases altern the actual content of tags or ANSI codes 'before' the line gets processed with them.

You can do 1 relatively easy, 2 is much more complex and pretty much requires scripting, but if you can do 2, then 3 is also possible. In fact it is necessary. In order to add something like commas you have to break the original line up into pieces and change the number of characters that may exist in between colors. For example:

[[37mExp = [[32m1234567[[37m

How exactly, unless you process the raw line in a script do you correctly change that to this:

[[37mExp = [[32m1,234,567[[37m

I may not have the source code, but I have discussed how many things work and how best to implement some features with Nick often enough (since like version 2. something, or maybe before) and have fairly good idea how a lot of it fits together. There is no easy solution with triggers, even if it would admittedly be a far better solution. However, jsut for your info Mushclient does things in more or less this order:

1. Recieve a packet.
2. Check for OnPluginPacketRecieved subs.
3. If no rejected in 2, add packet to the line.
4. Process for ANSI and MXP commands.
5. If MXP Error routine is set, then execute that.
6. Execute any other MXP subs that are relevent, repeating 6 each time until all tags are processed.
7. If packet contains an end of line, then look for OnPluginLineRecieved subs.
8. If not rejected in 4 then display the line.
9. Process through triggers.

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.

60,953 views.

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

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

Go to topic: Search the forum

top