Interspersing Hyperlinks with Simulate

My goal is an extremely heavy-duty replacement for simple "colorizer" triggers. When a name is matched (or the first word on each line of a player list for example), I want to turn it into a hyperlink that I can load up with hint text and a script when clicked on.

But unless there's a way to say "remove characters 20-28 from this line, and insert a hyperlink there", I need to match the entire line, omit it, and then rebuild it entirely.

Right now I'm using ColourTell, Hyperlink and ColourNote in order to output stuff I matched before and after the name in the world default color. Not ideal because it's hard to preserve existing colors, and other peoples' colorizer triggers won't function on Note-based lines.

I want to move to using Simulate and do my matching on packet received, but it seems like there's always a forced newline around hyperlinks. This:

ought to work; colorizers even work on the 'before' and 'after' parts just fine. But I can't use it unless I can remove the newlines that get forced around the hyperlink. Is there any way to do that?

Make your plugin run last by setting its sequence to be 10000 and that won't be an issue.

Their triggers run fine, and there's no problem for like...sound-based triggers. They still go off, but they trigger on the initial input. They won't modify color of a Note, which is what my script has to generate right now.

Try it yourself: Add a highlight trigger to 'longsword', then do:

The simulated message triggers the colorizer, the note does not. So unless I can make my plugin replace the incoming text with Simulate instead of with Note, colorizers won't work properly. (Never mind that I still want to preserve the ANSI of existing messages.)

there’s always a forced newline around hyperlinks

That’s by design, as different line “types” are made into new lines. For example, if you type a command, you don’t want it appended to the end of a previous line from the MUD.

The simulated message triggers the colorizer, the note does not.

Well, triggers are supposed to match incoming lines, not notes. If a trigger matched a note you might get into an endless recursive loop, if, for example, you happened to write a trigger that matched on “foo” and noted “foo”, which then matched a trigger, sent “foo” again, and so on until you got bored and force-quitted the client.

You could always make a version of Note that pushes what is being noted through trigger matching if you were desperate.

---

You might be thinking “but why can’t that be changed?” - the answer is that changing this sort of behaviour isn’t just a good thing for you and absolutely neutral for everyone else.

Let me give you a (somewhat unrelated) analogy. Say you are at an airport, waiting to catch your plane. Your luggage has been checked in and is in the hold of the aircraft. Unfortunately you didn’t hear the boarding announcement, and the calls for “Mr. Smith please go to gate lounge 10 immediately” until it is about one minute before departure time.

You rush down to the gate lounge and are denied boarding. Why? Because your bags have already been off-loaded, and they are not going to waste more time by putting them back on. And if they didn’t off-load your bags they might have a bomb on them and everyone on board might die.

There is no perfect solution. Maybe:

• You miss your flight
• Everyone is delayed, possibly missing further connections later on
• A bomb kills everyone on board because you had no intention of catching the flight

---

Similarly with the client. Changes like making simulated lines not trigger a newline would not be neutral. There may well be other people that are relying upon it working the way it currently does.

Maybe think of a different way of achieving your goal? For example, certain words could cause a miniwindow off to the right appear which has hyperlinks in it.

Hmm. Agreed that I wouldn't want to break existing expected functionality.

MXP turns some parts of the MUD output into Hyperlinks of a sort. Are they implemented the same way? Are MXP links / Hyperlinks implemented as styles?

Is there a way to adjust the styles of a line that's already been received, retroactively turning some text into a hyperlink? We can already alter the styles of received text by using standard colorizer triggers, so if a hyperlink is implemented as a style, that doesn't seem too far off.

There's a lot to build on, but I don't know of any current way that indices in an output line are addressed. Triggers can only retrieve the string content of the regex matches, and I don't think there's any way to even access 'get the most recent mud output line', let alone 'get the style object that is applied to character 10'. Just addressing whatever part was matched (the way colorizing triggers work now) isn't enough, either, since it needs scripts to figure out what the hyperlink content should be, and I only want to apply it to (for example) the second of three match groups.

I was hoping to keep my plugin within one window and with an absolute bare minimum of clutter, since I'm pitching this as a strict upgrade to colorizers, not a sidegrade.


I know I can do some stuff with OnPluginPacketReceived to replace some of the incoming text. But unless I can insert a hyperlink in there (which would be REALLY COOL), it doesn't quite work for me. Maybe there could be extra escape codes, ones not normally considered valid? That sounds a lot like "breaking expected functionality" unfortunately. I'm not sure how this would work. Hmm.

Yes, MXP uses HTML-like markup, and you could embed that into incoming text. For that to be recognized you would have to turn MXP on (you can configure it to be always on). You would then have the issue that things like <smile> would need to be turned into &lt;smile&gt; or they would disappear.

However the ability to script hyperlinks is restricted to internal hyperlinks (not MXP) in order to prevent people secretly running scripts or other unexpected things from a server (or indeed from another client if the server didn't properly escape things).

---

GetRecentLines (1) will get you the last received line.

---

You could conceivably delete the last line in the buffer and replace it with a note. The timing might be tricky, but see this:

http://www.gammon.com.au/forum/?id=6554

You really want the last "full" line (which might have wrapped over multiple screen lines). You can find out style runs of lines in the output buffer so you could save those styles when you re-assembled the line.

Also see GetLineInfo and GetStyleInfo.

---

What might be easier would be to make a plugin that has a high sequence number (and is thus run last) which omits all incoming lines from output, and replaces them with your amended line. By having it last in sequence all the earlier triggers would have matched.