Short of writing a plug-in system for external scripting languages, you will not find windows within TF. There are, however, a few simple things you can do to make it easier to keep track of your macros.

• Save every macro, trigger and so forth that you use into files, and have them load automatically when you connect. At the very least you will be able to use different files to organize your system. This also has the advantage of allowing you to use comments to remind yourself of the intended usage of files and macros.
• prefix all of your macros! if you have multiple variables for balance, prefix them with 'v_bal_'. You can use '/listvar v_bal_*' to see them all, and their values. for triggers i prefix with t_, for variables v_. I do leave macros without prefix though, for ease of use.

As for grouping, you can simulate grouping using variables and the -E option of a /def. -E is an expression, and the macro body will only be executed if the expression returns true.

So, to create group "curing",

1. make a variable v_curing_group, set it to true on creation. Then, on every /def statement for your curing, start it like this: /def -E(v_curing_group). Before the body is executed, v_curing_group will be checked.
2. Create a macro that sets the value of v_curing_group to be on or off.

It's not comprehensive, but it does allow you to selectively turn groups of triggers on and off.

You two have been extremely helpful, thank you greatly Neerth, that looks like a monster of a code I'm slowly getting used to all these strange coding syntaxes, but I'm glad I made the switch to tf.

Edit: Hmm okay, tf isn't saving any of the scrollback at all, so when I scroll back all I see are empty spaces save for the system messages that were sent before connecting to tf. The text gets cut off right at the top of the screen, so that when I view a long help file or do recall more than 45 or so lines (the height of the screen), I can't see anything before that. Visual mode is on, and from what I can see in the documentation, the output is supposed to scroll separately while keeping a small window with the current text (sort of like zMud)? But in either case, something doesn't seem right.

Use PgUp and PgDn to scroll through your text.

Also, if you want to scroll by half pages, add this to your .tfrc:

Ah I see now... the PgUp and PgDn keys on my computer are the same as the up and down arrow keys so it requires two keys to be pressed at once... and for some reason tf doesn't recognize that so I was paging up and down the terminal but not the world itself. How annoying

Edit: Oh wait a minute... I needed to add an extra 'shift' key in there too. Learn something new about my computer everyday

You might consider redefining your up and down keys to be pgup and pgdn then, so you don't have to hit two keys to scroll. Personal preference, though.

Yeah I thought about doing that, but then... which keys will replace the ones for cycling up and down the input history? Ah well it's not too bad. Now I'm going to focus on tackling that balance check script... starting with the prompt!

you could just redefine the esc_key_up and esc_key_down macros to scroll through the command history. You'd just have to look up the command for the history interface.

All right, time to start making triggers. Quick question, how do you apply the attributes/commands of a trigger to multiple lines at once? E.g. I want to hilite all the messages for balance and equilibrium recovery in bold, or I want to a single trigger to do ' eat pennyroyal' for all the different affliction messages without making a seperate line for each one.

Note: Is this the right way to write a trigger?

/def -t"You must pick yourself off the ground first." = stand

In the help file I see two parts after the trigger message, like they use 'greet = wave to %1' to define the macro greet, but when I do 'stand = stand' the trigger doesn't work. I'm not sure if it's better to make triggers fire with macros or fire by themselves.

Lets pick that apart:

CODE
/def ...
• Begin the definition
  
  
  CODE
  ... -mregexp ...
• Set the match type to regexp. You can also use -mglob to set it to glob matching, or nothing at all to leave it at the normal match type (which defaults to glob).
  
  
  CODE
  ... -aBCred,Cbgred ...
• -a starts attributes. B is for bold, C for color, Cbg for background color. The comma seperates attribute groupings so you can do both fore- and back-ground colors. /HELP attributes will give you a comprehensive list of possible attributes, but here's a short list of useful ones:
  L = do not add the line to your log
  g = gag the line
  C, Cbg = fore- and back-ground colors respectivly
  u = underline
  
  
  CODE
  ... \\ ...
• any time \\ is the last character in the line, it represents a linebreak so that one line can span multiple in your macro files, it's just a mechanism for making the definitions easy to read.
  
  
  CODE
  ... -t'You must pick yourself off the ground first\\." ...
• This is the trigger line itself. Note that the last period has to be escaped, because '.' is a special character in regexp.
  
  
  CODE
  ... t_needtostand ...
• This is the trigger's name. Always give your triggers a name, otherwise manipulating them from within tinyfugue becomes needlessly difficult.
  
  
  CODE
  ... = stand
• Everything after the '=' is the macro's body. Multiple commands must be seperated by '%;'

