Why InputChanged is being fired when the character is being moved by keyboard?

[rogeriodec_games]

Why InputChanged is being fired when the character is being moved by keyboard?

local UserInputService = game:GetService("UserInputService")
 
UserInputService.InputBegan:Connect(function(input, gameProcessed)
    print("InputBegan")
end)

UserInputService.InputChanged:Connect(function(input, gameProcessed)
    print("InputChanged")
end)

If I press some key that doesn’t move the character (Shift, for example), InputChanged doesn’t fire. But if I move the character with W, for example, InputChanged is fired repeatedly. Why? Any way to avoid this?

[MFCmaster1234]

Here is the answer to your question. It;s always best to look for the answer before you ask the question I hope the link answers your question.

InputChanged doesn't seem to fire if the input is from the Keyboard/MouseButton presses

As the title says, InputChanged doesn’t seem to fire at all if the input comes form the keyboard OR if it comes from mouse button presses (e.g. left-click, right-click, etc). Simple repro, in a LocalScript that spawns with the player (for example, in StarterGui): game:GetService("UserInputService").InputChanged:connect(function() print(tick()) end) This will not print the time if you press a button on the keyboard or mouse. It will if you wave around the mouse. Not sure if InputChanged was m…

[AdjacentPhoenix]

Instead of using UIS.InputChanged I’d recommend this service instead.

ContextActionService | Documentation - Roblox Creator Hub

ContextActionService:BindAction(INDEXSTRING, FUNCTION, false, Enum.UserInputType.MouseButton1, Enum.UserInputType.Touch, Enum.UserInputType.Focus)

If you are doing a toggle of when the Shift key is pressed use;

UIS.InputBegan(function(Input, GameInput)
     if Input == Enum.KeyCode.LeftShift then
          LeftShift = true
     end
end)

UIS.InputEnded(function(Input, GameInput)
     if Input == Enum.KeyCode.LeftShift then
          LeftShift = false
     end
end)

[rogeriodec_games]

@MFCmaster1234

It;s always best to look for the answer before you ask the question

I had looked for this topic and I created a new one because I didn’t see an answer for my question there.
What’s the answer?

[rogeriodec_games]

However, it works for the keyboard too.
And don’t think the answer is just “don’t use it”.
If it’s an incorrect behavior ( InputChanged is being fired when the character is being moved by keyboard), it must be fixed.
Otherwise, there must be a logical explanation for that.

[MFCmaster1234]

Are you moving your mouse at all when you move? Consequently. What is your question? I’m happy to help you with a specific guide to do something with scripting, but if you don’t tell us what you want to do in game, then what can we do?

[colbert2677 (ThisMangaOnHiatus)]

InputChanged fires because your input changes. You can check the type of input being passed via the UserInputType parameter in the InputObject. It will fire with Begin when you start moving and End when you stop moving.

Pretty sure Shift is occupied by the ShiftLock action. Try disabling shift lock and see if you get the same behaviour. GameProcessed may also fire with a different value. The behaviour of shift changes depending on if you have shift lock on or not: locking has higher precedence.

[MFCmaster1234]

My apologies. I just noticed your question is… basically asking why something is happening wi th in Roblox studio that is a part of the studio environment. Not an actual request for soemthing you want to happen, but rather a question regarding API. The person right above me answered in kind. And upon further research, according to their own API InputChanged does fire on keyboard down.

[MFCmaster1234]

Oh. I do recommend following the other other responder’s advice and using ContextActionService for controlling multiple aspects of a game in different contexts of the game with the same key. E.G. waving vs honking a horn in a car vs typing Hello depending on context.
Again I’m sorry. I made the mistake of relying on someone else who asked the same question but got an incorrect answer.

[rogeriodec_games]

Sorry for insisting on this matter, but I still haven’t had any answers to my question.
In my understanding (and as also described in the documentation), InputChanged might be fired only when some input event is fired. It’s not stating that it must be used only for mouse events: Mouse button down, touch begin, keyboard button down, etc).

Try the sample in my op:
Keys that have no effect on rendering will not trigger InputChanged, for example: (Left or Right) Shift / Control / Alt, also CapsLock and others. These keys will only trigger InputBegan (and InputEnded if applicable).

However, keys that in any way forces some changes in rendering, will fire InputChaged.

This way, I have to adapt the logic of my program to overcome this issue.

