Search Issue Tracker
Won't Fix
Won't Fix in 1.0.X
Votes
0
Found in [Package]
1.0.3
Issue ID
BEHAVB-4
Regression
No
Existing Custom Action nodes retain Action styling when inheritance is changed to Composite
How to reproduce:
1. Create and open a new project
2. Install the Behavior package
3. In the Assets folder create a Behavior Graph (Create → Behavior → Behavior Graph)
4. Open the Behavior Graph
5. Right click and create a new Custom Action node named “Test” (Add… → Action → Create new Action…)
6. Inside the newly created “TestAction.cs” script change the “TestAction” class to inherit from Composite instead of Action
7. Inside the Behavior Graph create a new Action node using the created Custom Action “Test” (Add… → Action → Test)
8. Observe the created Action nodes
Expected result: Both of the created nodes display Composite styling
Actual result: The first created Action node retains the Action styling, while the second one displays the Composite styling
Reproducible with: 1.0.0(6000.0.24f1, 6000.1.0a2), 1.0.3(6000.0.24f1, 6000.1.0a2)
Could not test with: 2021.3.45f1, 2022.3.51f1 (Behavior package is not supported in these streams)
Reproduced on: Windows 11
Not reproduced on: No other environment tested
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Shader Graph Node information is briefly displayed in Graph Inspector when clicking on Category in the Blackboard
- Module installation fails with "Download failed: Validation Failed" errors when using beta.2 Hub version
- JsonConvert conversion fails trying to call GetCallbackMethodsForType when [OnDeserialized] is used in a class
- Shader Graph Category dropdown cannot be expanded/collapsed when clicking on the text
- Different text alignment in the column header in Entities "System" window
Resolution Note:
After identifying the root cause and the potential impact, we’ve decided not to pursue a fix for this behavior. Correcting it would require rebuilding the node with the new type and preserving all existing fields, which is a non-trivial change needing engineering time and testing. Given current priorities, we won’t be able to allocate the necessary resources, and we want to be transparent rather than leave expectations for a resolution.
Workaround:
Delete the affected node and recreate it. This ensures styling and behavior to match the new inherited type.
Resolution Note (1.0.X):
After identifying the root cause and the potential impact, we’ve decided not to pursue a fix for this behavior. Correcting it would require rebuilding the node with the new type and preserving all existing fields, which is a non-trivial change needing engineering time and testing. Given current priorities, we won’t be able to allocate the necessary resources, and we want to be transparent rather than leave expectations for a resolution.
Workaround:
Delete the affected node and recreate it. This ensures styling and behavior to match the new inherited type.