Josh

You are correct. Thank you for the simple instructions, I have seen this occasionally happen, but your example gives me a very easy way to produce the error.

Added to project templates, for Lua and C++.

Okay, so currently the scene stores a unique position/rotation/scale for every objects, including sub-objects of prefabs. Changing the object's position in the prefab will not change its position in the scene, because it already has one that is established. This is by design, because otherwise there would be no way to reposition sub-objects of a prefab, they would just always be frozen in place, relative to the parent.

Yes, this is much better.

There doesn't appear to be one simple state that tells you what the recast navigation agent is doing. I'm sure the info is in there somewhere, but it will take more time to figure out exactly how it works and what information is available.

Let me see if I even have any functionality like that in Recast...

Not currently. I usually just do a distance check between their position and the destination, and if it's less than a certain amount, I consider them to have reached their destination.

Yeah, you are constantly creating timers, and you are waiting for an event inside the update loop! You probably want to do this: function MyScript:Update() if player:GetPosition().y < -5 and self.enabled == true then self.enabled = false if self.gTimerReborn == nil then self.gTimerReborn = CreateTimer(2000) self:ListenEvent(EVENT_TIMERTICK, self.gTimerReborn) end --self:Kill(player) --self:Start() end end function MyScript:ProcessEvent(event) if event.id == EVENT_TIMERTICK and event.source == self.gTimerReborn then player:SetPosition(initialLocation) self.gTimerReborn:Stop() self.gTimerReborn = nil end end

Thanks for the suggestions. Would love to see how you are using the terrain. It sounds like you are doing some very interesting stuff.

I can't answer this without seeing your project.

Closing due to lack of response...

5.0.2 Beta Full update for bug fixes, see details here: https://www.leadwerks.com/community/forum/120-bug-reports/?filter=solved_topics

In our game, there was a problem where a call to window->FlushKeys() was resetting the key down state, making the invetory screen flash on and off.

You don't want your characters to act as a navigation obstacle. That will make their volume get removed from the navigation mesh, and may be the cause of your problem. Navigtion agents will avoid each other using the built-in crowd system.

Updating graphics drivers will likely solve this problem. Closing this due to lack of response. If you have still have problems feel free to let me know.