godotengine
Add option `throw_error_with_invalid_path` to Project Setting and remove cache error from `AnimationTree`
Fixes #65608 Supersedes #68998
There are two reasons for the #65608 spamming:
First, when caching tracks, if they contain invalid paths, they throw an error and are not cached. The iterating is done on the list of tracks, not on the list of caches. If the cache is not found when iterating on a track, AnimationTree throws that error every frame.
#68998 tried to remove that error, but I didn't really think that was a good way. However, after I looked into AnimationPlayer, it doesn't throw errors in the same case, so it seems to be acceptable, I apologize for that.
However, there is another cause for spamming. If a large number of animations and a large number of track paths cannot be resolved, a large number of errors can occur during caching. This means that this can happen frequently with 3D skeletal animations.
Considering the existence of retargeting and duck typing recommendations, it might be fine that not to throw errors even for invalid paths. So I added an option to Project Setting to disable checking for paths in AnimationPlayer/AnimationTree.
disable checking for paths in AnimationPlayer/AnimationTree.
I think being able to playback animations without halting is better than catching errors.
It feels less of a landmine.
Okay fixed. Checking path needs to use has_node(), not has_node_and_resource().
I'm not convinced that this is the right approach.
First of all the added project settings are a bit awkward (new "Animation" top level category just for two new sections with just one equivalent setting each... that doesn't look good user friendly).
And making logic dependent on a setting most user won't even find also doesn't seem satisfactory. Users will still get spammed, report a bug, be told it's a feature and they can disable it, and then possibly miss situations where things are actually warning for a reason they need to be aware of.
Well yes. Honestly, I am not so much in favor of hiding these errors. We should be a bit more cautious.
I prefer no warning over halting the game for a few frames, because you can't debug halting.
Apart from this option, I think https://github.com/godotengine/godot/pull/68998 can be approved in one case. It seems to be consistent in behavior with AnimationPlayer.
Discussed in animation meeting, we kind of agreed the project setting isn't really a great solution. We need to rethink this one.
