Client Input System

[kurozael]

This is a breaking change for most gamemodes. If your gamemode just used the Sandbox.Player class, you may not need to do anything. But in most cases, you will need to update your gamemodes.

What's changed?

• InputBuilder no longer exists. Instead, the Input static class now contains everything you need to get raw input data such as analog look and move values and button states (down, pressed, released.)
• BuildInput( InputBuilder ) just becomes BuildInput()
• By default, stuff like selection index, active child, view angles are no longer available. Instead, you can implement these in your games using the new [ClientInput] attribute. All previous inputs have been re-implemented as an example into the Sandbox.Player class in the base addon

Advantages

• We got to strip out a lot of stuff that probably isn't needed for most games
• You can now add your own inputs to be sent to the server, this paves the way for a bunch of cool stuff like couch-coop games
• We can use this to implement multi-controller support

Wiki Update

Please see the wiki page on Input System to see what has changed fully and how to use the new system.

[DoctorGurke]

So while being able to attach whatever we want to usercmds is nice, completely ripping out all the default Input.* stuff with a few hours notice hurts. Some heads up on the fact that we're going to need to construct our own Input.Rotation, Input.Forward, Input.Right, ViewAngles, InputDirection etc etc would've been extremely nice.

[DoctorGurke]

Personally don't see why things like Input.Rotation and Input.Forward etc had to be cut, considering those are very basic input bindings directly correlated to existing default InputButtons, ie InputButton.Forward. Having to reconstruct these to even get the most basic movement going again feels dumb

[DoctorGurke]

As for Input.Rotation in most cases you can just use EyeRotation if you're setting it properly.

EyeRotation previously was set with Input.Rotation though?

[DoctorGurke]

You can see how ViewAngles and InputDirection are implemented on the Sandbox.Player class in the base addon

Also just for the record, relying on supposedly "Obsolete" classes to show this feels really yank, I thought this was supposed to be sorted by proper templates ages ago?

[kurozael]

Personally don't see why things like Input.Rotation and Input.Forward etc had to be cut, considering those are very basic input bindings directly correlated to existing default InputButtons, ie InputButton.Forward. Having to reconstruct these to even get the most basic movement going again feels dumb

The Input class contains all of the raw input data you need. Input.AnalogMove has what you want. Input.Forward is just Input.AnalogMove.x etc.

As for Input.Rotation you can control this in whatever way your game needs it now. You have full control. Not every game will need this, and if they do, some games will need it in a different way to others. It isn't difficult to implement your own view angles with this system.

[DoctorGurke]

I don't totally see what knowing about this last week would have gained.. it's not like you were going to be able to do much beyond merely knowing about it. This is pain week, not tickle week.

this change has been staging for how many months?

[Gmod4phun]

Input.SetViewAngles was added a few days ago, which was used for setting the view angles of a player (before that, changing the Controller/DevController temporarily was used and worked for a while but that has not been working for a long time now). This got nuked now and I can't seem to find something that would replace it.

[Gmod4phun]

Ended up using a ClientRPC and setting the ViewAngles that way

[garrynewman]

That'd be the correct way - that's really just what SetViewAngles was doing anyway

[felinusfish]

I appreciate this change, having to interact with the camera was a nightmare when attempting to force the view angle. Huge reduction in headaches overall. THANKS CONNA!!

[Remscar]

Is doing input processing in the [Event.BuildInput] still the best practice?

Like how you do in Forsaken? https://github.com/Facepunch/sbox-forsaken/blob/add703b89b327991bb6ce89538752bd0a7dcf5c4/code/ui/chatbox/Chatbox.razor#L83

[handsomematt]

For UI you can just do that check in Tick like we do in the base chatbox:

public override void Tick()
{
	base.Tick();

	if ( Sandbox.Input.Pressed( InputButton.Chat ) )
	{
		Open();
	}
}

[Fortune117]

Has there been any change in the decision of allowing games to have unique keybinds in some way?
I'm very much running out with the default ones so it'd be nice to know where we stand on the issue.

[LeQuackers]

I like this change a lot (especially for predicted UI stuff), but without unique keybinds it's very limited in terms of doing things you weren't previously able to do.

[Remscar]

For those who encounter it; The [Event.BuildInput] event was changed to [Event.Client.BuildInput] after the Camera Refactor update (https://github.com/orgs/sboxgame/discussions/2652)