V3.2

Release Notes:

New Nodes

Else If

Else if is used to check multiple conditions in sequence and execute code based on the first condition that is true. If none are true, it goes to a default option (the else)

As

As is the same as the convert unit, this node used for the C# Generator.

Expanded Node Support

The C# generators now support the following nodes:

• InvokeMembers
• SetMembers
• GetMembers
• If
• SelectOnFlow
• NullCheck
• AsUnit
• ConvertUnit
• DelegateUnits
• For
• ForEach
• Expose

Attribute Support with Parameters

You can now use attributes with parameters.

Customizable Generated Code Colors

Change the colors of your generated code to match your preferences and improve readability.

New Node Finder Window

Thanks to the contribution from omega-ult, we now have a Node Finder Window. This tool allows you to search for units within:

• ScriptGraphAssets
• StateGraphAssets
• ScriptMachines
• StateMachines

Currently, the search functionality is limited to units and does not include Groups, StickyNotes, Comments, or States.

Improved Pool Initialization

The Initialize Pool unit has been updated to allow initializing a pool with a custom GameObject, instead of automatically creating one.

Bug Fixes

• Fixed Disabled Connection Values Bug: Resolved the issue where connection values were not displaying.
• Warning Fix: Addressed warnings when entering a script machine.
• Fuzzy Finder Hanging Fix: Fixed an issue causing the Fuzzy Finder to hang when opened.
• To Macro and To Embed Error Fixed a issue where the To Macro and To Embed buttons would sometimes give a error when converting.

---

Also added better AOT Support for the OnUnityEvent node.

V3.1.2

You can now use Flow and Value Reroutes to customize the flow! also added Unity Event with parameters and fixed a bug where the finished output of the if would run before True or False.

You can select the connected node and the reroute and press backspace to toggle the flow.

V3.1.1

Added Arrows, Object Pooling Events and updated Log Unit also added HDR color.

To use HDRColor add Bolt.Addons.Community.Runtime to the node library and regenerate the nodes

V3.1!

The Community Addons is back! With the error fix, few tweaks and 27 new nodes.

Nodes added:

Have also 2 new windows :

• Unit Generator.
• Unit Descriptor Generator.

The unit generator will generate the basics of the node that you want like Inputs and Outputs but will not generate the logic you want for it that's up to you to add.

The unit descriptor generator will allow you to put a description and a custom icon for your node, The generated script has to be in a editor folder.

Finally back! with new maintainers.

3.0 Released!

It's been a long time coming, but the Community Addons is back in the swing of things! For a long time now, we've been anticipating the arrival of Bolt 2.0, which brought many improvements, an overhauled API, and the obsoleting of many of the units in the Addons. Now that the future of Bolt looks a bit different, there is value in continuing the Community Addons project, so we're back at it.

For this release, we've got an improved release strategy laid out, AOT compatibility, and a whole pile of toys from Jason Jones. A lot of those units were released previously on his website separately, but he's brought them under the Community Addons where the community as a whole can help maintain them and improve them. If you're looking to get the new features for your project and already have the 2.4 units, be sure to read Updating from 2.X below.

The Addons are in the best state they've been in for a long time, and it's exciting to be working on the project again after such a long break!

Updating from 2.X

