Modifying User Input

Man I ripped out so much code today. For like 3 hours ripping out code.

But I just got it so you can build and modify the user input from the gamemode.

/// <summary>
/// Clientside only. Called every frame to process the input.
/// The results of this input are encoded into a user command and
/// passed to the PlayerController both clientside and serverside.
/// This routine is mainly responsible for taking input from mouse/controller
/// and building look angles and move direction.
/// </summary>
public override void OnInput( ClientInput input )
	if ( input.Paused )

	// If we're using the mouse then increase pitch sensitivity
	if ( input.UsingMouse )
		input.AnalogLook.pitch *= 1.5f;

	// add the view move, clamp pitch
	input.ViewAngles += input.AnalogLook;
	input.ViewAngles.pitch = input.ViewAngles.pitch.Clamp( -89, 89 );

	// Just copy input as is
	input.InputDirection = input.AnalogMove;

This should let us change the sensitivity or clamp the view etc, allowing for different types of gamemodes etc.

I’m gonna feed this input to the camera, the player and the player controller. That’ll give them all a chance to modify it before returning it back to the game.


To be clear, the ClientInput functionality can define new keys for the Gamemode?

Can we make it so pressing F on the keyboard or X on a gamepad triggers the gamemode-specific functionality of ClientInput.Flashlight?

1 Like

Can the server easily modify a player’s view angles? Assuming client has authority there

1 Like

In what order are inputs going to be passed around? From the looks of it looks like it’ll be Camera -> Controller -> Animator with each being able to modify the input before it’s sent to the next but I figured I’d ask.

1 Like

No, it can’t work like that. We have to define a finite amount of buttons. We can bind them to different keys and you can use them for whatever you want, but I don’t like the idea of hardcoding to specific keys.


Yeah, it shouldn’t be a problem. I don’t have a specific example of it but it should be easy enough to figure out.


Camera and then controller. I wasn’t gonna pass to the animator but I guess there would be instances where it would be useful.


I thought the animator already used input, at least it does on the wiki page for it. I’m guessing you were changing it to just use Player.Rot instead?

That aside I’d imagine it’s more of a case of “Eh, can’t hurt” than anything else whether the animator uses inputs or just refers to the player for everything since it’d be last in line anyways.

1 Like

Talking about hard coding to specific keys: Have you thought about what you’re planning to do about player controls? I can see some gamemodes using a differnet control configuration than just the standard wasd / mouse controls.

Some basic shared controls the user has access to configurate would be great, but that still brings up the question of custom keybinds for other gamemodes.

1 Like

It’s a different type of input. I wonder if I should rename it. The input the animator/controller uses is the user command. Maybe it would make more sense to call the ClientInput something like InputBuilder.


It’s hard to cater for this stuff before it exists. It makes sense to have most of the common buttons covered by common inputs. wsad, q, e, ctrl, shift, tab alt, r, f, g, 1, 2, 3, 4, 5, 6, 7, 8, 9, z, x, c, v.

I’d like to try to limit us button wise to what would fit on a regular game controller.


I think the name is fine as-is, I was just mixing up some things on my end.

Do all three (Camera, controller and animator) use the user command then or is ClientInput used by something else before it’s sent off?

1 Like

I’m getting the vibe this should put you in a good place for native VR controller support then, especially with the var names. Can’t wait

1 Like

It should be possible for game makers to set their own binds for custom functionality. What if someone wants to make a complex PC game that doesn’t catter to game controllers? It should be possible.

1 Like

I think limiting the amount of and naming the inputs will put a serious damper on the types of games people will create in S&box.

Supporting controllers and/or VR inputs should be a decision that the modder makes, because certain game types (RTS, city builder, simulation, etc) just don’t work with limited controls. Games that work well with controller inputs are almost exclusively driving based games.

Inputs and bindings should either be open enough in the base game that modders can easily add extra controls or have access to key states, or just entirely omit control schemes and bindings from the base game and let developers template it out themselves, and only provide the interface to bind keys (if even that) and handle it on a gamemode-by-gamemode basis

I believe that locking it down will create the same issue that exists in gmod where it’s just too infeasible to create any sort of gamemode that isn’t an FPS


I disagree


Garry explaining why less is more for S&box.


Could you elaborate more on the stance? It’s been an issue in Garry’s Mod with various workarounds but still an issue nonetheless. I was in Crayta’s content creation phase/alpha/whatever you want to call it and had the exact same gripe among other people because they limit developers to only the amount of inputs that Stadia controllers provide in that game as well. Since it is a Stadia exclusive (which wasn’t known at the time) it’s a forgivable offense but presumably S&box isn’t in the same boat there

1 Like

We already have half the keyboard bound, I don’t know what your gamemode is doing where you can’t repurpose those keys. The only possible thing I can think of is if you’re making a flight sim?


Apart from the number row you listed WSAD and the surrounding area which is an okay variety, pretty much just the same as what Garry’s Mod gives you though . Just off the top of my head [M]ap, [J]ournal, [B]ag, [I]nventory, [O]rg/Guild/Social, [K]Spellbook and Abilities, [T]arget next unit

There are a ton of games that make great examples of why as many binds available as possible comes in handy. The left hand area covers movement and interaction binds for FPS games, not so much anything else though.