I’ve stumbled upon a case where putting wrong data into the SendEvent action it’ll result in exceptions inside CheckEvent conditions. I discovered this while working on a FSM that uses an event name that was bound to a BB parameter, but the parameter wasn’t always existing in the blackboards for the executing FSM. So basically, as long as the event name is (null) the CheckEvent will throw a NullReferenceException when it compares the sent event name to the condition event name:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
NullReferenceException:Objectreference notset toan instance of an object
Just discovered that this only seems to happen in standalone builds, not in the editor, because there is extra code running in the editor guarding an action from be started at all when there are parameters missing etc. May be the case why it only showed up in the build of our game but not whilst debugging it 😀
Indeed, within the editor, fields marked with the [Required] attribute (shown as red in inspector), guard the action from being executed, but still show an error log in the console like “A required field named ‘SomeName’ is not set.”, so that you know something is wrong.
In runtime though and to save performance this attribute is not checked, and thus why a null reference is thrown instead directly.
Yes, but GDs probably will miss it that there’s something wrong and the unpredictable behavior (FSM essentialls runs in editor when the offending action is the last one to be executed, but completely breaks FSM execution because it throws an exception on every update cycle but doesn’t progress anymore) gives a very hard time debugging and finding such problems. I’ve “fixed” it by adding additional null checks in the send event actions and also I removed the data check from the editor code so I have the same behavior in the editor as in the end product. An exception that is thrown every frame will also be easier to spot in the editor and GDs may not miss it that easily 😉
Hey,
Sorry for the late reply due to Christmas.
I will take a look and see if maybe doe the [RequiredField] attribute check in runtime as well, in case it does not have a performance overhead 🙂