@Tomnnn said:
Sorry to bump my own post, I don't see a way to edit?
No worries! You can edit your opening post anytime through the little gear icon in the top right of the title. If you select it, a drop down should appear that will let you edit the post.
I think I found my answer, would still appreciate anyone to confirm. I see the documentation for kinematic body mentions it is a good choice for doors / moving bridges. If it is suitable for those, I assume it won't be super expensive and is probably what I'm looking for.
Probably. A KinematicBody is essentially a tailored RigidBody under the hood, but has several helper functions that make it easier to control. It shouldn't be too much more expensive than a normal RigidBody node, performance-wise.
One question I do have after reading the docs - what is "manually moving" referring to? Is that the api for move_and_collide (and similar) or are the docs actually stating I can directly affect the transform origin (either via tween, animation, or just adding a vector3 to it) and it won't break the physics system? If that's the case, this is a lot simpler than I thought. I just wouldn't have expect that with my experience from other engines.
I think when the documentation is referring to "manually moving" nodes, it refers to directly changing their position, rotation, and scale, rather than letting the physics engine handle it. Direct manipulation can lead to issue with physics, so its often desirable to avoid or use the _integrate_forces (I think that's what its called. The RigidBody documentation should mention it) function, as then you can manipulate the node directly without the risk of causing strangeness with the physics engine.
You can manipulate the node directly in _physics_process, it just may cause some issues in corner cases with the physics engine. I haven't noticed too many issues in my own projects, but your millage may vary.
