+1
Cannot Reproduce

Bug with Wait in a Flow / State machine causing Missing Reference Exception

Reaper 4 years ago updated by Lazlo Bonin (Lead Developer) 3 years ago 7

If you have a flow or state machine running held in a wait it will cause Missing Reference Exceptions. Clicking the error highlights the CoRoutine Runner object.

To repproduce create 2 object, (happens with one aswell but you have to sam load the scene)

Create flow graphs on both , on one have On keyboard input triggering to load the scene.



On the other attach this flowgraph, which incidentally is another bug I believe, Ill post that one seperately, or maybe its just the cause of this one


When you run it wait 5 seconds or more and then hit Space to load scene, if it doesnt happen first time spam the key it will do it, then youll get this.


Initialy I had 2 scenes as I thought it was loading another scene that caused the roblem, but loading the same scene also caused it. 

Also the more objects you have running state machines in a wait node the more errors youll get. I ran into it after Id modified the enemy AI with more waiting and then had level loading.


This is thread with wait  bug, accidentaly put it in questions but couldnt edit it for some reason.

https://support.ludiq.io/forums/5-bolt/topics/857-wait-node-not-working-correctly/

Bolt Version:
Unity Version:
Platform(s):
Scripting Backend:
.NET Version (API Compatibility Level):
Not a Bug

When you load another scene, all the objects in the previous one get destroyed.

This includes the machine running the second graph you showed. 

However, wait coroutines are run on a special separate object that does not get destroyed when scenes change. This is very useful for code that needs to run after you switch scene. This means wait units will "complete" even if their parent got destroyed. (This was changed based on a feature request, but now that I mention it it does seem a bit odd).

The error you see here is because your Branch units are trying to get the Timer variable on the owner game object, but that game object got destroyed when you switched scene.

If you want to keep your second graph working after you load the scene, it needs to not get destroyed.

You can do that by calling DontDestroyOnLoad, for example in Start:



Tried Dontdestroyonload and it also doesnt work, also tried both Null Coalesce and Null check. What is happening is definately the Wait breaking it. Tried Has variable, Tried Caches . Ill give it a go with Jasons waits and see if thats any better.



Neither of these (or many others) work. The only thing that stops it causing the error is if no flow comes out of the wait ie if you sever the wait manually. Even if it goes in a node it doesnt come out of it will break it.

Also I tried Switching states and having the load trigger an event and pause for 2 seconds.

The event would switch states on the cube, but even though it had switched states the Wait is still flowing on the previous state graph, which means its in 2 states at once on the same state machine...

Treid with Jasons waits and they work aslong as you do it right ie

Have a short loop waiting for a few frames to pass to allow state machines to close

Then in the objects with State machine have a custom event breaking them out which is sent from the object controlling the loading.


Pending Review

I'll have another look at this if you're telling me it doesn't work with DontDestroyOnLoad.

Cannot Reproduce

Trying to reproduce this, but the setup is too complex and I'm not sure which graphs or objects I need to reproduce.

Please send me a minimal project (in a private ticket or in DM on Discord) that can be used to reproduce the error you're getting.

Same problem here!

But it's not straight forward. Same graph didn't caused error for some time but then it showed up again. Maybe a script execution order problem?

Anyhow: Problem occurs after a scene load / change which unloads an object with a  StateMachine running an active "Wait"-node

Wait nodes will be entirely refactored in v.1.4 with async flow, so whatever error is/was happening here is unlikely to happen again. Please submit a new report once v.1.4 is released if you still experience this issue.