Visual scripting and Addressables

I just started using VisualScripting and I noticed that a ScriptGraphAsset can be set as an addressable. It also sounds like script graphs don't require compiling.

Question 1: Deployment.
Based on this it sounds like I can add logic to asset bundles. So I can just redeploy the asset bundles rather than creating new builds and waiting a few days for them to be approved. Examples:

• DLC levels, characters
• Bug fixes
• New events / game modes

Is this a supported feature of VisualScripting?

Question 2: Mods
If question 1 is true then does that also mean I could have users create mods by creating new asset bundles e.g. new character => art, sound, logic (VisualScript)?

 

@CodeKiwi Thats correct. The game I'm working on right now does exactly those things.

Keep in mind tho, that any content crated that way, be it DLCs or Mod-support, will only be able to use compiled c# code (including potential custom nodes) that you ship with the game or patch into it the classical way.


EDIT: We're using AssetBundles tho, but in theory it should work with Addressables as well. The downside of addressables right now is that, afaik, you can't easily add addresses dynamically - thats why we're still using the "old" way of loading assets by names.

 

Depends on what you're targeting. It can work on Mono platforms, which allow runtime code generation. UVS does a lot of runtime code generation with its reflection based runtime.

But anything with IL2CPP scripting backend requires a AOT prebuild step that only runs in the editor. So adding graphs containing new nodes that aren't included in the base game and therefore don't have AOT stubs generated for them by the AOT pre-build step won't work.

The workaround being having a master graph that includes all nodes used in the game and ships with the base game so AOT stubs get generated for them. In that case, you can ship graphs as DLC but this is pretty hard to track and you also have to plan pretty far into the future.

"DLC graphs" is one of their under consideration items on the roadmap. Not sure if it's still happening or not.

 

Hi! Sorry for necro-posting, but I have exactly the same problem. I would like to support all nodes imported via addressables in a WebGL build.
I tried to generate and insert nodes by searching among the IUnit classes found in

AppDomain.CurrentDomain.GetAssemblies()

but many nodes are still unsupported (it finds around 340, of which 300 are instantiable).
On the other hand, importing them all by hand is unthinkable, given how many there are.

How do you recommend I generate this "master graph" without losing my mind?
Thank you!

 

I haven't seen anyone cracking this problem reliably and fully automatically. I'm sure it's possible with a ton of effort, but there are no straightforward fixes to this issue.

 

Hello @massimiliano1109, @PanthenEye,

Recently I have been able to manipulate the VisualScripting package in order to generate automatically AOT Stubs for most Unity APIs.
For my project it has been quite reliable so far (I just needed to make a few changes one time after upgrading from Unity 2021.x to 2022.x). I can successfully load new Visual Scripts from AssetBundles/Addressables.

Currently it's working on Unity 2022.3.7f1 with the VisualScripting 1.8.0 package on WebGL and Android (with IL2CPP enabled).

What I have done:

• First I have embedded the VisualScripting package directly into my project
  • In the Project panel locate the Visual Scripting directory.
  • Use context menu > Show In Explorer
  • Copy the VisualScripting directory to your project Packages directory
  • In Packages/manifest.json you can remove the VisualScripting package entry (not sure if it is necessary).

• Then I have modified the AotPreBuilder.cs file in (Packages\com.unity.visualscripting@1.8.0\Editor\VisualScripting.Core\Platforms\)
  • My file is in attachment.
  • Line 231, at the end of the FindAllProjectStubs() method, I call a custom function trying to find most of the AOT Stubs from common Unity namespaces ("UnityEngine", "UnityEngine.UI", "UnityEngine.Networking").
  • Starting Line 268, I use several sets of strings to filter in namespaces and filter out specific types, members, attributes, etc... which are not compiling when building (because probably only available in Editor).
  • It took me a lot of trial and errors to find out which type members I needed to specifically filter out, and I believe if I need to add more packages or Upgrade my Unity editor I might need to update this file.

• When building your application the AotPreBuilder.cs file creates a temporary AotStubs.cs file into your project (in Assets\Unity.VisualScripting.Generated\VisualScripting.Core)
  • Without the modifications, in my project the AotStubs.cs file is 11,612 lines
  • After the modifications it's 201,579 lines!
  • but it doesn't look like it makes the build significantly larger or longer to compile

 

Wow, you are so kind to share this solution that cost you hours of your work. I also eventually found a similar way to populate the temporary AotStubs.cs file, but it's not as elegant as your solution. Thank you so much.

 

Thats really cool. Thank you very much you solved a year long problem for me.
I was wondering if it is possible to turn the it around to only use namespaces that are whitelisted?

 

Hi @Elin042,

I have based my custom FindAllProjectStubs() method on the original FindAllSettingsStubs() method (line 254).
First there is a call to Codebase.Subset(...) (line 359) to retrieve a large database of C# members available in the project.
Then my code is iterating the members and filtering them by type, namespace or other details.

But I haven't really took the time to try other parameters in Codebase.Subset(...):

• I guess the second and third parameters can be used to filter the members types and kinds (public, field, property, method...), this may help to simplify my filtering code but I haven't took the time to run some experiments.
• The first parameter of Codebase.Subset(...) is a Type collection, I haven't changed it either, I use Codebase.settingsTypes which to my experience returns types from most assemblies.
  But when I take a look to Codebase.cs, it looks like Codebase.settingsTypes is populated by some types found in Codebase._assemblies which is created with AppDomain.CurrentDomain.GetAssemblies().

So in theory we could write something to list the assemblies we are only interested in (the namespaces we want to include), extract the types and filter them with Codebase.Subset(...).

For sure it would be a cleaner solution. But I am no expert in the VisualScripting package sources (or System.Reflection) so it might take me several iterations to get it working.
Today I have something which is working for my project, but the day I need to come back to AotPreBuilder.cs I will maybe try to use Codebase.Subset(...) the right way.