This is a dire warning to anyone that uses source control and the behavior package together and a plea to the team to look into this. Let me explain what I mean with what I just experienced.
I’m currently working on a small project with only a few people on the team. We use git for source control as is pretty standard. I’ve spent the last few days working on pulling in the Behavior 1.0.6 package and putting together a behavior tree for some NPC agents in our project. This includes custom actions and conditions. After nearing the end of this bit of work, I stashed my changes in git, pulled latest, and went about fixing conflicts to get my stuff ready for putting up for a PR. Conflicts weren’t too bad, none of it was related to the Behavior package as it hadn’t been pulled in before my stashed work but I did have some compiler errors to fix from the latest changes that came in with our project work. I went about fixing the script errors, fixed some prefab things that needed redone, some scene fixes, you know, standard stuff. As I was testing the behavior agent before pulling latest, I still had the behavior graph window open to that graph but didn’t pay it any attention at first.
Once I had all of the compiler errors fixed, I went to tweak something in the behavior graph only to now notice that I had a red warning that there were “# Placeholder nodes” and I could swap between them to inspect them. Every one of my custom actions had been replaced with a Placeholder node (I’m assuming because the compiler errors prevented the custom action classes from compiling). There was no way to reconnect the (now compiling) actions to replace the Placeholder nodes. However, that was only the beginning of the problem, and the only one that it actually warned me of.
In total, I found out the following:
- All custom actions I had written had been replaced by Placeholder nodes and written into the .asset file as Placeholder nodes
- All custom conditions that I had written were gone entirely
- All blackboard variables that were based on custom classes were also gone
It had saved all of these changes out to the .asset file of the behavior graph with no warning or confirmation that it would do so and overwrite large swaths of work. The actions weren’t as bad as it at least tried to maintain the name data of the custom actions so I could have remade most of them based on that. The conditions disappearing with no indication of what was there is unrecoverable. My graph wasn’t very large and there were parts that I could not easily recall what those custom conditions would have been set to. I can only imagine the nightmare this would wreak on a far more developed behavior graph that has had months of additions and tweaks potentially wiped out simply from day to day development when using source control.
To the team, I can think of two ways to resolve it:
- Never save Placeholder node information into the asset file, allow it to fail and force the user to fix the issue themselves. Also never strip conditional and variable information if its not understood (IE, isn’t compiled yet). Treat it like editing a prefab in isolation where you are stopped from saving if there are invalid monobehaviours detected.
- If you must save Placeholder node information, detect that, and before saving, warn and confirm with the user before allowing the .asset to be blindly saved.
I do like the package. It’s got plenty out of the box to get most people started pretty well into behavior trees. It’s also relatively easy to extend, but could definitely use more documentation on its existing components and more than just access to the scripting API for more engineer focused people looking to extend and use more of its capabilities. Yes I can (and did) spend hours digging through the source files figuring the system out (including adding temp logs when trying to sort out issues), but it would be much easier and more time efficient to have that be in the documentation. I’ve found some other minor gripes along the way, but most of those I can work around to varying degrees of success.
This issue, however, makes me incredibly nervous to use this package anywhere near a larger team or a production environment if tons of data can be wiped out with little to no warning.
For those worrying, I was able to restore a stashed version of the .asset file in question without all of the removed/Placeholder node information so I was able to fix my instance but it will likely happen again in the future. I hope you guys are able to look into the issue and figure out a good solution that doesn’t lead to losing a lot of work with custom actions/conditions.