[ichthys]

oh and guess what, player_connect runs for bots when theres a map change.

[ajax]

Originally Posted by ichthys Event_vars are "zoned"..... (I think ) BUT as soon as you es_xdelayed you are not directly expanding the vars and therefore when the delayed command is executed the event_var might be chaged.

but wouldn't a really long sequence of commands triggered by an event be the equivalent of a delay, albeit a small one? or does the command es_delayed specifically and directly take it out of the loop?

[ajax]

Originally Posted by ichthys oh and guess what, player_connect runs for bots when theres a map change.

interesting. as long as it runs bot disconnects before the map change, that shouldn't cause any logistical problems.

[Mattie]

Originally Posted by ajax Originally Posted by ichthys Event_vars are "zoned"..... (I think ) BUT as soon as you es_xdelayed you are not directly expanding the vars and therefore when the delayed command is executed the event_var might be chaged. but wouldn't a really long sequence of commands triggered by an event be the equivalent of a delay, albeit a small one? or does the command es_delayed specifically and directly take it out of the loop?

Noooo-- a long sequence of commands triggered by an event would not be a delay. When you're inside player_say.cfg, you execute within a single event. No other event .cfg file should run while you do that and all the information you have will be fine for that event_var().

es_delayed takes you completely out of the event loop. You are now executing during GameFrame and not during the event itself (or not as near to it as before). There's no pretty way at all I can maintain the event state across es_delayeds, so you need to expand event_vars() right away before 'leaving' the context of the event.

Imagine this code in player_death.cfg:

es_msg event_var(userid) is here.
// ... any number of commands.
es_msg event_var(userid) is still here.
es_xdelayed 3 es_msg event_var(userid)-- eh? who knows?

This would run like this (sorta):

• 1. Valve fires the event
  2. EventScripts listener is passed the event
  3. EventScripts determines which cfg file to run and saves event information (including extended variables)
  4. EventScripts runs player_death.cfg
  5. first es_msg runs and outputs the userid provided in player_death
  6. ... other stuff runs with the same event information
  7. last es_msg runs and outputs the userid provided in player_death
  8. es_xdelayed schedules "es_msg event_var(userid) ..." to run in 3 seconds.
  9. Control returns to the game!
  10. Valve fires other events, kicks players, handles server commands, processes game state, movement, etc.
  11. Valve asks plugins if they have anything they want to do during each GameFrame, and after three seconds, EventScripts speaks up during one of those and runs your es_xdelayed.
  12. At this point, when es_msg tries to expand event_var(userid), any number of events could have happened to change that information.

As you can see, es_delayed kicks you (necessarily) into the future and out of your current event. As such, the same event informaton isn't available. (I never realized this wasn't widely known, but I can see now that it wouldn't be clear to those who haven't worked with Valve's plugin architecture.)

It's theoretically possible to save the exact event state that went with es_xdelayed in the first place to recall later, but that would be pretty much the same as using es_delayed. I.e., there's really no way that es_xdelayed can really take advantage of 'late' evaluation of event variables, so no one should rely on it for that sort of thing. Of course, server variables persist outside of events, so they really don't have any caveats here-- you can access them whenever you want and they'll reflect that precise instant's state of that variable.

-Mattie

[ajax]

okay thanks for clarifying.