0
Not a bug

Many Triggers fail at assigning to Local Variables when the Local Variable is specified as living on the Invoker object

mode80 2 weeks ago in Game Creator updated by Marti (Lead Developer) 2 weeks ago 2

My scenario is I'd like to assign to a Local Variable living on the same object where a Trigger component exists. In this specific example I'm trying to assign a collided object to my "lastCollided" Local Variable when an On Trigger Enter event occurs. Screenshot of the setup : 

I expect that the "lastCollided" Local Variable existing on this very game object will get assigned. 

What actually happens is that the trigger fires correctly with a collider the lastCollided variable stays null. (However it does work if I choose "Game Object" instead of "Invoker" in the dropdown that specifies where the local variable lives.)

Tracing through the code I can see the IgniterTriggerEnter.OnTriggerEnter method has a call:

this.storeCollider.Set(c.gameObject);

This seems to be where the valid collider should get assigned to the local variable. However, the Set method's optional second parameter (which appears designed to accept the Invoker) is missing. As a result the variable does not get assigned. 

It works the way I expect if I change the line to read:

this.storeCollider.Set(c.gameObject, gameObject);

Presumably every call to VariableProperty.Set should have a populated 2nd parameter for the Invoker so that situations like this won't fail.  I think the fix is to change the definition of VariableProperty.Set so that the 2nd parameter is not option. Then populate it with "gameObject" in all the code that used to call it without a 2nd parameter. 

Unity version:
2018 LTS
Game Creator version:
1.0.4

Answer

Answer
Not a bug

Correct, the Invoker changes where it points depending on the Trigger. It should be read as "What object is responsible for the firing of the Trigger?". Despite this, I agree that it's not always clear what object is Invoker referencing to. For these cases, we created an Action called "Debug Name" where you can print the name of the Invoker. This allows you to quickly identify which object is.

We are aware that this is not optimal and we intend to fix this in Game Creator 2.0. We have a few ideas that will make this easier to understand and will always know what object does the Invoker refer to.

GOOD, I'M SATISFIED
Satisfaction mark by mode80 2 weeks ago
+1

Hm.. I see now that in this case Game Creator considers the "Invoker" to be the collider object, not the object containing the trigger. 

In general, it's hard to know what Game Creator considers to be the "Invoker" in different contexts. 

Answer
Not a bug

Correct, the Invoker changes where it points depending on the Trigger. It should be read as "What object is responsible for the firing of the Trigger?". Despite this, I agree that it's not always clear what object is Invoker referencing to. For these cases, we created an Action called "Debug Name" where you can print the name of the Invoker. This allows you to quickly identify which object is.

We are aware that this is not optimal and we intend to fix this in Game Creator 2.0. We have a few ideas that will make this easier to understand and will always know what object does the Invoker refer to.