Bolt. How to Listen to unity game events? What I'm doing wrong? is just me that needs this?

The problem:

I want to have bolt staying put and wait for an event to get fired by some other place in the game scene. Then when the event fired, bolt will do something.

I've tried searching the forum and internet, no luck in an answer.

What I've found is this asset

https://assetstore.unity.com/packages/tools/visual-scripting/bolt-unity-events-175821

which does exactly what I'm asking except it doesn't. Because the way it works is by manually tying in a script that send the event into the "On Unity Event" node.

So for each of these "On Unity Event" nodes you need a separate script tied in.

Boh.

If I need to write a custom script for all events that bolt needs to listen to I'm not doing any decoupling in the code.

I want bolt to listen to an event, defined by a simple string, the event name, and then do something.

I see waves of places where this "wait for event then do something" could be useful and now I'm puzzled because:

a. is a mistake what I'm trying to do? Have event fired and then bolt will do something is somehow wrong?

b. I can't believe bolt is not able to do this. Maybe it can do it but I'm not able to find the answer. Must be something simple that I'm missing.

 

Doing this is documented here: https://docs.unity3d.com/2019.3/Documentation/Manual/bolt-events-reference.html under the section "Unity Events."

I believe a better way to handle this is coming in a future release.

 

thank you, why it didn't show your reply in my dashboard. I will check this

edit: well I need to create a custom bolt playboard or whatever for each of the events I want to send?

if I have 25 objects in the scene created at runtime do I need bolt attached to them? I don't get it

 

Sorry for bringing up this old post - but I'd like to give some explanation.

So first of all: if you want to use the asset with the latest Unity-Version you have to update namespaces. First then it will compile again.

Then I don't understand what you mean with "extra scripts". Afair the asset was created at a time where unity wasn't able to handle properly such code:

Code (CSharp):

1. [SerializeField] private UnityEvent<string> onNameChanged;

You had to create a class inheriting UnityEvent<string> and make it serilalizable. So at that time extra scripts where required. But this isn't the case anymore.

If you go for AoT-Plattforms (like web/mobile). You have to use AotUnityEvents. And I THINK it should work fine if you just add the SerializeableAttribute to them:

Code (CSharp):

1. using System;
2. using UnityEngine.Events;
3.  
4. namespace JFruit.Bolt {
5.  
6.     [Serializable]
7.     public class AotUnityEvent<T1> : UnityEvent<T1> {
8.         internal void Use() {
9.             new OnUnityEvent().OneParamHandler<T1>(null);
10.         }
11.     }
12.    
13.     [Serializable]
14.     public class AotUnityEvent<T1, T2> : UnityEvent<T1, T2> {
15.         internal void Use() {
16.             new OnUnityEvent().TwoParamsHandler<T1, T2>(null);
17.         }
18.     }
19.    
20.     [Serializable]
21.     public class AotUnityEvent<T1, T2, T3> : UnityEvent<T1, T2, T3> {
22.         internal void Use() {
23.             new OnUnityEvent().ThreeParamsHandler<T1, T2, T3>(null);
24.         }
25.     }
26.    
27.     [Serializable]
28.     public class AotUnityEvent<T1, T2, T3, T4> : UnityEvent<T1, T2, T3, T4> {
29.         internal void Use() {
30.             new OnUnityEvent().FourParamsHandler<T1, T2, T3, T4>(null);
31.         }
32.     }
33.  
34. }

Haven't tried it out in real-world but I'm confident that then you also shouldn't need any extra scripts. So you can use them like this:

Code (CSharp):

1. [SerializableField] private AotUnityEvent<string> onNameChanged;
2.  
3. public AotUnityEvent<string> OnNameChanged => onNameChanged;

Therefor I don't see where you would need any extra script.