Yes, why does that happen? Shouldn't the colour change be valid only for the screen? I would think all triggers would match on the original colour, even if it was changed (no use trying to match "peru").
Do you intend to "fix" this? This way it's impossible for a plugin to reliably match when someone has coloured a line, possibly rendering it useless, while changing it doesn't have any downside.
Ah yes, no downside? Everything has a downside. :)
First, I don't really regard this as a bug - you (the trigger) asks for the line colour to be changed and it is. The fact that subsequent triggers now have to match the new colour is really their problem. After all, it isn't really "someone" that changes the colour, it is a trigger under your control.
You suggest matching "the original colour". Well, because of MXP, and the fact that every character in a line can potentially be a different RGB colour, MUSHclient now stores colour (and other) information in style runs, where a style run is a sequence of characters that have the same attributes (eg. colours).
To store "the original colour" really means making a complete copy of the style run information for that line, ie. doubling its size. So, the downside is, apart from the complexity, the extra memory needed to store the style runs twice, plus the possible extra bugs. For instance, say you had a word AAbbCC and you changed bb from red to green, you have broken one style run into three.
However the "original" style runs have the one run for that word, whereas the new ones have three. Now say you colour CC a different colour you are matching on the old style runs, but changing the new ones. Sounds complex to me.
Why not just adjust the sequence numbers for the triggers so that the plugin's triggers fire and perform whatever they do on the line 'before' the one that changes its color?
Hmm... This is very inconvenient... Now whenever I distribute a plugin I know that it'll probably never work right because of this. Many people colour channels, and I can't ask them to remove their triggers from the world file and load plugins in order... My only option is to disable colour matching, which will make it match in bios, etc... Plugins are supposed to be useable universally, and this effectively disables color matching in mushclient, in my opinion... Can't you modify MC to match triggers like Shadowfyr says? Storing style twice would be ineffective, i agree...
I'm not sure this really helps. For one thing, people who write plugin that deliberately match multiple times (like was recently suggested to colour chats purple and the rest of the line white), may well rely on all their triggers matching in the specified sequence.
If you match all sequence 5 triggers first, from all plugins, then you may get a different effect, that may make other things stop working.
In any case, say you made your trigger sequence 5, what is stopping someone else from having a trigger sequence 4, and then you still have the problem?
I suggest you simply advise that your trigger is designed to match on text/colour, and if they choose to change the colour in some way it may not work.
Another approach is to craft a trigger that simply matches the text and doesn't rely on the colour.
Are you sure this is a real problem, or are you raising it because you stumbled across it when having identical triggers in two different places? I mean who would have this in their bio?
Nick guildtalks 'hello there'
If it comes to that you may as well object that someone might fudge some other text in their bio to throw the triggers out. For instance, if I had in my bio:
Exits: north, east, south
That might throw out someone's exit-matching trigger.
And if they are going to get really nasty about it, they could put in their bio the exact colours your trigger is designed to match against.
OK, first of all, let me suggest this: Could you store the original color just until all triggers have been matched, and then discard it? Also, in reference to your example, could each plugin match the original color first and then recolor it according to the plugin? How about a "match_on_original_color" option? You only need to store the style until the triggers are evaluated, which is only a short bit.
And yes, it is important that it matches on colour, since now I can't distribute the plugin to anyone without changing the colours each time, because i have colored my channels differently from other people.
Many people put guildtalks in their bios (mainly funny ones), and it would match on those too if you whoised them. As for coloring them, RoD cannot color bios so that doesn't worry me so far... I see the usefulness of your way, I just think that more people rely on their plugin matching the original color than matching a modified color...
There might be a small problem with coloring if you use my way, i.e. to store the original color and match per plugin, mainly because a plugin can color it one colour and another one can colour it another, but that would be done if it didn't match on color anyway, and it's better to match than not to match, in any case...
I think that the "match on original colour" option would be the best solution. You would store the original style temporarily, match on whichever colour the trigger needs, and then pass it on to the next trigger. You don't need to store one style per plugin, because one is the original colour and the other is the displayed colour, i.e. only two styles...
I feel that matching on the modified color hinders reusability, because many users could recolor their text.
I'd also like to know how other plugin writers feel about this, so please post your opinions :p
Well.. I personally think it is a bit odd that changing the color of a line changes the line in some non-retrievable way myself. It makes no sense. I am not trying to match on the bloody output (the recolored line), I am trying to match the original line that 'came from the mud'. Why would I 'ever' want to match on what I personally changed?
To give another example. Lets say, for the purposes of this example, that you implimented a word replacement ability and I found some glaring error in the mud that the admin won't be getting around to fixing any time soon. It bugs the heck out of me:
----
Dark Forest
Its dark.
Exits: North and South
A Blue Fairy
-look
You see before you a green fairy wearing a bowler.
-south
Dark Forest
Its really dark.
Exits: North
A Green Fairy
- look
You are looking at a blue fairy holding a strange wand.
----
Now, lets say I used that new word replacement trick to switch the instances of 'Blue' and 'Green' when they appear in the room as part of a fairy. According to the total lack of logic used here with triggers, both fairies would end up blue. Why? Because the first trigger will match "A Blue Fairy", change it to read 'Green', then match the second trigger and change it back to 'Blue'. If it is already 'Green', then it skips the first trigger and changes it to 'Blue'. Ooops! This is assuming they always fire in that order. This would be a very obvious and serious bug. So why again exactly is color information being treated this way considered acceptable?!?
It 'may' be useful occationally to match on what you change a line too (though for color matching this is almost pointless), but only as an intentional behaviour on the part of the user, not the default which should in my opinion be what the user expects, i.e. matching on what was actually recieved in each trigger.
Yes, it is probably hard to do, but in my opinion it is one of the most important things that need to be changed, and I don't mind how long it takes, I just wanted to hear that it'll be changed eventually :)
Hmm, couldn't you make an extra style, and store line style changes in that, and then, when the triggers are all evaluated you could swap the old style with the new one. This way, all you have to do is transfer the change from the original style to the new one, and copy it when the triggers are done. Is that doable?