Hello.
Let me explain my project setup a bit.
I have an Assembly Definition called App in Scripts folder, that has Root Namespace set to WG. All scripts are under WG namespace.
The App (Assembly Definition) is added to Project Settings > Visual Scripting > Node Library.
Now, UVS fuzzy finder doesn’t see any of my scripts, but it does have all the nodes I’ve setup before update.
Example:
A graph setup before update:

Current fuzzy finder:

Script code:
using UnityEngine;
using UnityEngine.UI;
namespace WG.UserInterface.Match
{
public class ErrorScreen : BaseScreen
{
[Header("Visual Scripting Vars")]
public Button FindOpponent;
public Button Exit;
}
}
If I go to Project Settings > Visual Scripting > Type Options, I can add each script, and it will work. I can’t add the namespace though, and I just can’t add everything one by one there.
Any other solutions? Please!
I’m gonna guess that your assembly has some Unity Editor references.
Unity recently decided that UVS graphs have to compile 100% of the time. The problem being editor only nodes that wouldn’t allow to complete the build for IL2CPP platforms when UVS generates AOT stubs for those editor only nodes.
To achieve build compilation in all use cases, they decided that any assembly containing even a minor Unity Editor reference therefore is to be discriminated against. This has resulted in two issues: no assembly with even a minor #if UNITY_EDITOR conditional code will generate AOT stubs for IL2CPP builds. The same assembly nodes won’t also come up in search when added to the node library and only become accessible when adding individual types, which is your problem. Note that individually added types will still break IL2CPP builds because no AOT stubs will be generated for their reflected nodes.
Funny thing is that this change also broke their native first party tooling like Cinemachine. The build will compile but then throw errors on the target platform since no AOT stubs are generated for Cinemachine nodes. Sometimes it feels like the Unity people working on this have no clue how Visual Scripting is used and what impact such a major change has on nearly all projects using the tool.
More info in this thread: No AOT code generated for a monobehaviour
1 Like
This way above my knowledge. I will look into it and try to find a solution.
Thank you for your reply.
There is a workaround, but it’s very involved: No AOT code generated for a monobehaviour
Unity are aware of the issue. But I’ve no clue when or if this is getting fixed. Using an older version of UVS before they split assemblies into two categories - runtime and editor - would also help. I think this was introduced in 1.7.7 so 1.7.6 might be good.
Yes, 1.7.6 seem to work as expected at first look.
With 1.7.8, besides the missing units, after each Unity restart, I’ve had missing ScriptableObjects references. After each restart I had to reference again some ScriptableObjects. (lucky I have around 10 and I can remember them)