yes, be careful, even data is unique and not per Event, it's a global data, so everytime you set event data, get event info will get this latest data even in an fsm that came into an active state from a different event, it's not related.
This is quite at odds with what users might understand from the descriptions, especially on the actions which are specific to var types.
"Sets Event Data before sending an event."
"Sets the Int data to send with the next event."
It gives off the idea that the data package is unique to each event that is about to be sent next.
There's an implied "local" buffer since as long as no event is sent, the data package might be overwritten (changed) by any new set up until an event is actually fired from the current FSM, but from your description of the data being global, assumptions I ran with for quite some time now are now proven false.
So just how global is the data package exactly?
Say I have two FSMs, Fsm1 and Fsm2, either both sending the same event to different targets, or both sending two different events to different targets; if the data set up is done in Fsm1 but then doesn't fire any event, and Fsm2 sort of short-circuits this and sends its own event after the data set up but before Fsm1 sent its own event; is Fsm2's event going to use the data package as set up in Fsm1?
Or is the data pack set in a given FSM exclusive to this FSM, even if two (or more) separate FSMs all send the same event after, and only after, the setting up is done?
Besides the {{}} don't seem to have any effect on the formating inside the information section.
to overcome this, I either use SetEventProperties ( is you have PlayMaker Utils) which lets you define key/value and so you can create keys that are unique for a given event and not mix up data. Or I use a next frame event in the cascading logic omf my flow to give fsm a chance to act upon the reception of a given event, and use next frame event before sending the next step of logic.
But the globality of the data package remains the same, right?
Set Event Data uses default properties and Set Event Properties allows the user to define custom properties if I get this right.
As I explained above but it might not be clear enough, I encountered a problem a certain number of times during the development of my app where data would simply not be sent. I'm not saying data was overwritten, it was simply absent.
Typically this happened inside a state where I did:
1. Define GO target
2. Set up data
3. Send event to target
And this block was repeated a few times inside the same state, mainly because spreading this over several states created unnecessary clutter and the whole series of actions within the state was still small enough as not to generate a monster, and especially not warranting any complicated dynamic self-looping construct.
The event itself was always the same, like for example HELLO instead of HELLO_T1 (for target 1), HELLO_T2, etc.
In the "bug", not a single GO received any data, not even the last GO which you might think would at least receive data as defined in the last setting up. It's just blank everywhere as if there was a data-writing/encapsulation conflict during the same frame.
Two fsm sending two identical event data type with different value is not a good idea, you won't be able to enforce order and one value will get lost.
Hmm... "two identical event data type with different value"
You mean setting up data twice using FsmInt for example in both cases, once with 0, the next time with 4618?
Would there be a problem if I did this:
1. Set Int data = 0
2. Send BYEBYE to target 1.
3. Set Int data = 4618
4. Send BYEBYE to target 2.
Is there a risk of target 1 actually receiving the data that was meant for target 2?
Or target 2 not receiving any data until BYEBYE is received by target 1 and the data extracted?
All that time I thought events were treated as instances of one event template, and each one was unique, but are you saying that they are in fact sequential, as there exists only one single version of a given event at a given time, and that until BYEBYE for target 1 isn't received, target 2 won't receive BYEBYE?
when you know have this case, you need to either create a buffer array, where you add values to an fsmArray and then have the fsm process each value one at a time.
I'm not sure how that would differ much from my case, aside from this new step:
0. Set up FsmArray (once)
1. Define GO target
2. Get data at index n from FsmArray
3. Set up data
4. Send event to target
Repeat (with n incremented each time)...
or you put some next frame event to prevent the situation to begin with.
This might not be feasible because of the loss of performance in some cases where data has to be transmitted within one or two frames at most.
