I need some help with analog controller input

[keen pasture]

Hidy-ho! I'm making a 3D first person horror game using a node-based state machine (very much based off of The Shaggy Dev's model) for my character controller, mostly as a learning exercise than anything else. I've found the process super fun but now I'm attempting to implement controller support (doing it early so I don't run into big issues later) and I just can't figure out how to get smooth analog motion. Right now I'm just using the basic built-in movement script (shown in the image) but only cause I've tried some other solutions that didn't work so I just went back to basics while I tested other systems. I have no problem ripping it out entirely and coming up with something from scratch.

Basically, I just need help writing up a dead-simple movement script that allows seamless switching between keyboard and joystick inputs. I am not worried about acceleration or friction at this time as I am not going to have different surface types in this game. I think I'd like a circular deadzone as well.

I also would like some help getting the camera to work with the right analog stick as well, I haven't looked into that part at all yet but I figure I'd rather just get help on that here too instead of fiddling anymore with this as I don't want to get frustrated for my lack of knowledge.

Thanks!

OH for clarification the directional input works fine with this script and smoothly transitions between all directions on the analog stick. My problem is getting the speed to be smooth, as in ramping speed up or down dependant on the strength of the analog input. I've run some tests in the console and with this script the vector only ever outputs the extremes of it's given value (pressing forward is always -1 and backward is always 1, no matter how far I'm pushing the stick)

I did at a certain point split "input_dir" into two 'get_axis' variables instead of one 'get_vector' and then multiplied the velocity.x and velocity.z variables by their respective get_axis variables which did allow for accurate and smooth speed values but then for some reason treated both directions as the same (both forward and backward sent me backward), removing the possibility of negative numbers. I'm not the best at math but I have no idea why that would be.

[wet solar]

Try removing normalized(). Since that sets the vector to a solid length of 1. Making it impossible to go any slower or faster.

[keen pasture]

oh wow it's just as simple as that huh! thanks! so what's the use case of having normalized() there, ie. in what occasions would you want to have the vector have a solid length?

[wet solar]

Depends a lot.
I generally use it as a way to override a vector and set it to a specific length. Useful for increasing/lowering velocities.

If i have a velocity with a length of 80 and i want to make it be 30. Instead of doing something like velocity *= 0.4 i just do velocity = velocity.normalized() * 30

direction_to() also normalizes vectors automatically, since you generally do it for the direction and don't want its length to be influenced by anything else.

[keen pasture]

oh that's really interesting! that does seem like a much cleaner solution

[full dragon]

I will also like to point out, Input.get_vector() already normalizes the input vector if the length > 1

[keen pasture]

with that being the case why doesn't it automatically negate analog input in this instance?

[full dragon]

The length isn’t greater than 1

So it won’t normalize it

[keen pasture]

oh greater, I read that as lesser haha. I didn't exactly pass my math classes in school

but that makes sense

I have to imagine that if the input vector ever went above 1 or below -1 that it would just increase the speed beyond the expected cap, correct?

[full dragon]

Well it can’t, cause the length is maxed at 1 with Input.get_vector()

[keen pasture]

I understand, I just meant in a case where it wasn't maxed

[full dragon]

Ah yeah

The length of the velocity vector will be DIRECTION.length() * MOVE_SPEED, so if the length of direction gets greater than 1 then the length of velocity will be greater than MOVE_SPEED

(This is ignoring any y velocity actually so the length can be larger than that if you’re jumping or falling)

[keen pasture]

that makes total sense, thanks!

ok, with that settled now I'm gonna try using this to set up camera movement on the right stick myself. I think I know how to do it but if I can't I'll post again here. if I get it I'll mark this as solved

[keen pasture]

ok I've implimented it like this which wooorkss but the camera motion on the stick is very weird. it only moves when there is actively an input, meaning if I hold the stick in a single direction consistently it won't move at all. I think I understand why, because InputEvents only update when there is an input, not every frame, but wouldn't it be a waste of resources to have the game check for right stick inputs every frame? how should I go about fixing that?

[wet solar]

Checking for inputs is very cheap. Even every frame.
And even more when you will only be controlling one camera at a given time.

Do not worry with such extreme optimizations.

[keen pasture]

fair enough. I changed it to this which seems to work totally fine