[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  VBscript
. . -> [Subject]  Trigger not matching colour
Trigger not matching colour

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

Pages: 1 2  

Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Wed 27 Aug 2003 11:34 AM (UTC)
Message
OK, this boggles me. This trigger matches:

  <trigger
   match_text_colour="y"
   text_colour="14"
   custom_colour="17"
   enabled="y"
   keep_evaluating="y"
   match="[A-Za-z]+ (guildtalk|ordertalk)(|s) \'(.*?)\'$"
   regexp="y"
   sequence="100"
   other_text_colour="peru"
   other_back_colour="black"
  >
  </trigger>


This one doesn't:

  <trigger
   enabled="n"
   group="grpRecord"
   keep_evaluating="y"
   match="([A-Za-z]+) guildtalks \'(.*?)\'$"
   match_text_colour="y"
   name="Peru01"
   regexp="y"
   script="subRecord"
   sequence="100"
   text_colour="14"
   other_text_colour="black"
   other_back_colour="black"
  >
  </trigger>


What am I not seeing? (The second trigger is in a plugin, the first one is in an include file in the world, it colors text fine.
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top
Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #1 on Wed 27 Aug 2003 11:35 AM (UTC)
Message
I have changed color matching to "n" in the second trigger, and it matches fine, so it's not the trigger text's fault, it's the color matcher... Bug?
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top
Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #2 on Thu 28 Aug 2003 12:40 AM (UTC)
Message
By the way, the trigger in the include file runs first, changing the text color, and then the second trigger runs, and doesn't match.
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top
Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #3 on Thu 28 Aug 2003 12:47 AM (UTC)
Message
I just tried it in a world that does not have the trigger included, and it matches colour fine.
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top
Posted by Nick Gammon   Australia  (22,982 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Thu 28 Aug 2003 06:54 AM (UTC)
Message
Are you saying you match twice, the first one changes the colour and the second one doesn't match the original colour? That wouldn't surprise me.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #5 on Thu 28 Aug 2003 09:02 AM (UTC)
Message
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").
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top
Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #6 on Fri 29 Aug 2003 09:34 AM (UTC)
Message
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.
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top
Posted by Nick Gammon   Australia  (22,982 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Fri 29 Aug 2003 08:56 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #8 on Fri 29 Aug 2003 09:31 PM (UTC)
Message
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?
[Go to top] top
Posted by Nick Gammon   Australia  (22,982 posts)  [Biography] bio   Forum Administrator
Date Reply #9 on Fri 29 Aug 2003 10:26 PM (UTC)
Message
The problem here is that each plugin takes a stab at the triggers and the sequence is within plugin, not overall.

However if you organised the right plugin to be first in the list - and not have triggers in the main world file - then it should work OK.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #10 on Sat 30 Aug 2003 06:17 AM (UTC)
Message
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...
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top
Posted by Nick Gammon   Australia  (22,982 posts)  [Biography] bio   Forum Administrator
Date Reply #11 on Sat 30 Aug 2003 08:05 AM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #12 on Sat 30 Aug 2003 10:34 AM (UTC)
Message
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
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #13 on Sat 30 Aug 2003 07:01 PM (UTC)

Amended on Sat 30 Aug 2003 07:03 PM (UTC) by Shadowfyr

Message
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.
[Go to top] top
Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #14 on Sat 30 Aug 2003 10:10 PM (UTC)
Message
I agree, I think it would be much better if you kept the old style until the triggers finished evaluating so that they match on the original color...
Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] 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.

21,769 views.

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

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

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]