0
Not a bug

Missing references to actions

gyltefors 3 weeks ago in Game Creator updated 2 weeks ago 8

I have experienced references to actions getting lost, so I created bug ticket here to keep of the issue.

It last occurred during the following condition:

1. I added an action to a dialogue line.

2. The action appeared as normal when in editor mode.

3. When pressing play, the action was replaced with a missing action.

4. When stopping, the action was still missing.

5. In the log, the following entry was generated: "GameObject (named 'Dialogue') references runtime script in scene file"

The steps 1-5 can be repeated, and each time with the same result.

I'll follow up more info after trying debugging the issue...

Unity version:
2018 LTS
Game Creator version:
1.0.6

Answer

Answer
Not a bug

Okay, I see the problem. You're probably using custom Actions, since NewAction is the default name of a newly created Action. Unity has a (hidden) limitation that the name of the script has to be the exact same name as the class name. So for example, if you create an Action called "public class NewAction : IAction", the script name has to be called NewAction.cs.

If the class name and the script name aren't the same, the reference will be lost when Unity reloads its domain.

What it doesn't make sense is changing the code architecture to Scriptable Objects. These are objects that live in your Project Panel, not in the scene. Meaning that they can't reference scene objects. This would be a very big roadblock for making games.

BAD, I'M UNSATISFIED
Satisfaction mark by gyltefors 2 weeks ago

Ok, this is what I could figure out:

1. Whether the reference is lost or not depends on which action I add. In the case I am looking at now, my custom action references are lost, but not the builtin debug log action.

2. The reference is lost if I add it to a dialog line, but not if I add to another place, in a normal action list.

3. IAction is referencing a private variable m_Script, which seems suspicious, as we can make no assumption about private APIs (accessing private APIs should not be used in production code, and also please notice that the CSharp naming convention is to use the "I" prefixes for interfaces, not for classes).

4. Actions are components, that you somehow hide away and put inside other components. This seems hacky, and prone to issues.

Personally, I wouldn't dare to risk building a game on these foundations, and really hope you can revise this architecture for Game Creator 2.0. What if worst come to worst, and you would not be able to continue support for GC, and a game project starts collapsing because of a weak foundation (let's say Unity changes things under the hood, making m_Script behave differently)?

Checking the scene file, I found the following:

5. Something is referencing "NewAction". That is an old class name not used anymore, as I renamed it, and as far I can tell, removed all usage of the old version of the action.

6. m_Script for my actions have no guid, only a file ID. The debug log action does have a guid, as well as a type (3). I don't know how Unity uses file ID vs GUID, but we should not know it, and should not depend on it, as m_Script is a private API, and Unity is free to use those fields however it likes.

Again, I will hold off using actions until GC2.0, if you decide to switch to something like scriptable objects instead to represent action nodes for a new architecture.

Answer
Not a bug

Okay, I see the problem. You're probably using custom Actions, since NewAction is the default name of a newly created Action. Unity has a (hidden) limitation that the name of the script has to be the exact same name as the class name. So for example, if you create an Action called "public class NewAction : IAction", the script name has to be called NewAction.cs.

If the class name and the script name aren't the same, the reference will be lost when Unity reloads its domain.

What it doesn't make sense is changing the code architecture to Scriptable Objects. These are objects that live in your Project Panel, not in the scene. Meaning that they can't reference scene objects. This would be a very big roadblock for making games.

Of course I renamed the script to match, I have been using Unity for a decade. This bug is serious enough for me to drop using Game Creator, so please take things seriously. The way you are using MonoBehaviors is NOT working. If you don't want to acknowledge this as a bug, good luck with all the problems this is going to cause your users!

We hope you can understand we can not see your project and our suggestions are based purely on what you tell us and on our experience. Game Creator is used by a wide variety of users ranging from different levels of expertise. We're sorry if you were offended by our answer, but it makes total sense that the name of the Action is mismatched. Whether it's something you've already thought of or not is something out of our reach.

I can assure you we're not doing anything strange with MonoBehaviors. Without getting into details, Unity doesn't (up until 2019.3, which is the reason we'll be working on GC2) provide Polymorphic Serialization. The only way to have a collection of different class instances inside the same array is by having its base class inherit from UnityEngine.Object, which happens to only be available through ScriptableObjects or MonoBehaviors. If we want to reference scene objects, it all boils down to MonoBehaviors. Hence our decision. The suspicious m_Script property you mention is an inherited Unity property that is common for all MonoBehaviors, which references the actual script. You know when you create a custom C# script and see a greyed out property in the Inspector pointing to your script? That's the m_Script field.


Back to your issue, there's little we can do if we can't reproduce your issue. We (and many other users) have been using the Dialogue module without any problems so far. So please, can you provide the custom Action you're using in order to reproduce this? We will only be able to investigate this if you help us narrow dow your problem with clear reproduction steps.

Again, we're not dismissing there's a problem. There might be, but if we can't reproduce this with the steps you provide we can't do anything.

Is using polymorphic serialization on your road map for GC2? If so, I don't mind waiting for that.

Yes, among other things. Unity's going to change quite a lot in the following years and we're testing bleeding edge tech for the Game Creator 2.0 package. Polymorphic serialization is something we've already experimented with and the results are very promising (see screenshot).

Other things that we're taking into account for the next version are the use of the new UI Elements rendering system. We've built some Actions prototype (see same screenshot) using this new system, and despite not being there yet (there are any missing features), we're very excited and confident that this is going to be a very big step forward. Plus, this gives us a good excuse to rebuild the Game Creator editor UI to fit the new minimalistic editor theme.

The last part we want to tackle is the use of DOTS. This new paradigm shift is a game changer but not sure if in the good way. We're still investigating if it's worth switching to or even whether it is possible.


Feel free to drop your ideas in the Ideas channel.

+1

Thanks, that looks very promising! It would definitely be worth waiting for.