Moving staticBody collision not detectable

[mohamedAdhamc]

making clear that in the case of a moving staticBody the collision won't be detected.

Production edit: Closes #57539

[mohamedAdhamc]

this is a fix to issue #57539 in which someone thought it was a bug that the collision isn't detected but then it was agreed that in fact it isn't and while moving static bodies don't detect collision.

[lawnjelly]

Looking at these docs for 4.x, I have to admit I'm totally at a loss to what they mean, and what @pouleyKetchoupp 's intentions were in #48908. It seems as though in 4.x StaticBodies may or may not be static bodies. 😕 ❓

The docs for 3.x are much clearer on this.

Apologies but this is probably going to have to wait until we have a new dedicated physics maintainer who can work out how this meant to work (or someone who is familiar with how the new physics is meant to work?).

[Diddykonga]

Looking at these docs for 4.x, I have to admit I'm totally at a loss to what they mean, and what @pouleyKetchoupp 's intentions were in #48908. It seems as though in 4.x StaticBodies may or may not be static bodies. 😕 ❓

Yeah the docs definitely need some better explanations, especially around physics. For physics you have a few different scenarios:

1. Nothing - No Body, No Simulation
2. Static - Physics Body, No Simulation
3. Kinematic - Physics Body, User Simulation
4. Dynamic - Physics Body, Physics Engine Simulation

So the only difference between a 'static' body and a 'kinematic' one is simply whether or not the user chooses to change/simulate it. With a 'dynamic' one simply allowing the physics engine to change/simulate it.

[lawnjelly]

1. Nothing - No Body, No Simulation
2. Static - Physics Body, No Simulation
3. Kinematic - Physics Body, User Simulation
4. Dynamic - Physics Body, Physics Engine Simulation

Yes, this is exactly how I expected it to work (and is the model in 3.x I believe).

But in 4.x the docs say this, for instance, which talk more about moving than staying still, and is thus very ambiguous:

A static body is a simple body that can't be moved by external forces or contacts. It is ideal for implementing objects in the environment, such as walls or platforms. In contrast to RigidDynamicBody3D, it doesn't consume any CPU resources as long as they don't move.

They have extra functionalities to move and affect other bodies:

Static transform change: Static bodies can be moved by animation or script. In this case, they are just teleported and don't affect other bodies on their path.

There are also various references I've seen to Statics in "kinematic mode", which leave me completely confused. If StaticBodys are meant to be static (non moving) bodies in 4.x, this should be clearly stated in the docs.

This seems the best reference I've found for pouley's intentions:
godotengine/godot-proposals#2867

Where he says:

On the other hand, some names are less clear.
For example, StaticBody can not only be used for actual static bodies (walls, floors), but also moving platforms. It makes sense to group these functionalities together, but the name can be misleading, especially for beginners. Basically, StaticBody has two modes of functioning: Static and Kinematic (more details about body modes below).

So this new model of physics in 4.x is as clear as mud. 😀

It is probably in a state of flux currently, hence the discrepancy between the docs and the current functionality and behaviour. I'm not quite sure what we can do to "fix" this in the meantime, other than wait for a new physics maintainer to sort this out.

For instance the proposal is suggesting that StaticBody3D would have two modes, static and kinematic. And this seems to be what the current docs are based on. But in the engine, there is no static / kinematic switch (that I can see).

I kind of get the idea, that for e.g. a moving platform you might want to make it static during some part of gameplay, and switch to kinematic at other parts. But I am ending up wondering whether this is worth the confusion versus just making it kinematic.

[AttackButton]

Looking at these docs for 4.x, I have to admit I'm totally at a loss to what they mean, and what @pouleyKetchoupp 's intentions were in #48908. It seems as though in 4.x StaticBodies may or may not be static bodies. confused question

The docs for 3.x are much clearer on this.

Apologies but this is probably going to have to wait until we have a new dedicated physics maintainer who can work out how this meant to work (or someone who is familiar with how the new physics is meant to work?).

Since that by design the staticBody cannot be moved, @pouleyKetchoupp did create a new body called AnimatableBody3D #52286 (and AnimatableBody2D) that can be animated and (as I tested in the MRP) detected by an Area (3D or 2D) when in motion.

So, if you want a moving platform or doors, you need to use an AnimatableBody instead of a StaticBody.

AnimatableBody vs StaticBody and Area 4.0.zip

[YuriSizov]

Suggested change

	[b]Static transform change:[/b] Static bodies can be moved by animation or script. In this case, they are just teleported and don't affect other bodies on their path. Also their collisions with other bodies are not detected.
	[b]Static transform change:[/b] Static bodies can be moved by animation or script. In this case, they are just teleported from one position to another. They don't affect other bodies on their path and don't trigger collision detection in them.

[YuriSizov]

Intentions aside, if this is how it works, I think this is a fine note to add. I've left a suggestion to phrase it slightly better. And the same note should be added to their 2D counterpart (the docs are practically identical).

[TokisanGames]

This PR does not fix #57539. That issue is about Area3D. This PR only changes the StaticBody manual page, and has nothing to do with Area3D. See #57539 (comment)

Also that issue is a duplicate of #17238, which describes the real cause and decision points.

[YuriSizov]

Closing due to lack of consensus about its relevance and lack of activity.