Timer script triggers w/ arguments?

[Foxley]

I'm trying to call a script trigger from a set timer, like so:

Code: Select all

set timer (i, 0, 5, @hurt flash(ref, i))

I'm passing it a couple of arguments. Here's what hspeak has to say about it:
"Found unexpected pair of brackets containing 2 expressions. Either the
brackets should not exist at all, or should only enclose a single expression"

So I'm wondering, can timer script triggers not use arguments? Or am I just typing this completely wrong?

[Bob the Hamster]

The syntax error is because you cannot pass any arguments to the script when you write @scriptname

There is no way to pass any arguments to a script that is being triggered by a timer, other than the timer id which is automatically passed to the first argument.

However, we can probably come up with some other way to accomplish what you are trying to do. You can get your "i" variable from the argument, but you will need some other way to communicate the ref to the timer.

[Foxley]

Alright. The NPC ref is the important one, I could do something like duplicate the timer scripts if need be, even if it looks terrible.

[Bob the Hamster]

What is the range of timer scripts you are using? What are the possible values of i ?

[Foxley]

I'll just kind of clarify exactly what I'm trying to do (without actual scripts for now, I kicked my USB drive on accident and kind of borked it):

I wanted to set aside 5 timers for NPCs/enemies flashing after taking damage, for their invincibility period. The i is in a for() loop doing "if read timer (i) == 0, then set timer (i, 0, 5, flashythings)". So i could be 1-5. I was also going to use a fake slice array with 5 children to hold the flashing/invincibility counter extra data so it only flashed a certain number of times before setting the enemy vincible again.

So the answer to both your questions is five.

[Foxley]

I've decided to not use timers, I made NPC flashing scripts that update per frame instead. Now I'm having horrible issues with those too, but I'll make another thread for it.

[Gizmog]

The syntax error is because you cannot pass any arguments to the script when you write @scriptname

There is no way to pass any arguments to a script that is being triggered by a timer, other than the timer id which is automatically passed to the first argument.

However, we can probably come up with some other way to accomplish what you are trying to do. You can get your "i" variable from the argument, but you will need some other way to communicate the ref to the timer.

I don't know anything about timers, so excuse my ignorance, but why wouldn't RunScriptByID work?

[TMC]

runscriptbyid and settimer are the two most common commands that take script IDs as arguments, but the difference is only runscriptbyid lets you pass some extra arguments along to the script. You can't use the two commands together in any way, if that's what you mean. If the question is "why can't settimer store some arguments and pass them along to the script later, like runscriptbyid?" the reply is "no reason; that would be easy to add".

[Gizmog]

runscriptbyid and settimer are the two most common commands that take script IDs as arguments, but the difference is only runscriptbyid lets you pass some extra arguments along to the script. You can't use the two commands together in any way, if that's what you mean. If the question is "why can't settimer store some arguments and pass them along to the script later, like runscriptbyid?" the reply is "no reason; that would be easy to add".

Oh, no, my problem is I forgot how timers worked. I didn't realize you could pass a @script directly to the timer and it would run it at the end. I was thinking that he could use RunScriptByID instead of his regular script to pass arguments, but how could he pass arguments to RunScriptByID? He couldn't for the same reason. I was just dumb!

[TMC]

Funnily enough, "why not use runscriptbyid with settimer" was also my first thought for a second.

I am working on something called closures in the new script interpreter that will actually let you write

Code: Select all

subscript, temp, begin
  hurt flash(ref, i)
end
set timer (i, 0, 5, @temp)

And I would probably add shorter syntax to do the same thing.

[Bob the Hamster]

Nice! Closures will come in handy. I use those often in my python code.

Would a plausible short syntax be something like?:

Code: Select all

set timer (i, 0, 5, closure(hurt flash(ref, i)))

[TMC]

I was thinking of lambda expressions. Except I don't like the name "lambda", because it comes from lambda calculus and almost noone knows lambda calculus.
It looks like your closure() syntax is just a lambda expression with no arguments?

Here's something I wrote up a while back about possible syntax for lambdas: http://rpg.hamsterrepublic.com/ohrrpgce ... S4#Lambdas

[Gizmog]

Oooh. Lambada, the forbidden Calculus! My opinion of this feature has taken a 180 for the better!

[Mogri]

I was thinking of lambda expressions. Except I don't like the name "lambda", because it comes from lambda calculus and almost noone knows lambda calculus.
It looks like your closure() syntax is just a lambda expression with no arguments?

The difference between a lambda and a closure is that a closure can access the scope of its parent. In scope-permissive languages like JavaScript, there's no distinction. Since we don't have nested scripts in HS, there's no precedent, but I'd prefer closures to lambdas.

The ECMA6 syntax has grown on me, although it took some getting used to:

Code: Select all

[b]x => x*2[/b]
is equivalent to
[b]function(x) { return x*2 }[/b]

[b](x, y) => {
  while&#40;x<y&#41; x+=10
  return x
&#125;&#91;/b&#93;
is equivalent to
&#91;b&#93;function&#40;x,y&#41; &#123; ... &#125;&#91;/b&#93;

(actually, they aren't 100% equivalent because the this object binding is slightly different, but that's splitting hairs)

Something similar would make a tidy shortcut syntax here as well.

[TMC]

Actually we do have nested scripts in HS, using the subscript syntax. They are lexically scoped but can not yet form closures, because there is not yet a way to obtain a reference to a subscript (and the main reason for that is that it requires garbage collection). A lambda expression by definition evaluates to a callable object (although it could just be a script ID, I'm moving to objects instead of IDs), and hence can potentially form a closure, which is why I mentioned them, but I am aware that they are completely different things.

I also think the syntax using -> or => is nice. I guess => is better than -> if it's more common. x, y -> x.type == LATENT could be tricky to parse, so I also listed (x, y) -> x.type == LATENT instead.

I'm very happy to discuss this, there's a lot of decisions to be made, which I plan to slowly send out to the OHR mailing list.

Closely related to lambdas are list comprehensions. I'm not sure whether to imitate Python/JS syntax as closely as possible, or use a more HS-typical syntax like "newlist := foreach(iterator, list) return(expression)" (to mirror a new "foreach(iterator, list) do(...)" construct)