Now, you might wonder why I choose to use regexp in that example. The answer to that question is also the answer to how you can get multiple lines to fall under the same trigger. Without a long explanation of what regexp is, in case you already know, you can simply define your trigger like this:


Edit: Fixed the mis-matched quotation marks. That's what I get for spending more time worrying about formatting than about double-checking my code.

I'd suggest


First the opening and closing quotes must match, single or double - that's just a typo. What the ^ does is only look for matches where the following text starts at the beginning of a line. That goes a little faster (though I've never experienced much slowdown from triggers in tf) and prevents matching some, admittedly bizarre, situations. Also, there doesn't seem to be much sense in looking for the final period if we're willing to accept several variants. If we wanted to insist that the sentence ended right after "equilibrium/balance", we could do this:


There's our period back again, and $ is like the sibling of ^ ... $ means this has to be the end of the line.

meh, double post

Aah, so let me see if I got this right (I have a little familiarity with regexps but I'll read more on it later)

If I want a trigger to cure all afflictions associated with pennyroyal, it'd then be like...



?

Edit: I just used the script you postd on the previous page, Neerth, and I have to say... that is pretty cool! Though a few don't work/work properly, but it's probably my strange keyboard...

I agree, using the caret to start is faster because of greed issues with regexp, and you should make a practice of it. If you look for the end of the line as well, you should end with $ (or end-of-line) to make the trigger even faster.

Though, I usually leave it off, and specifically look for the period, for people just getting started with regexp to make it a little closer to globbing. Seems to make the transition slightly easier.

A lot of people do this, but to be honest with you I don't recommend it for entire lines. Because of the way regexp works, you can actually face some slowdown and eat more memory if you do this. For partials and mid-line variants use the or separated lists, for entire lines use a separate trigger, and make sure you encase it with ^...$. There will be a slew of people that well tell you I'm wrong about this, but I offer you what I've seen from personal experience.

As a reference: this is my basic outline for an affliction:

Two questions this time:

How do you make a trigger fire only once when it matches a list of possible trigger lines? For context, I'm trying to make a trigger automatically set my target when I do 'info here' in a room full of many of the same mobs.

And the second question would be on how to make a basic queue, like healing multiple afflictions in an orderly fashion when you do 'diag'. I tried setting priorities but they still all fired at the same time. Just a small push in the right direction will help!

The first work-around that comes to my mind, without having really thought it through, is to use a variable requirement and have the trigger turn that variable off. You could then use the prompt trigger to turn it back on.


That prompt trigger, by the way, would require any other prompt hooks you have to have the fall-through option on (-F), so that they all process correctly on the hook.

Essentially it will catch the first instance of the trigger, set the acquire variable to false, and until the prompt is caught again not process any more of the lines.



I will not go into detail on this, because you've asked for a small push. If you want more detailed information, I can walk you through a TF queuing system step by step, with priority checking and such.

Essentially, just contemplate the following facts:

• Lusternia has multiple types of healing methods.
• Lusternia has balances for each type of healing method.
• Afflictions are static; their effects and cures do not change as a general rule.
• TinyFugue supports conditional programming (read: /if, /elseif)

Put your mind to it, and do some research on how /if and /elseif work. The answer will come to you. Or you can just ask me to stop being cryptic.

Awesome, thanks for the speedy reply! I guess I'll be spending some time to play around with /if and all those other fun commands.

And I meant to ask this in the previous post though forgot, but can you set triggers to match colours as well? Because in the 'info here' example, once I trigger to have the target set, I want to hilight the name in red, and when I do 'info here' next time I'll avoid the red names and have the trigger catch new numbers. I suppose there are other ways to do this, but this sounds like the most convenient method (if possible).

That would be needlessly complex. In order to remember which names need to be colored, you'd have to save them somewhere. If they're saved somewhere, you can just reference that information. Trying to color and then act on the color would not only be redundant, it would be complex and unwieldy.

Why does it seem like I always come upon seemingly trivial problems...

This time I'm trying to do a simple regexp hilite.

/def -ahCred -mregexp -t"couch"

It still matches an entire line with the world "couch" in it. I read the regexp tutorial and this looks like the right way to match an exact string of characters. Is there some other setting I need to check? I also find it a little hard to match items in 'info here', it just keeps hiliting the whole line as bold (without colour), though oddly when another coloured hilite goes off, the colour appears in 'info here' for one instance. Though I guess once the above issue is resolved it should work itself out.

Drop the 'h' in your attributes. The hilite attributes always catches a whole line and colors it based on a system variable. It's trumphing your C attribute.

This will do what you want it to do.