AarchonWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Syntax: delay( seconds<number>, func<function> [, tag<string>] [, …] )

Begins a countdown to execute the provided function after the specified number of seconds. The provided function will run in the env of the actor, no matter what env the delay is invoked from. If the actor is destroyed by the time the function should run, it will simply not run.

Any number of arguments can be passed after the 'tag' argument and these arguments will be passed to the delayed function when it is called. As with the case of the env owner being destroyed, if any of the extra args are game objects that have been destroyed during the delay, the function will simply not run.

Example1:

<code lua>
function do_stuff()
  goto(31404)
  mdo("dance")
  goto(10204)
end

delay(10, do_stuff)
</code>

Example2:

<code lua>
delay(10, function()
            goto(31404)
            mdo("dance")
            goto(10204)
          end)
</code>

Example3:

<code lua>
delay(10, function()
            goto(31404)
            mdo("dance")
            goto(10204)
          end,
          "blah") -- Can target cancel just this delay with cancel("blah")
</code>

Notes: Remember that the delayed function will run in the env of the actor. Consider this example:

<code lua>
-- let's say it's an mprog, 'ch' would be a prog argument
mob:delay(10, function()
            ch:goto(31404)
            ch:mdo("dance")
            ch:goto(10204)
          end)
</code>

This will work fine, but would not run if 'mob' was killed/destroyed during the 10 second delay. In 10 seconds the CH that was 'ch' in this script will goto 31404, dance, then goto 10204. However:

<code lua>
ch:delay(10, function()
            mob:goto(31404)
            mob:mdo("dance")
            mob:goto(10204)
          end)
</code>

This one may not do what you expect. Since this will run in the env of 'ch', this will have the original 'ch' mob goto 31404, dance, etc. This has to do with the way closures work in lua.

[[http://www.lua.org/pil/6.1.html|http://www.lua.org/pil/6.1.html]] "When a function is written enclosed in another function, it has full access to local variables from the enclosing function."

So when you pass the function to delay, if any of the references in the function match 'local' variables then those will be passed into the function, but anything else will basically be evaluated when the function is run ( in the respective env ). 'mob' is a global variable in the env, whereas the script arguments (such as 'ch') are actually local variables to the prog (which is a function).

If global variables need to be passed to the delayed function, they must first be declared locally as below:

<code lua>
local lmob=mob -- the original 'mob' var declared locally to the prog function
ch:delay(10, function()
            lmob:goto(31404)
            lmob:mdo("dance")
            lmob:goto(10204)
          end)
</code>

Exploding mob:

<code lua>
-- EXPLODING MOB!!!!
-- 'kill' trigger
explode=explode or function()
    echo("The mob EXPLODES!")
    for k,v in pairs(mob.room.players) do
        damage("'%s' 2000 3000 lethal", v.name)
    end
    mob:destroy()
end

-- only start exploding once, it's all we need!
if timerStarted==true then return end
delay(60, explode) -- If mob isn't dead within 60 secs it will explode!
timerStarted=true
</code>

Since areas are never destroyed, AREA:delay() can be used to ensure that the delayed function won't be canceled due to game object destruction.

The actual delay time may be up to 1 second longer than the value provided. So delay(0, func) will run func 0-1 seconds after executed. See also [[:lua:cancelfunction|cancel]]

\\
**Passing arguments**

As mentioned, you can pass arguments along to the delay function and these will in turn be passed to the delayed function when it it called. While it's possible to avoid using arguments by using closures, it is better practice to pass arguments for 2 reasons:

  - Per notes above about closures, it's not always obvious which variables you are referencing are local to the outer scope (creating a closure) and which are global (no closure). Having your delayed function take arguments and explicitly passing arguments to the delay function is much more clear.
  - Any argument passed in this way will be checked if it's been invalidated (destroyed) before the delayed function runs. The function will not execute if any of the passed arguments are destroyed.

Example 4:

<code lua>
function ankhSpeech(ch)
  say("Well %s, I suppose then that the time is near.", ch.name)
  say("You've kept your word, and I will keep mine. The last step to ridding")
  say("your body of the curse is to reincarnate you. Once you're ready, give")
  say("me the Ankh. I'll use the power of the Ankh to open a portal to Irena's")
  say("lair. Once you've slain her, I'll use the Ankh to reincarnate you.")
end

if ch:carries(rvnum(5)) and ch:getval("r9_main_quest") == 6 then
  emote("stares at you, completely stunned.")
  say("%s... the... the Ankh. You found it!", ch.name)
  delay(2, ankhSpeech, nil, ch)
end
</code>

In above example, if the player logs out within the 2 second delay, the ankhSpeech will simply not run, rather than running and having a script error for referencing a 'ch' which points to a destroyed CH.