Bolt
>

FAQ

Updated: 2018-08-28

Which versions of Unity does Bolt support?

Bolt's minimum version requirement is Unity 2017.4, and has currently been tested until 2019.3.

We try to support new versions of Unity as soon as possible, but using Bolt with Alpha and Beta versions of Unity is not guaranteed to be compatible.


Why does my graph work in the editor, but not in builds?

If your graphs work in the editor but not in builds, you might have forgotten to run the AOT Pre-Build wizard before building.

This is necessary for all AOT platforms, that is, all platforms except the Editor and PC (Windows / OS X). If you target PCs but force the IL2CPP backend, AOT Pre-Build is also necessary.


Why does my variable reset to null?

You may notice some of your variables reset to null. This happens when you choose a type that supports null, but don't assign a value. This is not actually a bug, and will not cause any issue, but it is counter intuitive to new users. Here's why it happens:

Some types are called reference types and support null as a value, for example strings, game objects, or any class. Other types are called value types and do not support null, for example numbers, booleans, or any struct.

Bolt variables store two things: the name of the variable and its value, because it's the only things Bolt needs to know to be able to get and set this variable during runtime.

When you create a variable of a value type, Bolt can deduce the type of the variable by looking at its value. For example, when it sees that the value is "true", it knows that the type is "boolean". When it sees that a value is "3.25", it knows that the type is "float". Because it can deduce the type, it can show you the right inspector for it in the variables window.

When you create a variable of a reference type and give it a null value (default for strings and Unity objects), Bolt cannot deduce the type. When Bolt sees a "null" value, it doesn't know whether that's a "null string" or a "null game object", because both of these are actually the exact same thing at the CIL level. This is why it cannot show you the right inspector and reverts its type dropdown to "(Null)" after you close the variables window.

We are currently working on type-hinting, which would preserve the type across assembly reloads and make sure it doesn't reset to null. Stay tuned!


Why can't I drag or select a scene object in my graph?

You might notice that you sometimes cannot drag an object (game object or component) from the scene to your graph, nor select them from the object picker. This is normal and it is not a bug. It happens because your graph is a macro, not an embed (see the manual for more information on the difference between macros and embeds). Macros are saved as assets, meaning they are not aware of which scene they're in. Therefore, Unity does not allow saving references from within any scene in them.

There are two ways of solving this:

  • Create an object variable that contains your scene reference, and use Get Variable to access it in your graph (recommended)
  • Convert your macro graph to an embed; only do this if this graph will only be used once and only used in the current scene

Why doesn't my type show up in the fuzzy finder?

Before a type shows up in the fuzzy finder, two things have to happen:

  1. It must be included in your type options in the Unit Options Wizard (Tools > Bolt > Unit Options Wizard...)
  2. You must re-generate the unit options (Tools > Bolt > Build Unit Options...)

Note that if your type is a MonoBehaviour or any other type inherited from UnityEngine.Object, you can skip step 1, as those are automatically included by default.


Can I speed up unit options generation?

Yes! You can use Tools > Bolt > Update Unit Options... (Update, not Build) to perform an incremental update. Bolt will attempt to only regenerate options that changed since your last update.

For this to work, there are some conditions:

  1. Your type has to have the same name as its source file
  2. The source file must be a C# script (.cs), not a DLL
  3. Your type cannot be abstract or generic

Stay tuned! We are currently reworking this to improve the overall speed, better detect incremental updates, and avoid being limited by the above conditions.


Why don't I see abstract types, generics or interfaces?

If you're missing abstract types, generics (such as List of String) and interfaces (such as List Interface) from the fuzzy finder or the type dropdown, you are probably running in AOT Safe-Mode and targetting an ahead-of-time (AOT) platform, such as mobiles, consoles, or WebGL.

Because we cannot generate reliable AOT stubs for these types, they are likely to get stripped by Unity on build and cause errors at runtime. Therefore, we hide them from users. If you want to bypass this, you can disable AOT Safe Mode, although this is not recommended. Or you can switch to a platform that supports JIT, like Windows, macOS or Linux.

In Bolt 2, we will be generating full C# scripts for your graphs, which will ensure everything works in AOT. Safe-mode will no longer be an issue at this point, because we won't need to stub anything anymore.


How can I create custom units?

There are three way of creating custom units in Bolt:

  • Super Units, which are created visually from within Bolt itself
  • Reflected Units, which are reflected from your C# codebase
  • Custom Units, which are specifically coded for Bolt in C#

There is currently no documentation on Custom Units, because the API is not considered to be stable yet. Some community users have however started reverse engineering the Bolt source and extending it regardless. You can find them on the Discord server in the #api channel. They're usually really helpful!

You probably don't need to (or want to!) be creating custom units. With super units and reflected units, 99% of the time, you can avoid extending Bolt. Community user Reality.Stop() has made an awesome video explaining the difference between all three and when you should be using each.


Can I use Bolt to run graphs from AssetBundles?

Unfortunately, Bolt graphs cannot be reliably run from Asset Bundles, especially on AOT platforms, for the same reasons that C# scripts cannot. AOT pre-build generates "fake" scripts that pretend to be calling the methods and properties you use in your graphs. This keeps the Unity IL2CPP compiler from stripping them and making them unavailable at runtime. To do so, it scans:

  • Every macro
  • Every prefab for machine with embeds
  • Every scene for objects with machines with embeds

Any graph that was available during the (pre-)build of your core app will still be available in asset bundles. However, graphs that were not will not have the stub scripts generated, and will likely throw errors if ran from AOT bundles.

This is the same limitation as Unity, really: asset bundles cannot include new scripts. And for the same reason, too: these scripts can't be compiled just-in-time (JIT) on some platforms, namely iOS.

Was this article helpful?
This article was helpful for 1 people.
Yes, helpful
No, not for me