As Unity is continuing to modularize the engine, they are moving some "core" classes like Input in separate assemblies called "Modules". This causes Bolt to stop finding the associated units in the latest preview versions of Unity.
We will try to hunt down and add the new modules by default in a patch version soon, but in the mean time, you can add UnityEngine.*Module to your Unit Options Wizard (under Tools/Bolt) if you notice units are missing.
For example, adding UnityEngine.LegacyInputModule now seems necessary for accessing the Input class.
Status: Working on fix. All new modules will be added to the default list of assemblies in the next version, hang tight!
When entering Play mode in Bolt v.1.4.4+, you may notice this warning:
Your Unity preferences are set to recompile assemblies during play mode. This can cause data corruption in Ludiq plugins and has been temporarily disabled.
This is harmless and will not cause any issue. In fact, it's Bolt warning you that it disabled a feature that would cause issues, namely live script recompile.
Live script recompile is when you make code changes while the game is playing and Unity tries to apply them without exiting play mode. This is notoriously unstable and causes several plugins to break. In the case of Bolt, it has been known to cause graph and variable data to corrupt or disappear. This is why, in recent versions of Unity, there is an option to disable that behaviour. If you don't disable it yourself, Bolt will do it for you to make sure you don't lose any work.
If you want to get rid of the warning, simply disable the live script recompile preference:
Open the Unity Preferences
Go to the General Tab
Change Script Changes While Playing to Recompile After Finished Playing
If your project uses .NET 4.x (the new default since 2018.3), you might encounter a compilation error mentioning a conflict with types in the System.Threading namespace. Usually, the Task class.
The solution is simply to use the .NET 4.x version of Bolt provided within the Asset Store package, or directly from our Download page.
Note that if you previously added the .NET 3.x version to your project, then imported the .NET 4.x version on top of it, you will still have the leftover System.Threading.dll in Ludiq/Assemblies. Make sure you delete it!
Status: Fixed in Asset Store package on May 13, 2019.
A bug in Unity 2018.3.x causes a regular GC.Collect spike. You may notice a small half-second to second freeze every few seconds in the editor. This bug has reportedly been fixed in 2018.3.14f1, but the according to our tests, the fix did not work. We cannot test Unity 2019.2 yet either, because another Unity bug prevents Bolt from working on this version. The solution is simply to upgrade Unity.
When instantiating a prefab in Unity 2018.3, you might run into an issue where all its Bolt components are reset to their default state.
That means, for example:
The source of machines is reset to Macro, and the macro reference is None
The variables component is entirely blank
References to that prefab elsewhere in the project are missing
This happens for prefabs in projects that were created in the old prefab workflow (Unity 2018.2 and below) then opened in a newer version of Unity with the new prefab workflow (Unity 2018.3 and above).
The solution is simply to Reimport the affected prefabs. You can do so by selecting the prefabs, then choosing Assets > Reimport.
If you want to make sure you did not miss anything in your project, you can also use Assets > Reimport All. Note that a full reimport can be very long depending on the size of your project.
When building the unit database in 2018.3 or above, you might get the following error: Fatal error in GC: Too many heap allocations. This appears to be a bug in Unity's handling of garbage collection that was introduced in 2018.3 and is currently being investigated (Issue Tracker). The only guaranteed workaround at the moment is to revert to Unity 2018.2.
Status: Seemingly fixed in later versions of Unity 2018.3.
You may get one of the following warnings or error dialogs when importing the Bolt package, either when installing it for the first time or when updating it to a new version:
Assertion failed: Cancelling DisplayDialog because it was run from a thread that is not the main thread: Opening file failed Opening file /Assets/Ludiq/Bolt.Flow/Generated/UnitOptions.db: The process cannot access the file because it is being used by another process.
A default asset was created for 'Assets/Ludiq/Bolt.Flow/Generated/UnitOptions.db' because the asset importer crashed on it last time.
We are unsure yet as to what conditions are causing this error to occur. However, the workaround is simple:
Press the Cancel Button
Run Tools > Bolt > Build Unit Options
Status: User workaround needed for Bolt 1. Fixed in Bolt 2.
Some users reported issues with the former version of sqlite3.dll bundled with Bolt. For some reason, their operating system fails to initialize it as a native plugin in Unity. The suggested workaround is to download this version of sqlite3.dll to replace the one located at Ludiq/Assemblies/sqlite3.dll. Make sure to restart Unity after replacing the DLL.
We updated our version of SQLite in v.1.4.0f10 to this version.
Under some conditions we are currently unable to isolate, the Unity editor does not seem to honor LockReloadAssemblies while Bolt generates the inspector bridge scripts as part of the setup wizard. This causes the editor to recompile while the setup wizard is running, which prevents it from completing. Because it isn't complete, it restarts as soon as Unity finishes reloading the assemblies, in an endless loop.
In the mean time, the workaround is simply to skip inspector generation by hitting Next on this page of the setup wizard.
You can always generate inspectors manually later by using Tools > Ludiq > Generate Inspectors.... In most cases however, this isn't necessary for Bolt to work, though: it is only required if you are using CustomPropertyDrawers for your classes.
Status: Inspector generation has been removed from setup wizard in Bolt v.1.4.1 until we can find a reliable solution.
There are multiple conditions under which Bolt may fail to generate your documentation. This will not cause any issue, because documentation generation is not strictly required for Bolt to run. However, it will prevent Bolt from showing the built-in editor documentation for your custom scripts and third-party plugins.
You can click the Show log... link next to the documentation item that failed to generate to find the cause of the error. Most often, it is because MSBuild is missing from your Windows installation. You can fix this by downloading and installing MSBuild 14.0, then running the documentation generation again from Tools > Ludiq > Generate Documentation.
Status: User workaround may be needed depending on Bolt, Unity and Visual Studio versions.
AOT Stubbing does not work on constants (like Mathf.Infinity, Mathf.Deg2Rad, etc.) which causes a crash in IL2CPP builds. This is because the C# compiler substitutes constants by their actual value in the generated IL, which makes it impossible to access them via reflection later.
There's no blanket way for us to fix this kind of issue in Bolt 1. In Bolt 2, this will no longer be an issue, because your builds will always be running from actual scripts, so reflection will never be involved.
In the mean time, a simple workaround is to add the class that defines your constant to a linker file. To do so, create a file called link.xml anywhere in the project with the following content: