InputContext 'Sink' property doesn't behave properly

[Jackfruitfruit]

The ‘Sink’ property for InputContext is documented to disable events for contexts of lower priority that use the same keybinds. However, lower priority contexts still receive events like .Pressed even when a higher priority context with a binding that uses the same keybind has Sink = true.

Expected behavior

Lower priority contexts should not receive events if sink is enabled for a higher priority context that uses the same keybind for an action.

[runitbackrolfo]

Hi @Jackfruitfruit,

Thanks for the report. Could you provide us a minimal repro file that demonstrates the issue for us to take a look at?

[Magus_ArtStudios]

Are you sinking the input properly? Check out my sink input module.

local ContextActionService = game:GetService("ContextActionService")
return function (duration,Player)
	Player=Player or game.Players.LocalPlayer
	local FREEZE_ACTION = "freezeMovement"
	Player.Character.Humanoid:ChangeState(Enum.HumanoidStateType.GettingUp)
	--stopanims()
	ContextActionService:BindAction(
		FREEZE_ACTION,
		function()
			return Enum.ContextActionResult.Sink -- need to explicitly return this
		end,
		false,
		unpack(Enum.PlayerActions:GetEnumItems())
	)
	local function release()
	ContextActionService:UnbindAction(FREEZE_ACTION)
	end
	if duration then
		local taskcancel=task.delay(duration,release)
		return release,taskcancel
	else 
		return release 
	end
return release	
end
--local sinkinput=require(game.ReplicatedStorage.GlobalSpells.Questing.Util.SinkInput)(duration,Player)--returns string

[Jackfruitfruit]

hey, it seems inconsistent as I’m able to properly sink inputs when creating new instances but these are copy pasted from the broken project. Press buttonY on controller and you will see that both priorities print in output when only the higher one should print.
sink test.rbxl (59.5 KB)

[Jackfruitfruit]

this post has nothing to do with contextactionservice

[Jackfruitfruit]

I can’t tell if I’m going crazy or if I’m missing a mismatched property. Any assistance would be appreciated.

[runitbackrolfo]

Hi,

Thanks for following up! It looks like the hidden PressedThreshold and ReleasedThreshold properties of the InputBinding instance under the “1” context have been set to 0, which causes the Pressed signal to fire. To fix, you can select an analog keycode such as ButtonR2 to show the hidden properties again, re-set them to PressedThreshold=0.5 and ReleasedThreshold=0.2 defaults, and then select the ButtonY keycode again.

We’ll also look at fixing the logic here in the future as well to ignore PressedThreshold / ReleasedThreshold for non-analog keycodes so this doesn’t happen again.