Quote:

---

the second that I receive a var, that memory address changes regardless of which function you are on.

---

That's not true. The networking thread will receive a packet which contains the index of the variable, and its new contents. It doesn't have to update the var right away.

Actually, updating the variable right away would be a very bad idea. It makes much more sense to update the var right before the event function is executed (if there is no event function assigned, nothing is called but that's irrelevant). Updating the var as soon as you receive it would violate some basic rules of concurent programming. Some things that could happen:
-You don't know how much time the OS will assign to each thread, so it could very well be that two updates to the same var are processed by the networking thread (so the var is updated twice, if you are correct), before the script/engine thread is able to process the events -> lost update. (Think about that, it would be a horrible, random occuring bug, depending on how you use vars/events in your script)
-In the case of larger datastructures, it could be that the struct has only partially been updated when the OS switches to the script thread. The scripting thread could then read the inconsistent structure. This causes you to read structs in your events that where never sent, bad..


I think you have interpreted the manual wrongly (or you just want to be right very badly yea I know you ).

Quote:

---

After start of an event function, all event-dependent variables and pointers, like normal etc., keep their values only until the next wait instruction. During the wait pause they can (and certainly will) be changed by other functions. If you want to keep them longer, copy them to local variables or entity skills. For clarity, let the entities' main action do most of the work, and keep the event function as short and simple as possible, without any wait instructions.

---