Detecting selfcast spells

[Woden]

Is there an established technique for determining whether a given spell was selfcast or cast on you? Specifically, I'm talking about immediately after waitfor returns the spell's start message.

I'm thinking of something like using reget to scan back a few lines looking for "gestures at you", but how reliable is reget?

[Renian]

They have different messages when cast on you. You could also waitfor the "gestures at you" phrase versus the "you gesture".

Also, Lich does NOT save the times of spells cast by others correctly.

[Woden]

How would get work in this context? If I waited for "gestures at you" or "you gesture", when waitfor is triggered, could I use repeated gets to step through the subsequent lines until a spell message is found?

[Renian]

Yeah, or a matchtimeout.

[Shaelun]

I'm thinking of something like using reget to scan back a few lines looking for "gestures at you", but how reliable is reget?

It's not 100% reliable... I mean it is, but it's subject to certain nuances. Let me explain.

If it helps you visualize what's going on, every line that shows up in the game window is stacked, in order, on a "pile" (which is ultimately all an "array" amounts to). That pile then waits for a script to check it -- the get command will return the first unchecked line. It's accessing what a programming course would call a FIFO "pipe" or "queue" or "stack" -- first in, first out.

The thing is, reget doesn't work off of the same stack. It works off of the latest line sent by the game -- so a reget command will always work backward from the latest game line, regardless of whether or not your script has actually gotten to that line in its own personal pile of lines (the aforementioned FIFO). I made it more so that a script you started could access stuff that happened before said script had begun running. In practice it's an almost useless feature, since Lich could conceivably run a thousand scripts at the same time with no problems, but it was a cool idea at the time, heh...

The short answer to your question about waitfor followed by subsequent get commands is "yes." That stack will be exactly the way it looked in your game window, and your script can count on that when it uses get.

... hopefully reading this helped you understand more things than it made you confused about.

[Woden]

Excellent, thanks very much for the info, Shaelun. That helps very much.

Now the next question: assume that a script calls get, and the newest game line is returned. Given the execution speed of Lich, it's virtually guaranteed that the next get that is executed will not have any newer line to return. So what happens? I'm hoping that the answer is, "get waits until there is a newer line, then returns it."

Speaking of multithreading, that reminds me of something else I've been wondering about. When a script executes a waitfor or one of the related commands, does the other code in the main loop continue executing? In my case, I'm specifically wondering if I can waitfor an array of lines while simultaneously watching a timer.

Thanks again for your help. : )

[BigWorm]

Excellent, thanks very much for the info, Shaelun. That helps very much.

Now the next question: assume that a script calls get, and the newest game line is returned. Given the execution speed of Lich, it's virtually guaranteed that the next get that is executed will not have any newer line to return. So what happens? I'm hoping that the answer is, "get waits until there is a newer line, then returns it."

Speaking of multithreading, that reminds me of something else I've been wondering about. When a script executes a waitfor or one of the related commands, does the other code in the main loop continue executing? In my case, I'm specifically wondering if I can waitfor an array of lines while simultaneously watching a timer.

Thanks again for your help. : )

No, you would have to fork another thread to do two things at once.

[Shaelun]

Excellent, thanks very much for the info, Shaelun. That helps very much.

Now the next question: assume that a script calls get, and the newest game line is returned. Given the execution speed of Lich, it's virtually guaranteed that the next get that is executed will not have any newer line to return. So what happens? I'm hoping that the answer is, "get waits until there is a newer line, then returns it."

Speaking of multithreading, that reminds me of something else I've been wondering about. When a script executes a waitfor or one of the related commands, does the other code in the main loop continue executing? In my case, I'm specifically wondering if I can waitfor an array of lines while simultaneously watching a timer.

Thanks again for your help. : )


As for the first question, that's precisely what happens: the script waits for a line to return. Well, to be precise, the script actually stops executing until the core of Lich starts it back up again when there's a line to return. It's usually referred to as a "callback," and its why Lich can run dozens of scripts and still use less CPU time than a single Wizard script (technically, scripts aren't actually using the CPU at all most of the time.)

BigWorm is quite right. The reason for that behavior is that every script is, technically, just a thread of the core Lich program -- that thread encapsulates the execution context/environment. It's really a lot simpler than it sounds, heh. So when a script is paused or is waiting for a line to return with get or what have you, the entire thread is basically frozen; that's why you'd need to have the script fork off its own thread (with Thread.new -- multithreading is pretty low-level, but by all means, look it up in any Ruby documentation for details.)

Do bear in mind though that if you're going to be using multiple threads, that all threads associated with a given script share things like the stack that get works with. It's perfectly safe to have multiple threads playing with the same variables, but unless you get into things like mutexes and condition variables, you can't depend on a certain execution order.

If you're curious, when you kill the thread that originally "forked" off its own subthread, the subthread will be killed along with the original script thread (as would any other subthreads that were spawned).