Raycast can collide with area even if monitorable property is set to false

[jmb462]

Godot version:
Godot 3.2.3 RC 3

OS/device including version:
Windows 10

Issue description:
When monitorable property of an area is set to false, other area can't detect it as the documention explains it.
But raycasts can still collide with this area.

I know that there is an input_ray_pickable property but it seems very strange that unmonitorable area are not so unmonitorable.

So bug or feature ?
Thanks.

Steps to reproduce:
Set up a raycast and an area with monitorable set to false.
Raycast can still detect aera.

[TheDuriel]

RayCast node should respect the Areas properties. Manual raycasting via physics state should not.

[Xrayez]

Manual raycasting via physics state should not.

Physics servers have methods like area_set_monitorable though, I'm not sure whether I'd want to introduce inconsistency between low-level and high-level behaviors either.

The monitoring property docs:

If true, the area detects bodies or areas entering and exiting it.

The monitorable property docs:

If true, other monitoring areas can detect this area.

Ray cast nodes themselves cannot be considered as physics bodies (they do not affect the outcome by themselves, after all), more like physics/geometry tool.

Ray casts have collide_with_areas and collide_with_bodies properties. So perhaps it would make more sense to rename (#16863) those monitoring properties in a similar fashion (and even splitting them):

monitoring → detect_areas, detect_bodies.
monitorable → detectable_by_areas.

Those properties could also be conveniently grouped in the inspector.

[luis-gmonkey]

Would this be fixed in godot 3.x or only on 4.x releases?

[Calinou]

Would this be fixed in godot 3.x or only on 4.x releases?

It's unknown whether this is actually a bug in the first place. There hasn't been much discussion around the existing behavior (only two people have commented above).

cc @pouleyKetchoupp

[luis-gmonkey]

I understand, but as end-user I think it would be nice to mentioned this at least in the raycast/areas docs.
Since one can assume that when the monitorable is disabled that areas will be excluded from the collision with the ray.

[pouleyKetchoupp]

I'm not sure what the solution will be in the end, but if anything is changed it will be for 4.x only because it will very likely break compatibility.

In 4.x we don't really need these properties anymore since collision layers will be one-directional for areas. That means you can achieve all the same use cases through collision layers, but we can still keep the properties for convenience.

The solution proposed by @Xrayez seems like a good candidate, property names can make things more clear. Having some areas ignored by some raycasts can still be achieved through collision layers.

I understand, but as end-user I think it would be nice to mentioned this at least in the raycast/areas docs.
Since one can assume that when the monitorable is disabled that areas will be excluded from the collision with the ray.

Yes, for 3.x we can at least update the doc to make it clearer.

[avilches]

I think this is a real bug. Another way to see it is if all the shapes inside the Area2D are disabled=true, the raycast ignore the whole area, which is the expected behaviour. This is the workaround I had to do to ignore the Area2D, not big deal, but I guess set monitorable=false should have the same behaviour.
EDIT: the bug still happens in 4.0.0-rc.5

[superoven]

For what it's worth, I would consider this a bug. This is strange functionality and intuitively, I think that if an Area2D is set to monitorable=false then a RayCast2D should not be able to collide with it (if it is set to detect areas).

The idea to rename the properties to be more clear about what it's actually doing is fine, but I would much rather it be possible to disable an Area2D.

EDIT: You can set all the CollisionShape2D children to "disabled" and get this effect. Perhaps this is the proper way to do it? It still feels unintuitive to me, but at least I don't have to mess around with remember to reset all my collision layers dynamically.

[wcjohnson]

For another perspective, I don't think this should be considered a bug. I have a use case where I only need to run raycasts against a particular collection of collision volumes at a certain time (triggered by game events). I don't need continuous monitoring of these volumes, and being able to turn that off while still maintaining the ability to manually ray cast on demand seems like it should be a performance win.

[AThousandShips]

Would add my voice to this not being a bug, I would however say it's a lack of a feature, and that instead of making monitoring control ray casting instead add a separate setting to control this, alternatively add an option in the ray cast to filter on monitorable, I feel it'd be too restrictive to have to pick between either no interaction or all interactions, as mentioned by others there's valid situations where you want raycast and not body interactions and visa versa

[TheDuriel]

There's really no issue with casting, checking if the result contains a disabled area, and casting again if it does.

[AThousandShips]

Agreed, was mostly suggesting alternatives if we want more ease of use with this

My suggestion would be to possibly make this more clear in documentation (though I'd say it is clear enough as it says what it controls) and then close as not a bug, and people can open a proposal for alternatives to how to control this

I'm also guessing that monitorable offers a performance advantage when turned off, making it very useful if you want an area that only recieves rays while not being considered for physics steps for other reasons, but I'm not familiar with the internals