Video where i make this project from scratch: • UE5.1 My routine for m... State Tree Overview: docs.unrealengine.com/5.1/en-... I talk about non AI usage and Events here: • UE5.1 State Trees non ...
Some of the bugs i talked about in this video have been fixed and there are some additions in 5.2, watch my update video here ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-4y9KVs4DyrU.html
I said in the video that a variable that has an "input" category doesn't have to be instance editable for it to show, it's true but it will also not work xd. Mark your variables Instance Editable if you want to edit or bind them.
I think I found why event firing doesn't work from within the tasks themselves. There's a very simple bug in the C++. Gonna do a pull request. I'm working on a task that will let you run child subtree assets because they didn't add that for some reason. This resulted in me going into the C++ and I found this bug. This is the C++ that drives task nodes: EStateTreeRunStatus UStateTreeTaskBlueprintBase::EnterState(FStateTreeExecutionContext& Context, const FStateTreeTransitionResult& Transition) { if (bHasEnterState) { FScopedCurrentContext(*this, Context); return ReceiveEnterState(Transition); } return EStateTreeRunStatus::Running; } It needs to be: EStateTreeRunStatus UStateTreeTaskBlueprintBase::EnterState(FStateTreeExecutionContext& Context, const FStateTreeTransitionResult& Transition) { if (bHasEnterState) { FScopedCurrentContext ScopedCurrentContext(*this, Context); //
It's there but not exposed, so yeah, technically i could drag it out of the return node and promote to variable but then i can't use "switch on" node with it. I guess it's a viable solution for simple scripts and i could've mentioned it but you might need that switch at some point, and then you'd have to make workarounds or make your own enum anyway.
@@MrKosiej I could following you and instead of makeing a new enum I draged and promoted. once that I get the newly created variable and drag out and used the select node. and on each option selected what was needed: succeded failed etc
If you refer to context actor class - not really. Circular dependancy would happen if the actor and state tree couldn't run without each other, which is false. They can, but if they're not properly "connected" the interaction between actor and state tree won't work correctly. By connecting i mean adding a state tree component with apropriate asset to the actor and choosing the right class in state tree. But it will still work even if you just choose "Actor". At high level it's just casting avatar to that class so you can access its fuctions. Concluding, you need to set up a single part for that part to work, it doesn't depend on the other part. Unless your logic depends on both way interaction. But that's not in the fundaments of that system.
@@MrKosiej By saying dependency I meant asset dependency since BP classes are all binary assets files on your disk. If your check the reference viewer you can see BP_Enemy is referencing ST_Enemy, then your ST_Enemy is also referencing BP_Enemy which creates an infinite loop. Historicially, Unreal doesn't handle this kind of pattern well as it *may* randomly crash your project if you have too many of these. Also I have to mention that this is quite different from circular reference in your native C++ code which is a normal pattern in coding. Of course if you plan to move your BP classes to C++ then this won't be a problem at all.