Important - Do not skip if you are updating from the 2.X line of units!!!
The Community Addons project has moved away from distributed dlls to the Unity Package Manager. The primary driver for this is the existing dlls caused problems when building for AOT platforms (namely, Unity didn't realize it needed to include the dlls in the build). By using the Unity Package Manager, we can actually deliver the source code to your projects, enhancing your ability to tweak, customize, and participate in the project, while simultaneously slaying the AOT dragon once and for all. In addition, we can push out fixes as we have them, rather than slowly bundling things up into a large release.

All in all, it's a much better delivery system, but it does mean that you need to DELETE all Bolt.Addons.Community dlls from your Assets/Plugins directory! These are old, no longer updated, and will interfere with the new version. Simply remove them from your project, and then follow the Installing the new version instructions below for how to add project via the Package Manager.

If you have Jason's Bolt Extensions or UAlive, contact him on how to update safely now that these units are in the Community Addons.

Installing the new version

The Community Addons now uses the Unity Package Manager to directly pull the repository down into your project. However, this does mean that you need a configured .git client, because Unity does not provide one for you. This is a one-time setup step per computer that many of you can skip over if you've actively used .git before. (for more information on the subject, you can consult Unity's documentation on the matter: https://docs.unity3d.com/Manual/upm-git.html)

Prerequisite: If you don't have a git client installed on this computer

1. Install Git. https://git-scm.com/downloads
   • On Windows, you can automatically add git to the System Environment, allowing you to skip step 2 below.
     
2. Otherwise, manually configure Git to be a part of your system environment.
   • Windows:
     • On Windows, this means adding the git executable to your PATH environment variable
     • Right-click My Computer on your desktop or start-menu, and select Properties.
     • Click the Advanced system settings tab.
     • Click the Environment Variables button.
     • Under System Variables, click PATH (can also be called Path) and click Edit.
     • Paste the location to your git.exe and insert a semicolon at the end as a separator between what you just pasted and what was already there (No spaces). For me, this path was C:\Program Files\Git\bin\git.exe

(other platforms are supported, ask on the discord for help)

Installing

The Community Addons can be installed using one of two methods:

Via Package Manager:

Open the Unity Package Manager, and click the "+" button in the top-left corner :

and add the following url:

https://github.com/RealityStop/Bolt.Addons.Community.git

(for more information, or if errors are encountered, see https://docs.unity3d.com/Manual/upm-ui-giturl.html)

Then, use the Tools menu to Build Unit Options, and they're ready to go! Once you've rebuilt your unit options, the new nodes will be available for use.

Manual install:

Alternatively, open Packages/manifest.json and add this line under dependencies:

"dev.bolt.addons": "https://github.com/RealityStop/Bolt.Addons.Community.git"

(for more information, or if errors are encountered, see https://docs.unity3d.com/Manual/upm-ui-giturl.html)

Then, use the Tools menu to Build Unit Options, and they're ready to go! Once you've rebuilt your unit options, the new nodes will be available for use.

New Content

Whoohoo! Now we get to talk about all of the new toys! In addition to the new update method, the AOT compatibility, and the ability to see the source directly in your project, we also have new Units to play with!

AOT Compatibility

There is now a custom build script to pull in a custom link.xml to force Unity to include the Addons in AOT builds. The Dragon has finally been slain, and version 3.0 brings the first version that is fully AOT compatible.

Reroutes

Behold. You can finally reroute flows and values wherever you please. You can find them by searching 'reroute' in the fuzzy finder. Once you've picked them from the fuzzy finder, you can simply press spacebar to lay down a new reroute.

Just promise to show us any spaghetti atrocities you commit:

Random Element

There is now a unit that can select a random element from an IEnumerable, with optional toggles in the graph inspector for accessing both the key and value of a dictionary:

Be aware that because of how the data containers are structured, accessing elements from an array or list is far more performant than accessing a random element of an dictionary (in my testing with 10000 elements, arrays/lists were about 100x faster). It's still fine to pull from a moderately sized dictionary, just try not to do it every frame.

Query

We now have a Query node, which can perform operations similar to how you might use LINQ in C#. The simples, Any, is shown here:

Any returns if the collection has any items (and thus, is not empty). For instance, if you maintained a list of targets in range, you could query the list to test if there were any targets in range.

However, the Query node offers a drop down that can alter the operation performed for several other variations:

Some of the other variations have to operate against each element in the input Collection such as the following case that results in a filtered list Where the condition yielded true:

Here is a super basic example using the Where method. If the item is above 10, its automatically added. Here's some input, and the resulting output:

When working with some of the Query types, you'll notice that the condition is checked multiple times, which means you need to use a variable or reroutes to feed the updated result back into the unit each time. This is because (using the above Where example), each item in the Collection input node is being tested to determine which elements result in a true Condition result. To do this, it will set the Item output and pulse on the Body flow output, much like the For Each node does. However, after that flow has terminated, the Query will recheck the Condition to find the result of the operation for that Item in the collection. Using reroutes to show this relationship, the following is an equivalent:

Array and Multi-Array support

Three new units have been added to improve support for arrays and add multidimensional arrays to Bolt. If you are unfamiliar with multidimensional arrays, you can think of them as an n-dimensional table, or a list of lists, rather than a flat list. (Creating jagged multi-arrays are currently not supported, use C# for that)

Additional units that are able to fetch items from arrays (of any dimensions) have also been added. You can find all of them under Community->Collections=>Multi Array

Convert

Convert is an AOT safe way of converting an object or collection from one type to another. This was created so we could use Linq properly by evaluating only after we converted. The convert unit however, is intended to also convert any object to another type if it is an allowed conversion.

And that's all for now! Go make something awesome!

V2.6

Version 2.6 released

This is largely a maintenance release, intended to resolve some errors in the software and bring the addons pack up to the latest UnityVS version. If you're wondering what happened to V2.5, it was soft released as an update to 2.4. Chances are if you're already using the Addons, you've already got 2.5.

2.6 includes:

• eliminates a set of warnings when using a Professional version of UnityVS (Unity's distribution of Bolt)
• code driven defined event listeners now properly check to ensure the event is of the appropriate type. Using the events in the graph already performed this check, we're just bringing code uses in line with the expected behavior.
• Manual Events now support coroutine flows, and aim to be unopinionated. A few concessions have had to be made to work the way a user might expect and preserve the single-threaded nature of Bolt. The exact mechanics deserve an entire post of their own, but the see the following table for when the event is immediately triggered, and when it will defer to the next time it can safely execute within the Bolt threading context (typically the next update).

Normal, Editmode	Immediate
Normal, Playmode, Running	Defer	(Deferred, to avoid threading edge cases)
Normal, Playmode, Paused	Immediate
Coroutine, Editmode	Warn, Immediate	(We can't use regular coroutines at edit time, and editor coroutines can't run Bolt nodes or Waits)
Coroutine, Playmode, Running	Defer
Coroutine, Playmode, Paused	Defer

Ideally, it just executes and everything is happy, but it miiight be the next frame before it can execute.

V - 2.4.1

Updated to support Bolt 1.4.7.

Also includes a minor revision to the C# Defined Events API, which now has a static proxy to facilitate listening and triggering events. This is available in the Bolt.Addons.Community.DefinedEvents as follows:

    /// <summary>
    /// Triggers Defined Event units listening for the passed eventData on the target gameobject.
    /// This is the scripting quivalent to the Trigger Defined Event unit.
    /// </summary>
    /// <param name="target">The game object that event units should listen on to receive the event.</param>
    /// <param name="eventData">This is a filled object of the type of event you want to trigger.</param>
    public static void Trigger(GameObject target, object eventData)

    /// <summary>
    /// Triggers Defined Event units listening for the passed eventData globally.  Note that triggering an event 
    /// globally will not trigger events listening for the event on a particular object.
    /// This is the scripting quivalent to the Trigger Global Defined Event unit.
    /// </summary>
    /// <param name="eventData">This is a filled object of the type of event you want to trigger.</param>
    public static void TriggerGlobal(object eventData)

    /// <summary>
    /// Registers a C# listener for an event on the target object.  This is the scripting
    /// equivalent to the Defined Event unit.  Notice the IDisposable return value, which allows you
    /// to end the subscription for the event (via calling the .Dispose() method).
    /// </summary>
    /// <typeparam name="T">The type to listen for.</typeparam>
    /// <param name="target">The game object to listen on to receive the event.</param>
    /// <param name="onEvent">The action or method to call when the event occurs</param>
    /// <returns>A disposable that, when .Dispose is called, will unsubscribe from the
    /// event, essentially cancelling the call to RegisterListener.</returns>
    public static IDisposable RegisterListener<T>(GameObject target, Action<T> onEvent)

    /// <summary>
    /// Registers a C# listener for an event globally.  This is the scripting
    /// equivalent to the Global Defined Event unit.  Notice the IDisposable return
    /// value, which allows you to end the subscription for the event (via calling
    /// the .Dispose() method).
    /// </summary>
    /// <typeparam name="T">The type to listen for.</typeparam>
    /// <param name="onEvent">The action or method to call when the event occurs</param>
    /// <returns>A disposable that, when .Dispose is called, will unsubscribe from the
    /// event, essentially cancelling the call to RegisterListener.</returns>
    public static IDisposable RegisterGlobalListener<T>(Action<T> onEvent)

V2.4 - Defined Events

New Units!

• Defined Event
• Trigger Defined Event
• Global Defined Event
• Trigger Global Defined Event
• Log
• Some Value

Release video here:

Covers most of the information below.

Defined Events

Defined events are a concept originally created by Discord user AFoolsDuty. We reached out and asked for permission to incorporate the units, but set them aside when the Lazlo revealed the Bolt 2 roadmap, which features an alternate Event system that would render the Defined Events unnecessary.

Recent acrid response to that choice on the Discord servers proved that you all still saw the units as valuable, so after some polish, here they are! Major thanks to AFoolsDuty for pioneering this approach to events, and giving us permission to incorporate them. We've expanded the concept, tweaked performance, and added support for defaults and type filters. None of us had thought about this idea before he presented his units, so again: as much as we've tried to present the best version of the units that we can, none of this would have happened without his ingenuity and permission.

Defined events allow you to write a tiny amount of C# code to provide the specification for the event, and the new units will manage listening, defining ports, and sorting order on the fly. Here's an example snippet of code:

This is a defined event: we've written down the specification in code to specify that the TakeDamage event takes a Damage amount (as an integer), a DamageSource (as a reference to another GameObject), and whether the damage should be considered a critical hit.

We store these in a struct or class and signal that this is a IDefinedEvent. Basically, all this does is tag the struct/class for us to use and track. We use this to show just the list of IDefinedEvents in graph.

Lastly, we tag the struct/class specification with [IncludeInSettings(true)] so that Bolt knows to include this in the fuzzy finder. Whenever we add a type to Bolt using this attribute (rather than the Unit Option Wizard), we have to tell Bolt to re-index the list of Types so return to Unity and tell it to Build Unit Options.

Now, we can add a Defined Event or a Trigger Defined Event in our graph and see our new type!

The Defined Events system keeps track of the available events, their arguments, automatically builds ports, and includes pickers for common types (int, float, string, GameObject, and bool)! If you would like it to build ports for a 3rd-party type, the graph inspector includes a type dropdown that includes all types. Additionally, we include Global defined event support with two additional units:

The Global variants don't take an event target to listen/announce on like Custom Events. Instead, these send the event to all listening units in the entire active scope of your project! To help prevent unintentional triggering of your logic, the targetted Defined Event system and the Global Defined Event system will not trigger each other. Defined Events will only listen for events sent to their event source, and Global Defined Events will only listen for events sent via a global trigger.

In addition, we retain a C# API for triggering from custom code that should be instantly reminiscent of the existing Bolt Custom Event API (available in the Bolt.Addons.Community namespace):

Lastly, If you need to create events for third-party data, you can add them via the Unit Options Wizard, and then use the type filter in the Graph Inspector to select them. Unlike the dropdown on the unit, the one in the graph inspector does NOT filter to just IDefinedEvent types!

In-Editor Performance

Special note should be given on in-editor performance for large projects. While built game code always runs with better performance than working with the Unity Editor, the Defined Events (and Global Defined Events) actually disable some optimizations on themselves when running in the Unity Editor in order to support Bolt Live Editing.

Events in Bolt register to listen using an EventHook, and can provide Bolt with several pieces of information that Bolt uses to pre-sort Events into little bins so that only events that care about a particular Event get activated when an Event comes through the system. By providing more information up front, you get better pre-optimization from Bolt, which is great.

However, this event registration happens only once, so when operating in the editor, the Defined Event system does NOT provide Bolt with the extra Tag for the event type that you, the developer, chose. This allows the Bolt Live editing to work properly as you change the event types in editor to match your requirements, but comes at the cost that each Event is having to actively check for every Defined Event that they see if the event type of the event matches the one currently selected. In effect, support for Live Editing causes the Defined Event system to lose the benefit of the pre-optimization of Events when in the Unity Editor.

In particular, this affects Global Defined Events, as every Global Defined Event, on every GameObject, in every active scene has to inspect every defined event that is triggered anywhere in your active logic! Obviously, heavy use of Global Defined Events will rapidly deteriorate in-editor performance, so, either use them sparingly (chosing to use the targetted Defined Events instead, which do benefit from pre-sorting by the game object target) or disabling support for Live Editing (which enables full optimizations).

The Community Addons team recognizes that certain large game projects might encounter deteriorating performance from the Global Defined Events, and so we have included a special switch that allows you to turn OFF support for Live Editing event types in editor. Turning this option off causes all Defined Events and Global Defined Events to switch to providing the full type information to Bolt, causing proper optimization similar to what you would see from Built code.

To control this option, create a new script in your project that derives from the CommunityOptions class. This class will be found at the start up of your project and will override the default In-Editor performance.

However, once this option has been toggles, you can no longer change the event type on the fly in play mode. Doing so simply causes the event to not fire. Exiting playmode and reentering play mode would be required for the correct event registration with Bolt to happen.

More fun stuff!

If you've used Logs much (we do during development!), having to feed in String literals or constantly using string.Format nodes gets old. So we have a new Log unit that provides a string input that can act as:

• direct input (0 args),
• .ToString() echoer (with 1 arg, and empty format string)
• format string (with >0 args).

Hopefully, this makes getting functional log statements a lot smoother.

Some Value

In our quest to make mocking up graphs for sharing purposes, we have a new documentation unit to help in those circumstances where you know a value needs to be wired up, but you just don't know what.

Also, thanks to Necka for testing, feedback, and reigning in my crazier ideas.

And that's it! Go make something awesome!

v2.3.2 - Bolt 1.4.1 compatibility

Development has slowed while we await Bolt 2 (some units are graduating to official Ludiq nodes!), and at some point an internal API change broke the community units. This release fixes that, and includes a bit of a change to Random Numbers, which now supports AOT Lists.

Please note that this means the existing Random Numbers is now obsoleted, but don't worry! They'll continue to work as they always did, you just have a shiny new node to use in the future!

v2.3 - Editor Events

There are two main changes this cycle:

New unit from Jason:

A unit that can be used to manually trigger logic at edit time. Use this to make your own editor tools!

Please note that this unit will not trigger on its own.

Variadic Branching just got cooler

Branch (Params) received some new modes and now supports:

• And
• Or
• Greater Than (limited to two inputs)
• Less Than (limited to two inputs)
• Equals

This compresses the individual Branch And, Branch Or, Branch Greater, Branch Less, Branch Equals, and Branch Next all into the Variadic Branch (Params) that can take multiple inputs! Not only that, but you can change modes on the fly, and the ports assignments will be kept if possible.

Expect a few minor upgrades to improve the inspector integration on this one.

Misc

Lastly, Math Op now has a graph inspector toggle that allows it to accept non-numeric inputs (say, adding vectors)