If you have verified that where you are setting the enum it is actually receiving fire, yet the switch on enum is not switching to the choice you are setting. Any ideas?
The reason would be incorrectly set up script. Share it.
1 Like
Morning Everynone, how are you doing?
As you probably already guessed it, this question is connected to this thread.
Ok first off some code and nodes.
I first get if that Y1 box or Y2 box is overlapping.
Next up I check to make sure the NPCs are overlapping the camera actor else every baddie on the map will come to see me @ game start.
I initially tried to use the switch like this.
I figured out that I first rectify the flow to a pulse with a do once node, then call close gate, this will stop the first NPC as soon as he laps the Y1 box, I found I had to also set the collision for the Y1 box to off which will allow the second or other NPCs to walk past the Y1 box and to Y2 because I set the enum…
Well that is how it should work in theory I suppose. What is happening is the first NPC hits Y1 and stops (correct) then the second NPC walks to the TPC capsule and violently shakes left and right at the speed of an Event Tick. But…when that switch was set, I thought it would then choose the second option, move to TPCY2, but it did not. Before I can venture further into Beat Em Up enemy movement behavior…I have to sort this out. Any thoughts or suggestions here are much appreciated.
bump bump
bump
bump bump
Just to recap, I’m trying to get a second NPC to move to a Y2 box attached to the third person character AFTER the first NPC moves to a Y1 box also attached to the TPC.
In theory, as soon as that first NPC overlaps, its going to set the enum to go to the second path on the switch (Y2).
Then from an instanced NPC’s point of view, that first path should become irrelevant.
However, it seems to not be setting the enum and that switch working. Which does not make sense to me because in this next pic and video you will see that set enum node has to be receiving fire because right after it I turn off the collision of the Y1 box, and you can see that first NPC stop as soon as he laps it, if it were not receiving fire that second NPC would also stop and not keep moving!
Hmm, according to a print string, it (the switch) is working, but the movement is not changing…
I am not chipping in because I dislike the method you’ve opted for - I can’t add anything affirmative to this. I believe the movement approach is going to be a major obstacle further down the line - you’ll spend most of the time ironing out the kinks and finding elaborate workarounds rather than focus on gameplay development. We can already see them move funny and glitch out a bit.
When I experimented with this, I set up a long strip of nav mesh and had the AI move to destinations. Not only does it seem more manageable but would also give you a free obstacle avoidance mechanics. And navlinks, and proxies, and zones, and jumping. The entire latent AI system exists for a reason - take full advantage of it. And I’m not even talking about more nuanced Behaviour Tree stuff.
Same goes for damage handling - I often see folks write their own damage system simply because they do not realise a great system already exists! Perhaps take a step back and explore navmesh navigation?
There’s a chance I’m quite wrong and the awkward wonkiness we see is intentional, of course.
1 Like
Thank you Everynone.