Yes. Bolt's minimum version requirement is Unity 2017.4, and has currently been tested until 2018.2. We try to support new versions of Unity as soon as possible, but using Bolt with beta versions is not guaranteed to be compatible.
There are currently a number of known issues with Unity 2018.1 and Unity 2018.2. These are caused by Unity bugs which have been confirmed and fixed in later versions; however, we cannot do anything about them. See the known issues section for more details.
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!
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
- It must be included in your type options in the Unit Options Wizard (Tools > Bolt > Unit Options Wizard...)
- 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.
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:
- Your type has to have the same name as its source file
- The source file must be a C# script (.cs), not a DLL
- 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.
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.
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.