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.
 Entire forum ➜ MUSHclient ➜ General ➜ StyleRuns
StyleRuns

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

Posted by WillFa   USA  (525 posts)  Bio
Date Wed 24 Jun 2009 04:55 AM (UTC)

Amended on Wed 24 Jun 2009 04:57 AM (UTC) by WillFa

Message
StyleRuns are frustrating me. :)

Why is the GetStyleInfo(linenum) table so much nicer than the TriggerStyleRuns and function MyTrig(t,l,wc,SR) tables?

Why is the documentation on TrigSR and SR table so hard to find? There's a blurb on the Edit Trigger page. It has "· style - style bits (bold=1, underline=2, blink=4) or'ed together (eg. bold underline would be 6)"
So what's Inverse? 8?

Okay, so the Ansi spec may call the bit Blink, but MC always renders it as Italics. Can we just call it Italics?

How come you can't match on underline?
Why can you match on Inverse? How can a user actually tell the difference between:
\1B[41m\1B[30mThis is a test.\1B[0m

\1B[31m\1B[7mThis is a Test too.\1B[0m
They look the same. By the way, a trigger that matches on Black on Red ambivalent about bold, italic, and inverse matches one and not the other. Does that generate any questions? Man, I just wizzed and I am SO gunna screw with people.



Just so this isn't just rabid venting...
Can you please change the TriggerStyleRuns and 4th param tables to the same table that's returned by GetStyleInfo?
Can "underline" and "match_underline" be added to a TriggerOption as well, please?


Thanks Nick. :)

p.s. Woo woo on 4.41! :)
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #1 on Wed 24 Jun 2009 05:55 AM (UTC)

Amended on Wed 24 Jun 2009 05:58 AM (UTC) by Nick Gammon

Message
Quote:

Why is the GetStyleInfo(linenum) table so much nicer than the TriggerStyleRuns and function MyTrig(t,l,wc,SR) tables?


GetStyleInfo has more information, I agree. Probably for speed because TriggerStyleRuns (and the trigger styleruns table) has to be set up for every line that is received. I think I omitted stuff that didn't seem to be very useful in making copies of the colours (eg. for copying to dummy windows or miniwindows).

To compare ...

GetStyleInfo:


1:
  "textcolour"=12632256
  "action"=""
  "backcolour"=0
  "starttag"=false
  "text"="<"
  "changed"=false
  "variable"=""
  "actiontype"=0
  "blink"=false
  "inverse"=false
  "bold"=false
  "column"=1
  "length"=1
  "ul"=false
  "hint"=""


The style run as passed to a trigger:


1:
  "textcolour"=12632256
  "backcolour"=0
  "length"=1
  "style"=0
  "text"="<"


Stuff like the hint, action and actiontype are only relevant to MXP. The column can be deduced by adding up the lengths as you go through the style runs (ie. the first one will be column 1, the second one will be the 1 + the length of the first style run, and so on).

The style types (bold, underline, etc.) are more quickly stored as an integer (which is how they are stored internally) and a simple bit.band operation can extract out individual bits.

Quote:

How come you can't match on underline?


I think I ran out of bits. The match information is stored in a 32-bit field, as defined in the source:


#define TRIGGER_MATCH_TEXT 0x0080   // high order of text nibble
#define TRIGGER_MATCH_BACK 0x0800   // high order of back nibble
#define TRIGGER_MATCH_HILITE 0x1000
#define TRIGGER_MATCH_UNDERLINE 0x2000
#define TRIGGER_MATCH_BLINK 0x4000
#define TRIGGER_MATCH_INVERSE 0x8000


In any case, you can match underline yourself by scripting a check on the style runs.

Quote:

Why can you match on Inverse? How can a user actually tell the difference between: [black on red / black on red done with inverse].


Er, it matches if the inverse bit is set, useful or not. I know you can simulate inverse by swapping the colours around.

Bear in mind some of this design is about 14 years old. It doesn't necessarily make any sense. ;)

Quote:

Can you please change the TriggerStyleRuns and 4th param tables to the same table that's returned by GetStyleInfo?


You are asking that for every incoming line, the program increases the number of items it has to put into the TriggerStyleRuns table (for each style, which might be 20 styles) from 5 items to 16 (we would have to keep "style" for backwards compatibility). This increase would apply to every plugin that uses Lua, which might increase the workload further.

I am concerned about a blanket increase in work like this, which apart from the time taken for Lua to make all these additional table entries for a once-off operation, also adds to the work it has to do in garbage-collecting later.

Quote:

Okay, so the Ansi spec may call the bit Blink, but MC always renders it as Italics. Can we just call it Italics?


I couldn't make up my mind whether to go with what the ANSI code is (blink) or how it is rendered (italic), as you can see.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #2 on Wed 24 Jun 2009 07:03 AM (UTC)

Amended on Wed 24 Jun 2009 07:04 AM (UTC) by WillFa

Message
Fair enough.

I think I found a bug with TriggerStyleRuns tho.
Inverse isn't in the style value, and backcolour and textcolour are the raw ansi values, not the applied ones.


<triggers>
  <trigger
   enabled="y"
   match="This is a test."
   send_to="14"
   sequence="100"
  >
  <send>tprint(TriggerStyleRuns)</send>
  </trigger>
</triggers>


Tested with:
\1B[36m\1B[7mThis is a test.\1B[0m

\1B[36mThis is a test.\1B[0m


Results in:
This is a test. --(black text on cyan)

1:
"backcolour"=0
"length"=15
"style"=0
"text"="This is a test."
"textcolour"=8421376

This is a test. --(cyan text on black)

1:
"backcolour"=0
"length"=15
"style"=0
"text"="This is a test."
"textcolour"=8421376
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #3 on Wed 24 Jun 2009 07:27 AM (UTC)
Message
Yes, I see what you mean. Now why couldn't you have found that 8 hours earlier? Then it could have gone into version 4.41. :P

I was swapping the textcolour and backcolour around, twice. So my code which set up the TriggerStyleRuns was being *too* smart. I removed the extra swap, and now it looks OK.

Fixed in version 4.42.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #4 on Wed 24 Jun 2009 07:58 AM (UTC)
Message
Cool! I'm almost glad this is fixed. ;)


So here's what I'm trying to do. (Again, I tried something similar 6 or 7 months ago, got frustrated and put it down :))

I'm writing a plugin for myself and a few friends. These friends have varying levels of savviness on scripting and trigger creation in general. This plugin is kind of an advanced, yet simplistic stepper (because 3Kingdoms has strict rules on botting). I'm trying to write some scripting so the plugin can configure itself for their setup.

It's an LDMud, and we have several optional ansi variables set. You can get a listing of ansi variables with 'setcolor -check' which outputs like:

example   look_monster           default        <ESC>[44m
example   look_player            default        <ESC>[41m
example   mage                   default        <ESC>[36;1m
example   mageschool             default        <ESC>[36;1m
example   melee                  default        <ESC>[31m
example   notify                 default        <ESC>[36m
example   party                  default        <ESC>[33;1m
example   room_exits             default        <ESC>[33;1m
example   room_long              default        <ESC>[33m
example   room_short             default        <ESC>[46m
                                                <ESC>[37;1m
example   say                    default        <ESC>[32m


'example' is in the ansi style, of course.


Here's what code I have so far, but I think I need to rewrite this with GetStyleInfo.

function ConfigTrigs (t,l,w,sr)
	local which = w[1]
	
	MatchColor = {}
	for i = 1,8 do
		MatchColor[GetNormalColour (i)] = i+7
		MatchColor[GetBoldColour (i)] = i+7
	end

	local  bold, ital, back, fore = "n", "n", 0, 0
	back = MatchLookup[sr[1].backcolour]
	fore = MatchLookup[sr[1].textcolour]
	if (sr[1].style % 2 == 1) then bold = 'y' end
	if (bit.band(sr[1].style , 4) == 4) then ital = 'y' end
	
	SetVariable(which .. "_back", tostring(back))
	SetVariable(which .. "_fore", tostring(fore))
	SetVariable(which .. "_bold", tostring(bold ))
	SetVariable(which .. "_ital", tostring(ital ))

	SetTriggerOption(which, "back_colour", back)
	SetTriggerOption(which, "text_colour", fore)
	SetTriggerOption(which, "bold", bold)
	SetTriggerOption(which, "italic", ital)
	Save()
end



So TriggerStyleRuns will have the rendered values in textcolour and backcolour as of ver 4.42. But the PCRE colour matches still match on raw ansi.
"Black + Back Red" isn't a match with "Red + Inverse" if you're ambivalent about inverse matching. So the above will potentially have bad configurations. :(
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #5 on Thu 25 Jun 2009 02:20 AM (UTC)

Amended on Thu 25 Jun 2009 03:57 AM (UTC) by WillFa

Message
Would it possible to change this in ProcessPreviousLine.cpp around line 977. (I have an older version of the source, and am unsure if it changed)


        if (trigger_item->iMatch & TRIGGER_MATCH_TEXT)
          if (get_foreground (trigger_item->iMatch) !=
              (iFlags & INVERSE) ? iBackColour : iForeColour )
            continue;   // wrong text colour
        if (trigger_item->iMatch & TRIGGER_MATCH_BACK)
          if (get_background (trigger_item->iMatch) !=
              (iFlags & INVERSE) ? iForeColour : iBackColour)
            continue;   // wrong background colour


I don't have VC++ installed, so I haven't tested if this actually compiles. It should in theory. :)

This change makes color matching coincide with the values in TriggerStyleRuns, GetStyleInfo, and the drawing routine. Although it makes a literal match on \1B[36m\1B[7m -> "Cyan on Black, Inverted" iodiomatic, as you'd need to match Black on Cyan - the result.
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #6 on Thu 25 Jun 2009 04:31 AM (UTC)
Message
Yes, that looks OK, but you have changed the sense of it slightly.

Previously, you could test for (say) red on black normal, or red on black inverse (but you would have to swap the colours around).

Now what you are saying is, if you want to match red on black, and you *see* red on black, then you want to match, regardless of whether the reason you see red on black is it is red on black normal, or black on red inverse. Is that it?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,122 posts)  Bio   Forum Administrator
Date Reply #7 on Thu 25 Jun 2009 04:33 AM (UTC)
Message
Potentially if someone was allowing for the inverted behaviour this will muck them up. That is, they might have specified black on red (and inverse) to get the effect of matching on what looks like red on black.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #8 on Thu 25 Jun 2009 05:02 AM (UTC)
Message
Pretty Much. I want to alleviate the situation where:

You see red on black.
You double check this by checking TriggerStyleRuns, which says it's red on black.
You Triple check this with GetStyleInfo(GetLinesInBufferCount()) and it confirms that indeed it is red on black.

But your trigger doesn't match because it's actually inverted black on red. You don't care about Invert and left the tri-state gray.


I think that's a much more common scenario then someone actually knowing that an invert ansi tag is sent and having the tri-state set to true.

Incidentally, GetStyleInfo() will say it's red on black, and invert is true, and that isn't what ansi tags are sent. So, if you actually want to match on invert, you'd make the trigger agree with GetStyleInfo(line,0).



I think that potential someone that has a trigger set up for black,red, and inverse way will have done so only after trying red on black first and have it not work.
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.

23,076 views.

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