Predictive & Live Debugging

Predictive Debugging

Bolt will attempt to predict nodes that may cause an error before you even enter play mode.

When a node is not properly configured or may cause an error, it will be colored yellow.

When a node is certain to cause an error, it will be colored orange.

In both cases, you should examine the node and make the required changes until it turns back to its normal color.

Let's look at a simple example. Here, the Log node is colored orange because it's missing the Message that it should output to the console:

If you connect the result of A + B to Message, the Log node will go back to normal. However, the Add node will turn orange, because it's missing its first operand, A.

If we properly provide values for both operands, everything will go back to normal.

Note that we don't have to connect the B input port, because it has a default inline value.

Null References

Null reference exceptions are very common. They happen when a parameter expects a value, but you give it "nothing", or in scripting lingo, "null".

Bolt will attempt to predict those if the Predict Potential Null References option is checked in Preferences > Bolt > Flow Graphs.

For example, even though the Destroy unit here has an inline value, since it is set to "None" (null), it is colored orange:

However, there are some rarer nodes that allow for null parameters. Unfortunately, because there is no way to know that from codebase analysis, Bolt will color them orange as a false positive. If this is a recurring issue for you, you can turn off Predict Potential Null References.

Missing Components

When you use nodes that require components and pass a game object or component that does not have the specified component, the node will be colored yellow as a warning. For example, here, even though we are providing default values for each value input of the Add Force unit, Bolt detects that the owner game object does not have a rigidbody and warns us:

Bolt will not color it orange because it is possible to add components to game objects at runtime, so the node is not guaranteed to cause a crash if you add the required component before calling it. If this use case happens often in your project, you can disable Predict Potential Missing Components debugging from Preferences > Bolt > Flow Graphs.

Live Debugging

When in play mode, the currently active nodes are highlighted in blue.

If an error occurs, the node that caused it will be highlighted in red.

Let's take a look at a faulty graph. Here, we're trying to log our third favorite fruit to the console when we press space. (Surely this is an example that could apply to a game... right?)

Can you guess what will go wrong? If we press play and click the object, here's what happens:

As you can see, all nodes are highlighted in blue as soon as we click because they were activated. However, there was an error in the console. Uh oh!

That's fine, but it doesn't tell us exactly where we went wrong. To make our life easier, Bolt highlighted the faulty node in red.

We made a common mistake: thinking array indices start at 1, whereas they actually start at 0. In scripting, indices are always zero-based. That means the first item is at index 0, the second at index 1, the third at index 2, etc. Therefore, if we want to get the third item, we need to write 2 in the field:

Then, the graph works as expected:

This article was helpful for 18 people. Is this article helpful for you?

Yeah, I think that one is under codebase, are you using Human naming, if not, try switching and search again. Also look under, Codebase > System > Collections > Generic

Would it be a bad idea to make bolt start at 1 when human is selected? Or have an option for that?