Feature request: renaming classes

[FeastSC2]

I'm not sure how Unity does it, but it detects and keeps the reference of scripts when you rename a class.
I believe they are using the meta files.
This would mean only one task per file but that's really not a problem compared to losing your references in all the behavior trees.

I see you added the possibility to replace once a script is lost, this is nice.
But realistically if I make a change to the name of a class that I often use for my AI, it will be very tedious to go through every behavior tree and manually replace.

Could you try and find a way to replicate Unity's auto-tracking of renamed classes?
That would speed up my workflow a lot.

 

[FeastSC2]

Another question I have is why did you decide to opt for a system that doesn't support Unity's native inspector?
Was that a necessity?

I'm wondering about this because Unity's scriptable objects have native support of attributes.
and if using those or a derivative form is possible, it could remove a lot of work.


Lastly the fact that a tree is linked to a MonoBehaviour instead of an asset surprised me too, it doesn't stick to Unity's usual approach. Did you have any reasons for this?

 

[Justin]

Could you try and find a way to replicate Unity's auto-tracking of renamed classes?
That would speed up my workflow a lot.

The GUID is used in Unity's case, but a GUID is tied to the file and not the class. This is why when you create a new MonoBehaviour you can only have one MonoBehaviour per file. The best route for refactorization is to save the tree in JSON format then you can modify the JSON directly with your new class name.

Another question I have is why did you decide to opt for a system that doesn't support Unity's native inspector?
Was that a necessity?

Yes, for two reasons:
- Allows you to show the inspector within the editor itself versus a separate panel.
- Tasks are objects, and in order for Unity to show the object in the inspector they have to be attached to a MonoBehaviour or ScriptableObject. There isn't a clean way to just see the object inspector.

Lastly the fact that a tree is linked to a MonoBehaviour instead of an asset surprised me too, it doesn't stick to Unity's usual approach. Did you have any reasons for this?

You can use a ScriptableObject by saving to an external tree.

 

[FeastSC2]

Yes, for two reasons:
- Allows you to show the inspector within the editor itself versus a separate panel.
- Tasks are objects, and in order for Unity to show the object in the inspector they have to be attached to a MonoBehaviour or ScriptableObject. There isn't a clean way to just see the object inspector.

Very well.

The GUID is used in Unity's case, but a GUID is tied to the file and not the class. This is why when you create a new MonoBehaviour you can only have one MonoBehaviour per file. The best route for refactorization is to save the tree in JSON format then you can modify the JSON directly with your new class name.

Understood.

Is there a way you could make a tool to support quick refactorization?
It would go through all Behaviour Tree components and Behaviour Tree assets in the project.
From there you could write the old class name and modify those lost references to a new class name.

Modifying prefabs and the BT assets should be simple enough.
And then for the non-prefabs, you would need to actually open up and modify scenes.

Now even if you end up supporting only some of those (assets, prefabs, non-prefabs) this would already be quite useful.

 

[Justin]

Refactoring is an interesting use case for visual scripting. Having some type of an (semi)automated solution would be awesome, and I have added this to my list for things to research.