TriggerEvent - Target Object

[MakerPlay]

Hey, thx for jumping in.

It looks like, there is no way around. Some of these examples show also "AddComponent" which isn´t that good, performancewise. Global sendEvent requires a second script, and so on...So i have to say, the other VS´s get it working, somehow. Believe me, or not, it can´t be only magic, there is more  .

[tcmeric]

Can you open one of those actions and send the code to me or djaydino?

[djaydino]

@tcmeric
What actions are you asking?
I only own playmaker

[MakerPlay]

I guess it is meant: something like "TriggerEvent.cs" but in GameFlow or in FlowCanvas, right? So you can take a look, how they managed to get it work.

I will take a search, and if i find something like that in GF and FC i will post it.

[MakerPlay]

this is the code of "TriggerEvents.cs" inside FlowCanvas:

Code: [Select]


using NodeCanvas.Framework;
using ParadoxNotion.Design;
using UnityEngine;


namespace FlowCanvas.Nodes{

[Name("Trigger")]
[Category("Events/Object")]
[Description("Called when Trigger based event happen on target")]
public class TriggerEvents : EventNode<Collider> {

private GameObject other;
private FlowOutput enter;
private FlowOutput stay;
private FlowOutput exit;


protected override string[] GetTargetMessageEvents(){
return new string[]{ "OnTriggerEnter", "OnTriggerStay", "OnTriggerExit" };
}

protected override void RegisterPorts(){
enter = AddFlowOutput("Enter");
stay = AddFlowOutput("Stay");
exit = AddFlowOutput("Exit");
AddValueOutput<GameObject>("Other", ()=> { return other; });
}

void OnTriggerEnter(Collider other){
this.other = other.gameObject;
enter.Call(new Flow(1));
}

void OnTriggerStay(Collider other){
this.other = other.gameObject;
stay.Call(new Flow(1));
}

void OnTriggerExit(Collider other){
this.other = other.gameObject;
exit.Call(new Flow(1));
}
}
}
GameFlow is closed. This means, all actions are inside a *.dll. So i can´t share with you.

[Alex Chouls]

I did some investigation and GameFlow is adding components to forward MonoBehaviour events (MouseDown, Collisions etc.) to scripts on other objects. They just add these components automatically and hide them in the Inspector. So behind the scenes, you're still doing Add Component etc. You just don't need to worry about setting it up. I'm sure other VS systems are doing the same thing - it's really the only way to get these MonoBehaviour events (AFAIK).

I've been playing around with adding this feature to TriggerEvent, CollisionEvent etc. and hope to have it in the next update. We already do a lot of pre-processing at build time to avoid un-needed Monobehaviour event overhead and Add Component costs at runtime, so we should be able to expand that system to handle events on other GameObjects while minimizing performance costs.

[MakerPlay]

You are really sure, it is working this way (add comp.)in GF ? I don´t know if this is the right way, doing it in PM, because of performance. But on the other hand, i have to say, a clean structure is the most important thing in a big project, using a VS system. Otherwise the overview get broken, get spaghetti and so on.


 

[djaydino]

Ah yes, i forgot about 'hide in inspector'

Code: [Select]

gameObject.GetComponent<Myscript>().hideFlags = HideFlags.HideInInspector;That would indeed explain every thing

I don´t know if this is the right way, doing it in PM, because of performance.

I don't think that this way is going the have performance issue if it is pre-processed.
If there where Tons of triggers it might increase loading time.

But on the other hand, i have to say, a clean structure is the most important thing in a big project, using a VS system.

I must disagree with you, performance is the most important in almost any project.
i definitely would not like to have lag in my games

[jeanfabre]

Hi,

 I confirm as well that there are no other ways to catch trigger events than having a monobehaviour on the GameObject itself acting as a proxy if you whish other GameObjects scripts to be aware of his.

I think it roots from the way GO, components and monobehaviours where designed initially in Unity.

 Bye,

 Jean

[MakerPlay]

Thx for explaination. Interesting. I think this core-behavior in unity will not change in the future. If its doable with "proxies" somehow, why not. Seems like other Devs. doing it this way.

True, performance is important. Just thought that clean code / structure results in a good performance. Otherwise you got bad performance. On top, it depends on the gameEngine too i think.

[jeanfabre]

Hi,

 The current beta of PlayMaker is currently focusing on this, early tests are positive, so this will be available soon, you'll be able to select a gameobject target for triggers and colliders actions.

 Bye,

 Jean

[MakerPlay]

Hey,

nice to hear that. Will be curious how the workflow will be. Is it planed to be, lets say, in the next release 1.8.6 ?

One last thing:
please add "multi object targets" into it. So usually you are able to put only "ONE" object into the target-slot. This is also a big downside. Please update this to be able to put as many target-objects as you want into the event. Thanks !!!

[jeanfabre]

Hi,

 PlayMaker is already at 1.8.6, so it will be in 1.8.7

Multi object targets is not planned in any actions, so I don't think it will be available no.

Bye,

 Jean

[djaydino]

Hi,
But there might come a custom action for it when possible

[Alex Chouls]

Yeah, I think the infrastructure coming in the next update will make it easier to do things like events from multiple objects.