Zugg Software :: View topic

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

Some shops in Dragonreams work something like this:

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA

State 0 (pattern): in the whatever you see:
State 1 (pattern): blank
State 2 (within lines, param=1): ({An|Some|A} *) for (%d) (%w) ({Kronar|Dokora|Lirum})

Since State 2 will now only match on lines that are actually part of the list, there's no need to test for anything. The qn stuff can be handled in the below trigger on the [Type SHOP line.

There's a limitation with the withinlines type wherein if it expires without firing it always resets the trigger back to state 0 even when there are further states defined, but in your case you can just make a second trigger on the [Type SHOP line that gags this and the preceding blank if you desired.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

I think you missed the point. I'm not trying to modify the output in any way, and the first blank line is matching perfectly via regex \n.

When I type just "shop", it shows a list of containers - no telling how many (likely no more than 10 - I've never seen more than six in one shop)! I then want the script to automatically look in/on each container by sending "shop (container)". My problem is matching an unknown number of lines with the same {^(*)$} pattern, and stop matching when it receives a blank line. In my code above, I attempt to use the LoopLines parameter to match whether there's something there or not, then test the match to know whether to stop the looping and reset the multistate trigger to 0. It doesn't quite work, and I'm not sure why.

Sorcerer Joined: 15 Apr 2011 Posts: 809

Try changing your looplines trigger to a manual trigger. Manual triggers never change the state on their own, it must be done manually in the code, thus the name. You shouldn't even need to change your code at all, and it would be more reliable - it would match ANY number of lines between the two blanks, no matter how rare the chance of a shop having more than 10 containers is.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

What? Spell "bolor" with a "k"? "Kolor"! Oh, there we go! What a silly bunt!

Thanks, this solution was too obvious.

Enchanter Joined: 09 Sep 2007 Posts: 605

Why you can't have just 2 triggers - one simple text parsing trigger for containers and one for a blank line that will disable the first one and do things with data collected? After that second trigger can disable itself. There is no need for "loop lines" or other hard-to-debug options.
Make OnInput trigger for the "shop" command which will turn on both mentioned above triggers.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

Using the Manual parameter was the perfect solution, a single trigger to handle all of my shopping needs. I had never attempted to use that parameter except as the primary trigger, I'm glad to discover how to use it in later states.

Sorcerer Joined: 15 Apr 2011 Posts: 809

Yeah, manual triggers are great for capturing everything between two lines, I use it for things like room descs.

Enchanter Joined: 09 Sep 2007 Posts: 605

Very nice solution, Daern. I wonder how you handle a situation when there is no blank line after a list?

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA

Assuming you can match whatever ends the list, just change the state's trigger from ^({*|})$ to ^({*|End of list!})$.

Enchanter Joined: 09 Sep 2007 Posts: 605

You can't, because * will match everything. It doesn't match an empty string, but will match any other "end of list" string. And, while you can do ^({End of list!|*})$ instead, it adds 1 additional string match check per each trigger execution. Is it will be more effective (in terms of execution speed) than 2 separate triggers?

Can you see, in my MUD there is no blank lines after a list, and I have different approach to list parsing. In my system I have custom OnPrompt event that fires each prompt. I use it for many tasks and handle it whenever I need to. This way I can catch any "shop"-like command, turn list-parsing trigger on and then disable it with the OnPrompt event handler. Of course, I'm always looking for more speed-effective solution. If I'll find it, I'll definitely switch to it.

Sorcerer Joined: 15 Apr 2011 Posts: 809

Make the pattern of the trigger ^(*)$, then check in the code if it's the end of list string with %match. If it is, change state, if not, process it however is required. And FYI, * does match an empty string (including blank lines).

Enchanter Joined: 09 Sep 2007 Posts: 605

Sorcerer Joined: 15 Apr 2011 Posts: 809

First of all, ^(*)$ may be slow, but if it's only enabled when you're trying to capture every line anyway, what else are you going to do? Remember that when you have a multistate trigger, only the currently active state is considered enabled, and a disabled trigger doesn't have any speed impact at all. You don't need a pattern like ^({*|})$, just ^(*)$ will suffice. And it's true that dot matches any single character, but you didn't take into account the * - it means match 0 or more of the previous term. So .* will match anything, including nothing.

As for the speed of using %match in the trigger... if you have an event being raised on your end of list string anyway, I agree that it would be more efficient to reset the state in that event, and leave out the check for if the line is your end of list string in the manual trigger. As you said, %match is equivalent to having another trigger, and if you already have a trigger with that pattern to raise the OnPrompt event, you're just duplicating it.

Magician Joined: 23 Apr 2003 Posts: 358 Location: USA