Mudlet - Forum

We have a line spacer pattern which will have the trigger engine skip # lines before matching the next pattern, and the line delta, which gives a "line space" for the whole thing to complete in.

I'm thinking that a time spacer pattern would be useful - put the time in seconds, can be decimals, and the next pattern won't be matched until the time expires. Reasoning behind this is sometimes you don't know how many lines will come before the next pattern - in a lot of spam, it can be a hundred, in no spam, it can be zero. But you do know the approximate time that it'll come (if it's reliable) - hence the use for this pattern.

I could think of a ton of uses for this.

This idea doesn't work because you can't have have 2 unknown variables (line delta + time pattern). If line delta is undefined you'll end up with millions of match states and none of them will ever get deleted. And if you define a line delta, the match state might get deleted before the time pattern has been reached.

This is specifically a pattern, not a vague delta thing.

I can actually implement this on the lua side. I'll post code when I get home from work.

Vadi wrote:This is specifically a pattern, not a vague delta thing.

If it's a general pattern people will want to use it in the context of our state machine and this is impossible or doesn't make any sense whatsoever as stated above.

It'll be used as a time spacer pattern... just because people might want to use it as a general condition for the whole trigger to match in, which brings confusion with line delta (or or and), doesn't invalidate it's use as simply a pattern.

Match states are being cleaned up when the line delta is reached irrespective of their current state. The only way time patterns would be possible with Mudlet's line based state machine would be if we reset the line delta to 0 after a successful time pattern match as you don't know how many lines you'll get in x seconds (otherwise you could solve your problem with a simple Lua condition that checks for timestamps + a subsequent regex pattern). This, however, just postpones the problem of garbage collection. Let's say line delta = 3, #1 time pattern 5 seconds, #2 regex "asdf" This means that the match state is gc'ed after 5 seconds + 3 lines from the MUD. If you don't know how many lines pass within 5 seconds, how can you know how many lines pass after 5 seconds before your regex trigger can match or gets gc'ed? Consequently, the time pattern suggestion only leads to unreliable triggers.

I know, not exactly what you wanted, but it works.

It'll get gc'd when the 5 seconds pass and there are no more patterns, if any. Otherwise, it'll continue trying to match the patterns and it's normal from there.