setTimer() and queue()

[aubergine]

Both of these functions accept an optional game object as their last parameter.

This to me seems absurd, because there is no guarantee that the game object will still exist when the timer or queued call gets triggered. What happens if that object gets wiped off the map before the function gets called? If the object gets destroyed the timer or queued function call is cancelled.

For example:

Code: Select all

function makeVictimRunAway(victim) {
  // do stuff using passed in victim object
}

eventAttacked(victim,attacker) {
  queue("makeVictimRunAway",victim); // what if it explodes next game tick?
  // or...
  setTimer("makeVictimRunAway",1000,victim); // even more absurd
}

IMHO the object parameter on the setTimer() and queue() functions should be removed.

[NoQ]

The function doesn't get called. I think this was mentioned in the pdf doc:

If the game object dies before the queued call runs, nothing happens.

[aubergine]

Yup, just spotted that. However, I still don't see any benefit in having that object parameter in the first place?

[aubergine]

Also, removeTimer() takes a function name - what if you only want to remove one specific timer associated with that function, not all of them?

And as queue() uses setTimer() internally (IIRC?) then am I correct in thinking that removeTimer() will also clear any queued calls to the function as well?

[Per]

I'm not sure what is absurd about calling queue() or setTimer() on a specific game object, and it not running when the game object dies. If you don't want that behaviour, don't pass it a game object parameter? It seemed sensible to me, even though I haven't used this feature yet.

You are right about removeTimer(). Maybe it should take an optional game object parameter as well.

[aubergine]

So, "absurd" was too harsh a word to use, sorry. I was trying to convey that I couldn't determine a reason for passing in a game object.

I guess there might be uses for it in terms of micromanaging units, but the code could get scarily complex quite quickly.

In normal Javascript, setTimeout() returns a unique ID for the timeout, which can later be passed to clearTimeout().

Maybe setTimer() and queue() could return a unique ID. And then extend removeTimer() so that if a string is passed in (function name) all timers/queued funcs relating to that function are cleared, however if a number is passed in then only that specific timer/queued func gets removed?

[aubergine]

@per - could these two functions be updated so they can accept either a string or a game object as the "object" param?

Currently I need to spawn a function for each deferred job, because it's the only way I can determine what should be done for a given function call. I want to have a single function on global that handles "deferred jobs" for my AI: If I can pass a string in as "object" param it would allow me to have a single function that looks up that string in an object to work out what needs doing.

EDIT: Or keep the "object" param same as it currently is and add an additional optional param which can take a string. That way I can pass a game object (optionally) and a string (optionally).

[aubergine]

@Per - also you mentioned in another topic that the timers/queued functions get stored in savegames and that if a game object was passed to them that the .id and .player properties are all that gets stored.

I thought .id was globally unique, across all players - if so, why is the .player property stored in savegames?

[Per]

I thought .id was globally unique, across all players - if so, why is the .player property stored in savegames?

Much faster lookup time. Objects are stored in multiple linked lists. (Changing that would probably be a good idea some time.)