[AdjacentPhoenix]

OK let me get this correct in the way you are attempting to do this.

InputChanged should be reserved for input types that have data that can change.
Such as;

• Mouse
• Touch
• Gamepad Delta

There is nothing that changes with the keyboard.
Use;

• InputBegan
• InputEnded

However if you want to use the “InputChanged” event to detect if a key is up or down use (This may not or may work, not sure).

    local UIS = game:GetService("UserInputService")
    
    UIS.InputChanged:Connect(function()
        if UIS:IsKeyDown(KeyCode) then
            -- TRUE
        else
            -- FALSE
        end
    end)

Mention above is a “hacky” method, again I recommend using InputBegan and InputEnded

[rogeriodec_games]

Thanks again for all your attention, I know that I can use other events.

However my question was not answered yet.

In addition, as I mentioned before, the documentation does not say that InputChanged should not be used for keyboard events, on the contrary, it mentions keyboard events:

So, after all, either the documentation must be improved, or InputChanged must be corrected.

[AdjacentPhoenix]

the documentation does not say that InputChanged should not be used for keyboard events, on the contrary, it mentions keyboard events:

Agreed, it doesn’t say you shouldn’t. I think that description should be changed as it is misleading, however that is a different section.

Just reiterating, I’d really advise not using it. As it obviously doesn’t fire when it is a character controlled key. The other events do not have this issue.

[rogeriodec_games]

OK, let’s go:
I have a camera script that is triggered in a “construction mode” of the game, that is, when this mode is activated, the user can navigate the camera through the terrain using both mouse and keyboard (wsad and others). Camera movements are computed within BindToRenderStep.
This way I need the InputChanged to detect the movements of the mouse.
The problem there (which is the cause of this topic) is that the InputChanged is being activated when it shouldn’t (just when the user presses a key). This means that I must work around this problem using code, which would not be necessary if InputChanged was simply not triggered by the keyboard.
In addition to this, I realized that InputChanged is only triggered when there is a rendering event, which makes this problem even more illogical.
Can you understand now?

[colbert2677 (ThisMangaOnHiatus)]

@rogeriodec_games

This means that I must work around this problem using code, which would not be necessary if InputChanged was simply not triggered by the keyboard.

Just use an if statement and check only for the UserInputTypes you want then. Yes you would need code to work around problems but I’m confused as to why you would not want to write code here to solve your problem. You have to do it.

UserInputService.InputChanged:Connect(function (inputObject, gameProcessedEvent)
    -- Option A: Guard clause
    if not (inputObject.UserInputType == Enum.UserInputType.MouseMovement) then return end
    doSomethingWhenMouseMoves()

    -- Option B: If statement
    if inputObject.UserInputType == Enum.UserInputType.MouseMovement then
        doSomethingWhenMouseMoves()
    end
end)

Wanting InputChanged not to fire for keyboards is a non-problem. InputObject already provides the properties you need to accomplish what you’re really looking for here, which is only to check for mouse movements. Changing the behaviour of InputChanged also isn’t necessary just to avoid a few lines of code to omit non-mouse movement inputs that also fire InputChanged.

[MFCmaster1234]

So… the solution was… there was no question all along? Or what was the whole point?

[rogeriodec_games]

No, the InputChange problem does not change and remains illogical, but as not everything can be perfect, I just settled for the answer. It is not worth it to spend more time arguing than to create some lines to get around this defect.

[colbert2677 (ThisMangaOnHiatus)]

The question still baffles me and I still don’t understand, after reading everything, what the point of this question is. The response I just got helped me make a comment. It’s not illogical for keyboards to fire off InputChanged or whatever problem is being had here, if there is one in the first place. It seemed more like an attempt to avoid writing a simple line of code by asking why a behaviour exists and wanting to change either it or the documentation.

[rogeriodec_games]

Sorry, I’m not trying to create controversy here.
I just don’t understand why InputChanged is triggered by the keyboard when a Render occurs and is not triggered when a Render does not occur.
Deeply understanding each behavior makes a developer more confident which paths to follow.

[MFCmaster1234]

I think the answer is probably hidden away in some dark back room under a stack of papers at the Roblox HQ, where it’s written in red ink, DO NOT LAUNCH, but the memo was never delivered and that’s just going to be a mystery left to the universe to fix in its own way.