You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem or limitation you are having in your project:
It's not really a limitation, just an annoyance. In any game involving movement, including many of the demo projects, it's really common to see code like this (from TPS demo):
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
The above example is a bit cluttered and repetitive. So, what can we do to fix it? I propose we add a new method called get_axis (or possibly get_axis_strength) which allow us to do this instead:
# Order of get_axis is positive action, negative action.varmotion_target=Vector2(Input.get_axis("move_right", "move_left"),
Input.get_axis("move_back", "move_forward"))
We could also expand this to allow working with two axes at once, perhaps get_vector:
# Order of get_vector is positive x, negative x, positive y, negative y.varmotion_target=Input.get_vector("move_right", "move_left", "move_back", "move_forward")
Bonus idea: This could also be expanded by allowing arrays to be accepted:
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Importantly, this proposal does not involve Input having any kind of internal concept of what an axis is. You can provide any two actions, and it will simply give the result of one's strength minus the other's strength. You could even create nonsense like Input.get_axis("ui_accept", "ui_up")) if you wanted to, since it just accepts any set of actions.
Because of this simplicity, the implementation would probably only involve a few self-contained functions, each of which should be fairly small.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
Yes, it can be worked around with a few lines of script. But also, it will be used often, as any game that involves player movement will likely have code that looks like this.
Is there a reason why this should be core and not an add-on in the asset library?:
It's too simple of a proposal to have an add-on in the asset library just for it.
The text was updated successfully, but these errors were encountered:
The problem with such approach is handling the deadzones. Usually, when you get an axis, you expect the deadzone to be the same for each side. And when you get a vector, you want the deadzone to be a circle, not a square.
This means computing a deadzone value out of the underlying actions' deadzone (like an average), or layering another deadzone on the strength produced but the underlying events, or even or eventually distort the deadzone area per side. Even if the last one is probably the most easy to understand, I fear the deadzone thing might lead to confusing behaviors.
We have to make sure this is not a problem.
Other than that, since it does not modify the underlying system, and is only about adding two helper functions used often, I don't mind the addition.
@groud I agree that there are further ways to improve get_vector, I'm curious how complicated that would be to implement (is there a way inside Input to get the raw value and bypass the deadzone so that we can apply a deadzone ourselves?), but the deadzone really shouldn't matter for get_axis since on joysticks you can only push one direction at a time and for keyboards it's always 0 or 1.
Describe the project you are working on:
Godot demo projects
Describe the problem or limitation you are having in your project:
It's not really a limitation, just an annoyance. In any game involving movement, including many of the demo projects, it's really common to see code like this (from TPS demo):
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
The above example is a bit cluttered and repetitive. So, what can we do to fix it? I propose we add a new method called
get_axis
(or possiblyget_axis_strength
) which allow us to do this instead:We could also expand this to allow working with two axes at once, perhaps
get_vector
:Bonus idea: This could also be expanded by allowing arrays to be accepted:
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Importantly, this proposal does not involve
Input
having any kind of internal concept of what an axis is. You can provide any two actions, and it will simply give the result of one's strength minus the other's strength. You could even create nonsense likeInput.get_axis("ui_accept", "ui_up"))
if you wanted to, since it just accepts any set of actions.Because of this simplicity, the implementation would probably only involve a few self-contained functions, each of which should be fairly small.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
Yes, it can be worked around with a few lines of script. But also, it will be used often, as any game that involves player movement will likely have code that looks like this.
Is there a reason why this should be core and not an add-on in the asset library?:
It's too simple of a proposal to have an add-on in the asset library just for it.
The text was updated successfully, but these errors were encountered: