There are three basic types of utility decorator: constant, blackboard, or using a custom blueprint that will evaluate each time the Utility node starts.
Example uses are to add some random variation to AI behaviors, or to select a behavior by weighting various criteria to determine what is most important to the AI at the time.
It’s available in binary form (just unzip into …/YourProject/Plugins or Engine/Plugins) and the source code is also on Github (MIT license). Links and more info here.
This was originally an engine mod and there’s still a chance it might make it in as a PR at some point. It’s been sitting around for a while though, so when I realized most of it could be done in plugin form I figured I might as well release it to the community now.
Enjoy, and if you have any questions or problems with it, just post here. Cheers.
Interesting implementation. Have you experimented with modifying the base BT nodes so you can use all existing BT nodes? I added a utility goal based virtual that is overridden on a sequence and selector and evaluated in custom decorators and tasks and found it to be more flexible.
@dzeligman: I’m not quite sure what you mean by ‘so you can use all existing BT nodes’, or what the meaning of utility would be in the case of a sequence node? If you can explain or give an example of what result can’t be achieved with my setup, I’d be happy to look into it.
I can say though that this was developed with input from Epic’s Lukasz Furman, since it was initially written with a possible PR in mind. As such, it was done in a way so as to:
Minimize changes to existing engine code (obviously since it was converted to a plugin, there are now none).
Add as little as possible in terms of new nodes/new UI, to avoid adding complexity to the BT editor.
Respect some fairly strict rules defining how decorators should behave, and in particular how a composite is allowed to choose child execution based on decorators.
Outside of these restrictions, then of course there is a whole lot more functionality and flexibility that could potentially be added.
One thing I did consider was having a kind of two-tier utility, with utility functions returning an integer priority class along with the float utility value. That would I think allow more easy control over which child was executed, by first filtering children to the highest priority class available, before selecting based on utility value.
When shooting for those goals it makes sense. It def appears pretty simple and easy to extend. What I meant when saying use all existing nodes is being able to do more DFS/recursive based lookup of utility. Independent utility for selectors and sequences. Its possible my current implementation does not obey all decorator execution rules such as latent abort/event based execution as a result.
Right yeah I think I see what you’re getting at. Yep, it’s certainly a pretty simple implementation, though makes it easy to do a lot of things that were hassle or borderline impossible with the default nodes alone. Truth is though I did this as an engine learning exercise, it wasn’t driven by any particular project needs. So as yet I haven’t really made much use of it or tested the limitations.
Am I right in assuming you added the binary form of the plugin into the Plugins directory within your project, and also that your project contains C++ code?
I am having this same issue with another plugin I’m currently developing for the marketplace. As far as I can tell, for projects with C++, UBT assumes plugins should have source code too and generates this error if only the binaries and content exist. Blueprint-only projects with binary plugins work fine, as do C++ projects with plugins with source code. I’m currently awaiting a response from marketplace staff regarding this.
In the meantime, if you clone or download the Github repo linked in the original post, and put the whole thing into your project’s Plugins directory, I think you may find that fixes the problem.
Hmm, is there no output prior to that, detailing the error?
Can you let me know a bit more about your setup - engine version (I assume 4.10), build config (Development/Shipping and Editor/Game), and how you’re building (it looks like you’re packaging? Do you get this error if you just do a straight build, either UBT command line or within Visual Studio?).
Sorry you’re having problems. If you can give me more info I’ll look into it right away.
I just realized I pushed an update for 4.11 to the Github repo, which would cause the latest version of the source on there to no longer build under 4.10.
If you clone or download this commit here, hopefully that will allow it to build from source with 4.10.
I’m currently looking into whether I can somehow make the binary version work with C++ projects.
I’ve been away for a few months so this got rather forgotten.
Have just now uploaded an update for 4.12, available here.
The recommended way to use the plugin with a launcher build is now to unzip this into your ‘[EngineInstallation]/Engine/Plugins/’ folder (as opposed to your project’s ‘Plugins’ folder). I’ve tested it in this scenario and it will successfully package even with Blueprint-only projects.
There is a simple Blueprint-only example project (also at above location), which now relies on the plugin being installed to the engine as described above.