StyleRuns

Posted by WillFa on Wed 24 Jun 2009 04:55 AM — 9 posts, 32,164 views.

WillFa USA Wed 24 Jun 2009 04:55 AM #0

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! :)

Nick Gammon Australia Forum Administrator Wed 24 Jun 2009 05:55 AM #1

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.

WillFa USA Wed 24 Jun 2009 07:03 AM #2

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

Nick Gammon Australia Forum Administrator Wed 24 Jun 2009 07:27 AM #3

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.

WillFa USA Wed 24 Jun 2009 07:58 AM #4

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. :(

WillFa USA Thu 25 Jun 2009 02:20 AM #5

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.

Nick Gammon Australia Forum Administrator Thu 25 Jun 2009 04:31 AM #6

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 Australia Forum Administrator Thu 25 Jun 2009 04:33 AM #7

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.

WillFa USA Thu 25 Jun 2009 05:02 AM #8

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.