I replicated your setup because this remote maintenance proves quite difficult
.
It turns out that there is a problem with resizing the FsmVar[] xxxxx by creating a new object ("new FsmVar[fsmvars.Count]") and trying to use it immediately afterwards.
You can test it yourself by throwing a Debug.Log() at the end of BuildFsmVariableList(): whenever you try to do something with xxxxx, wheter updating, setting or getting a value to/from it, it seems to break the function without throwing any error, and anything afterwards won't get executed (as if that action variable gets corrupted or isn't accessible).
When you comment that resizing process out (
//action.xxxxx = new FsmVar[fsmvars.Count];
), you'll see that it reaches the end of that function.
It might be that something needs to be done to the FsmVar[] after resetting/resizing it, but I think your best bet would be to go for a different collection variable if possible, like FsmArray which natively has a .Resize() function and can also hold any object type.
If you do, you should know that with FsmArrays you need to do the following when resizing/manipulating them (kind-of pseudo-code):
FsmArray array;
...
array.SetType.(...);
array.Resize(...);
for(...) {
array.Set(i, ...);
}
array.SaveChanges();
While setting up your scenario I also noticed that you were missing the UnityEditor using directive ( "using UnityEditor;" ), to get things like EditorGUI to work and you'd need to set the types to string before filling it with string values:
action.xxxxx[v].Type = VariableType.String;
I guess I can't help you any further than that. Maybe Jean or someone else sees this and might know what is going with FsmVar[]'s in such a scenario, but It could be that using an FsmVar[] is not be the desired approach and the reason that something like FsmArray exists.