CAS priority at which MouseButton1 does not interfere with ClickDetectors, Tools?

I am attempting to create a “coyote time” feature for click detectors. The click detector targets are moving relatively quickly on the screen, and as a UX feature, I want players to be able to click on the click detector even if it’s moved out from under their mouse. To that end, I’ve created a system that tracks the last click detector the player has hovered over. The part I’m struggling with is the click input.

I attempted to BindAction using Enum.UserInputType.MouseButton1 as the filter, but this breaks click input for ClickDetectors and Tools. Both are important parts of the game, so I have to keep them working.

I tried to BindActionAtPriority as low as -100 and it was still a higher priority than click detectors and tools.

The actions are bound once at the start of the client session - there’s no reason the bound action should have a higher context than tools and click detectors that I know of.

Is there a better way to get click input while filtering clicks meant for tools and click detectors?

I believe the Default ContextActionPriority, which Tools and ClickDetectors use, is exactly 100.

Try using 99 or:

Enum.ContextActionPriority.Default.Value - 1

Unfortunately, 99 does not work, 101 does not work, and

Enum.ContextActionPriority.Default.Value - 1

does not work either.

Could it be, that your input-handler would need to return Enum.ContextActionResult.Pass?

I needed to do that, for my ‘Rolling Stock Removal (for Ro-Scale)’ script, so turn-tables would still be ‘clickable’.

2 Likes