I notice that AILerp moves the object by simply moving its transform.position. I’m not that advanced, so I’m not sure if this is exactly right, but I’ve heard many times to avoid simply moving the object’s transform when moving bodies in Unity projects that use Unity physics and to instead to change the velocity or use forces (like rigidbody.AddForce).
Is this accurate?
Is it possible or reasonable to forgo the transform.position movement created in AILerp’s Update() method and somehow hook in my own custom force-based FixedUpdate() movement?
There’s nothing inherently wrong with changing a Transform’s position, since that’s essentially what is going on under the hood when you use physics, anyways.
You could surely use some other custom script that leverages RigidBody forces to move a Seeker with physics, but it’s trickier to get that type of movement to follow an exact path, which is what AILerp is for.
Thanks for this.
Why do so many people, Unity devs included, say to avoid transform.position movement, then? Is it different here due to the way that movement and physics is handled in A* Pathfinding Project?
AILerp is intended to follow the path exactly, not to use physics for movement. If something should use physics to move around, you probably don’t want to use transform.position because that just bypasses the physics system, however if you simply want something to move exactly how you tell it to move then it is the right way to do it.
Would you say that physics movement is compatible with the ‘can move’ method of AILerp?
Perhaps I’m misunderstanding the intention of the ‘can move’ method. What kind of movement is it intended for? The reason why I’m confused is that most Unity projects seem to employ physics-based movement using rigidbodies and forces, etc.
It is intended to be used with AILerp, to tell your Seeker whether or not it “canMove”, obviously. This has nothing to do with physics, and is simply a flag to tell AILerp whether or not to run the Pathfinding code in Update().
That is true for some Unity projects, sure. The projects that use physics-based movement, and (though I’m not 100%, as I haven’t used them) that is probably the case with other AI scripts in this asset. AILerp isn’t one of those scripts, and doesn’t interact with physics, instead using lerping to move along an exact path.
Thanks for the explanation.
I’ve tested a bit using the seeker and rigidbody obstacles. The seeker seems to move objects just fine, though I recall the physics interactions from previous tests to be a little strange.
Can you foresee any problems with physics/rigidbody-based objects colliding/interacting with a seeker object that is using the AILerp script?
The way AILerp is written does not really lend itself well to using physics interactions, you can of course modify it however you see fit to make that happen, but you are going to have to change quite a lot.
Thank you.
Is AILerp and A* Pathfinding Project simply not meant for games that use physics-based movement and interactions, then?
Please help me understand: what is A* Pathfinding Project used for if the pathfinding objects are “out of bounds” for such interactions?
Exactly. AILerp is currently the only movement script that supports 2D movement, the other ones that are more suited for physics based movement (AIPath (and RichAI for recast/navmesh graphs)) only work in the XZ plane at the moment.
Thank you.
I see - this is more so a lack of 2D features issue, since the other scripts for 3D are suited for physics. Are you planning on implementing more 2D support in the future?
Hi
Yes, I am planning to rewrite my movement scripts so that all of them can be used for 2D and for 3D.
Good to know, thanks! I’ll be waiting for the update.