enigma-dev/enigma-dev — pull request #778 by sorlok (2014-07-18 06:15:07+00:00)
Title: other.var fix

Please read this carefully!

This pull request contains two fixes. The first is a simple optimization: "enigma::place_meeting_inst()" is called twice, with the exact same parameters, in the collision detection routines. I'm fairly sure this is safe.

The second one fixes the following code:
```
//In the collision code:
with(other) { myvar = 2; }
self.savedvar = other.myvar; //self.savedvar will be 0 instead of 2!
```

Note that GameMaker:Studio shows the correct value of 2. Also, note that other's value *is* actually set correctly by the with(other) block; it's just the direct access afterwards that fails.

After tracing the issue down, I realized that we have the following confusing bit of code in the generated object_access file:
```
//Snipped from generated object_access function for myvar:
object_basic *inst = fetch_instance_by_int(x); //Here, x is "other".
if (inst) switch (inst->object_index)
{
case obj_something_unrelated: return ((OBJ_obj_something_unrelated*)inst)->myvar;
case global: return ((ENIGMA_global_structure*)ENIGMA_global_instance)->myvar;
default: return map_var(&(((enigma::object_locals*)instance_event_iterator->inst)->vmap), "myvar");
}
```

So, we retrieve the object_basic instance, but then in the default case (which is what is triggering here), we return the instance_event_iterator's instanced vmap? That doesn't make any sense; even if we wanted to use the instance_event_iterator, it would be available through "self", which would have been passed into the object_access function as "x".

I changed the "instance_event_iterator->inst" to just the "inst" retrieve earlier, and everything works. I also re-compiled Iji (which has a ton of indirect object access) and the game became more stable. So I have every reason to believe this is a good idea. But I'm not 100% sure, so please double-check and let me know if there's actually a good reason to use instance_event_iterator->inst.