Hello, so, usually when i ask a question on the GDScript, its usually something very, very dumb that i should probably think about myself, anyways, currently trying to make a very scaleable Command-based UI system, specifically for future usage, problem is, with my idiotic coding practices, I have no idea how i am supposed to even select the labels and their text without literally making the increments be used as a kind of ID.
Here is my code that due to other business, took me about 5 hours to make:
extends Control
@onready var options = $"Control/OPTION/"
@onready var cursor = $"Control/cursor"
@onready var click = $Click
var cursor_pos_x = 0
var cursor_pos_y = 0
func _ready() -> void:
#wrote for testing purposes only.
print(options.get_child_count())
print(options.columns)
func _process(_delta: float) -> void:
cursor.position.x = cursor_pos_x
cursor.position.y = cursor_pos_y
var increment_x = 1
var increment_y = 1
func _input(event: InputEvent) -> void:
var anim_cursor = $Control/cursor/AnimatedSprite2D
if Input.is_action_pressed("A"):
click.play()
anim_cursor.stop()
command()
if Input.is_action_pressed("RIGHT"):
if increment_x != options.columns:
cursor_pos_x += 8 * 6
increment_x += 1
anim_cursor.stop()
if Input.is_action_pressed("LEFT"):
if increment_x != 1:
cursor_pos_x -= 8 * 6
increment_x -= 1
anim_cursor.stop()
if Input.is_action_pressed("UP"):
if increment_y != 1:
cursor_pos_y -= 8 * 2
increment_y -= 1
anim_cursor.stop()
if Input.is_action_pressed("DOWN"):
if increment_y != options.columns:
cursor_pos_y += 8 * 2
increment_y += 1
anim_cursor.stop()
print(str(increment_x) + "and" + str(increment_y) + "are the x and y incrementational values.")
await get_tree().create_timer(0.3).timeout
anim_cursor.play()
func command():
pass #Not implemented yet.
I just realized an idea for what i need to do, i will explain when i implement but feel free to correct my methods if needed–
You might be able to use Godot’s built in “focus” which can be annoying to style but is very functional.
If you are using _input you should use the passed in event instead of Input
if event.is_action_pressed("RIGHT")
Otherwise your events may fire more than once per press, _input is triggered with any event so holding down “RIGHT” and moving the mouse around, a control stick, or even resizing the window will trigger this if statement multiple times.
1 Like
Yeah, but its moreso the issue is taking the cursor index’s position and selecting the correct label for match in order to execute action, my idea diddnt work, but i am not sure if i need to do some weird equation in order to actually select a label from the container, or if i should do it an entirely different way . . . i am making the menu so that its SNES / NES / Sega Genesis like, mouse controls arent supported in my game so far. . .
thank you for response
dang not many people seem to be active right now. Ig ill continue to struggle on my own accord. . . so close though . . .
I don’t think I understood the question correctly. Cause you explained it in a way a button2d would fix but I’m assuming that’s not the issue
OK, heres a screenshot if it helps with what my structure is:
So, basically i have been attempting to make an equation so that based off of the increment_x/y variables, an output can be given for the correct label index. If i could figure that part out, this would be easy, this is more or less a mathematical problem
The proper way to handle this is by using actual Button nodes and Godot’s built in control focusing system, as @gertkeno already hinted.
The way you’re currently trying to do it is complicated, unreliable and scales poorly. It’d require re-adjusting every time a need arises to rearrange the layout or add more buttons.
1 Like
If i used buttons and the on focus system, even then i still need a way to select the correct button with the cursor (not mouse cursor, i mean a literal arrow that blinks)—the main issue is not in how the system is, but how i select an option, if i were making a simple button based command system, then Switch ports of the game would be annoying to use due to lack of a mouse, the problem may be just my style of doing things, but in the case scenario where i did use a button and onfocus—how would the cursor be relevant without still requiring the same equation that i am trying to find?
That’s precisely what focus is - it’s selection. You can change focus via mouse, keys or scripting.
1 Like
*OK, i know that, i am saying that this cursor i am using:
the arrow, i not using mouse control, i am using the literal arrow that is controlled with the dpad and select button; so you see, a button system literally is unapplicable here
It’s totally applicable. The arrow is just a visual representation of the currently focused control. By using focusing your system wouldn’t depend on the precise placement of controls, which’d make it way simpler to manage and adjust.
i dont think its understood, how the selection works is it selects the label node, if i were to do the cursor system and make it work, i would just check the text in it rather than the location of the label,
Thats why i am going about trying to just figure out the equation so that it will focus correctly.
It’s 10 minutes setup and 10 lines of code. Literally.
extends Control
func _ready() -> void:
for button: Button in find_children("*", "Button", false, false):
button.focus_entered.connect(_on_focus.bind(button))
get_child(0).grab_focus()
func _on_focus(button: Button) -> void:
%arrow.position = button.position + Vector2(-32.0, button.size.y / 2.0)
4 Likes
Wh-what??? Gah!! I was being very stupid—i will do your method, thank you very much!
(seriously why diddnt i know how to do this? )
(sorry for not getting it earlier also)
This is like me going from the stone age to the brass age, seriously thanks man
I really wonder why my programming methods are so archaic.
This is just a case of knowing the systems within Godot. The focus system is fantastic, and you were trying to re-invent it (or at least some parts of it). It’s rather hard to implement yourself and almost needs to be done at a core level which isn’t accessible in GDScript. Again knowing to leverage the focus system isn’t really your “programming methods”, nobody memorizes every single signal and method in the docs; your script wasn’t bad for what you were trying to do, you were just trying to do something that’s been done and a signal will get you 90% of the way there.
1 Like
Ahh, aye, thank you, aye, *i was just trying to re invent the wheel using cubes,
this is very memory efficient also, i gotta research more on the godot-specific systems
