I have been working with UnityEvent a lot recently but needed to use 2 arguments, a string and an int, so I set this up in a new script.
[System.Serializable]
public class SetFloat : UnityEvent<string, int>
{
}
But when I went to Invoke it, I get errors.
[SerializeField]
public SetFloat floatParameters;
public void Call()
{
floatParameters.Invoke();
}
Apparently, Invoke needs 2 arguments of the same types, which makes no sense to me at all, it’s meant to be a generic solution, so I’m not sure why hard-coded values would be required, or even relevant.
Does anyone know what the appropriate values for these arguments are?
using UnityEngine;
using UnityEngine.Events;
[System.Serializable]
public class SetFloat : UnityEvent<string, int>
{
}
public class AnimationSetParameters : MonoBehaviour
{
[SerializeField]
public SetFloat floatParameters;
public void Call()
{
floatParameters.Invoke();
}
}
Why does it make no sense? It is as generic as it could be. Why would you use the generic version if you don’t want to pass any values after all?
Noone can tell, since it is your game. You have to know what you want to pass, like mentioned above. The only thing that is known to us is the type, like already mentioned by @passerbycmc and which is also shown in the methods parameter list.
My point was, if this requires values to be hard-coded, how can it be generic? Wouldn’t this require a different script each time you wanted another event, defeating the point of it’s existence?
for unity to serialize you need to subclass it into a concrete type anyways. Also you dont need a new script for everyone you can put multiple non MonoBehaviour classes in 1 file. You only need UnityEvent if you want to take advtange of the inspector and unity serialization. If you are only working with events in code you can use the native C# events.
public event Action<string, int> OnMyThingHappened;
Nothing needs to be hardcoded. Instead of literals, you can also pass variables as you surely know.
I’m not quite sure you fully understand the idea of events though.
The part of your application that provides the event is the one that’s responsible for its execution. It’s also responsible for the arguments that will be passed, if there are any at all.
The part of your application that is interested in the event is the one that gets notified and may handle the event. It can either use the additional information or ignore it.
For instance, the most trivial one is an event that doesn’t pass on any information to the handlers.
Since you’re using UnityEvents, I’ll use it as an example:
So if you use a simple UnityEvent, all it really does is notifying the subscriber (the one that’s interested in the event’s occurence). In this case, with the event’s execution there won’t be passed any information. The receivers/subscribers are wrapped in a UnityAction and just do whatever they’re supposed to do.
Using an event with parameters, the handlers will be notified as well, but you’ll also pass additional information during invocation (the arguments of type T1 and T2) that may or may not be of interest for the actual event handler.
When you use a UnityEvent, the subscriber will be wrapped in a UnityAction. Using UnityEvent<T1, T2>, subscribers will be wrapped in UnityAction<T1,T2>, so on and so forth.
Using the UnityEvent<string, int> says, you’re accepting handlers like
void OnWhateverHappened(string someString, int someInteger)
{
// handle the event
// either use someString and someInteger or just ignore it
}