Physics don’t sound like an ideal way to move zombies, they’ll probably end up looking like they’re skating. It’s more suited for real world simulation.
I would have thought pathfinding will work as a way to move zombies. Maybe you can share a screen snip of what you’ve done already?
My understanding is pathfinding uses forces for movement, not physic’s so that’s why it would not be moving with both behaviours enabled by default.
Although I have not tried it (beyond the quick example below), you could still use pathfinding to find a path then using physics to move the unit to the next node along the path.
Above is a VERY basic implementation.
Thank you very much for your help, I had not thought of this kind of solution. now it seems to work. I have one last question… the player is controlled by joypad and moves through a variable (speed). same thing as enemies does not move if physics is added. I attach photo code so as to better understand
how can I implement physics by moving it with the speed variable?
My first thought is that your JoyStick.Speed is 0. To confirm this, I’d suggest you add a output to console action in this event :
and output the two parts of the equation (LeftButtonBackgroud.Distance(LeftButton) * 100, and LeftButtonBackgroud.Variable(JoyStick.JoySinstanceMaximun). then run the debugger and check the output.
thank you so much guys it works!
I need to ask you one more last question.
I have not previously applied physics to my game and used the classic pathfinding behavior.
when the player was not seen by the enemies, they moved in random position.
now with applied physics, enemies get stuck very often when passing pathfinding nodes.
how could I do to overcome this obstacle too?
I would like the enemies to move to random locations in the room
no the problem is created when the player moves to random points of the map … as you can see from the video it is like it was jerky. while if forced to chase the player moves without any problem.
Is the above action the only pathfinding command used?
Also, best practice is to use a “Has destination been reached” condition. And you should also check there is a path was found following a “Move object to…” action (use the “Path found” condition)
the other event is this below
when the variable enemy alert = 0 I would like the enemies to wander randomly around the map in search of the player
when the variable alert of the enemies = 1 the enemies follow the player (it works correctly with the event set as an example above by Eiklahc)
the problem arises when the variable alert is 0.
it is as if the enemies are repeated several times the same action and vibrate in that way.
You’ve missed the drawing of the path nodes - the nodes don’t just appear by magic. So not just the Move commands, but all pathfinding related commands, be it conditions or actions.
Do you change the nemici’s position anywhere? Either by using a force or by setting the X & Y position? Are there any other behaviours attached to nemici?
yes, in addition to pathfinding, I’m using physics to move enemies
pathfinding creates the path and physics makes them move as suggested by Eiklahc
Ok, I think you’ve misunderstood what @Eiklahc meant. He meant just use physics to go from node to node, not a combination of pathfinding Move command and physics forces.
So in a nutshell, you’ll find a path, get the nodes, stop character from moving and move character from node to node using forces.
It’s either one or the other; pathfinding or force. but not both.
ah ok now I understand … I thought you could use pathfinding behavior to set a path and then move the object with physics node after node. physics managed very well the collision between enemies precisely I was looking for a solution of movement using physics. at this point I will try to use physics only when enemies collide with each other. Thanks again and sorry for my misunderstanding
I think we’re all a little confused currently.
@MrMen if you have physics enabled for an object, it can no longer use forces for movement and you have to (afaik) use physics for the movement. (which is what OP wanted in the first place it seems)
@kevino93 Depending on how much pathfinding is required + amount of units I’d suggest not running the Move (Pathfinding) every frame. Currently in a personal project with around 150 objects and fairly basic blockers 0.5 seconds seems pretty decent when it comes to updates.
I should have been clearer - by forces I meant Physics forces.
But won’t the OP need to stop the pathfinding movement, otherwise the movement and physics will interfere with each other, and possibly the reason for the jittery movement?
I know I was getting glitchy/jittery movement when using LastNodeX()/LastNodeY() + Physics + Regular update of the path (every 0.5s).
I have fallen back to using NextNodeX()/NextNodeY(), although it’s not true pathfinding as it’s really just having the object go towards the last last node it seems.
I probably need to work out some custom logic using the NodeCount() and GetNodeX()/GetNodeX() but with the destination constantly moving and updated 0.5s its not really an issue atm.
I too am using the nextnode code as you suggested, but I’ve noticed that (usually on the first node) the object start to move glitchy. Let me know if you’re able to find a solution. Thanks
So I decided to create a project today to work on pathfinding + physics to see if I could create a method to simulate the movement of node to node with physics and came across a weird interaction/feature.
Even with physics enabled and the object not moving, there is some kind of “ghost” that is still moving along the path based on the Max Speed of the pathfinding behaviour.
This means if you’re able to match up the speed of your physics movement and the movement of the “ghost” using NextNodeIndex() should work.
Using an impulse force (with all physics behaviour default other then both dampening’s being at 10) it seems 50% of the path finding max speed /10000 works fairly well (Pathfinding Acc at 999, Max Speed at 60, Impulse at 30/10000)
(Blue is not using physics and is the control)
Using forces (physics/not impulse) it seems to be max speed + 100 /1000 (Pathfinding Acc at 999, Max Speed at 60, Impulse at 160/1000)
(Blue is not using physics and is the control)
Depending on the speed of the unit, I think physics force is better option then impulse as it feels much smoother.
EDIT: It seems that +100 scaling for non impulse isn’t correct when using a lower value (such as 15) so you might need to setup a test like above to get the ratio correctly otherwise you’re going to have VERY zippy enemies 
Thanks for the explaination. I’m following your codes, but I didn’t quite understand the code:
Those numbers are just what I used to match up the speed of the “ghost” with the movement via physics when using 60 as a speed.
You’ll have to match up the both the pathfinding speed with the physics speed your self (for example for the movement speed of 18/1000 (physics force) it was around 45 for the pathfinding max speed)
