How would you structure a mouse node

cloa513

It would simplify the code if I could store data derived from particular buttons that the mouse clicks on and then other buttons that the user clicks on get that data. I am guessing a script attached to the main scene (Node2D) use mouse click signals- how to specify the mouse click signals data?

I also desire a custom mouse cursor and I know you can load an image and set for the mouse cursor but it would be great if it could modulated to any color. someone in qa said the var=preload() is just a texture so I guess you can use

draw ( RID canvasitem, Vector2 position, Color modulate=Color( 1, 1, 1, 1 ), bool transpose=false, Texture normalmap=null ) How exactly do use draw()- do you need all those arguments.

Erich_L

I think an easier way to get where you want to go is this way: have a menu manager node and give it a script. Have your buttons as a child to that node or at least have them in the same scene. Then connect each button click to a function in the menu manager with signals. With each button going to a different function in that script you can decide more specifically what those button presses mean to you. As for the color part- I haven't tried to do that yet myself.

Edit: I did try to make a video on signals a few days ago if you're not super comfortable with them.

You could give each button a script called ... uhh.. MyButton and give it export vars that you can set in the editor. Then when you make your own signals you could send those parameters through to your menu manager. But I don't think that's the easiest way to do it.

cloa513

Thank you for your reply. I am not saying no signals rather focused signals because it will have mouse control to mediate the data flow. Mouse control is a signal. Conceptually we aren't thinking differently except you are not thinking buttons modifying buttons.

Just look at your example game and just suppose the game was really change properties of the bananas.

Maybe a little a confusion most buttons are in my game are the main game (a few are actual controls) for them you could just as easily substitute the parts of a simulation like Lemmings especially if the Lemming weren't added but always present.

cybereality

Signals can pass data around. So like @Erich_L says, you can have a manager script that handles the button interaction (this would be the script with all the code, which connects to the child buttons, and has the logic for when buttons are pressed). When the button gets clicked, it will send the data about the button (such as the name or other data you can define on export variables). This is one way to do it anyhow. Otherwise you could set custom functions for each button (still in the manager class) that will be easier but the same idea.

For the mouse cursor, if you set a custom image in the project settings I don't think you can alter it. But you can also just use a Sprite and have a script that sets it's position equal to the mouse position each frame. This is more flexible, and you can change the color with modulate or scale it or do whatever you want. But there is a 1 frame lag due to the way the mouse logic works in Godot.

Erich_L

Hmmm, not sure I completely understand what you're going after. You can add binds in a signal with extra variables you want to pass. I didn't actually do any of that in the video I made tho. Timestamp 8:24 you can see where binds can be added.

cloa513

A user clicks on a main control button then clicks on one or more game buttons of about 800 of them which sets data for them. Don't signals have to be closed? Does that mean I have send the signal to an every single game button even though only one of them needs it.

The main control buttons could have their functionality changed and send an update message- not a problem as previously clicked buttons have their listener preset.

The user can also click on subcontrol buttons but they can autoclose.

Main control buttons are black, grey, white, red, yellow, orange, green, blue, indigo, violet. Red is nominal reserved for error but a user could set it. Grey is for resetting the games buttons. White erases game buttons. Black sets up the game buttons. The other six have potentially identical functionality as set by the user by their individual sub-control buttons which are two. I am thinking I could have a color picker to allow the user to change the colors of the main control buttons but not fundamental functionality. Basically 5 types of control functionality.

Erich_L

Don't signals have to be closed? Does that mean I have send the signal to an every single game button even >though only one of them needs it.

I'm not sure what you mean by closed. Do you mean one to one? A signal can be connected to more than one node.

DaveTheCoder

Does that mean I have send the signal to an every single game button even though only one of them needs it.

When a signal is emitted, it's broadcast. It's not sent to a specific listener. Any node can listen for a signal by connecting the signal's name to a handler method or by using the yield() method.

cybereality

Signals should be fairly optimized, I don't think they are an expensive call. You can connect multiple objects to listen to the same signal, but they can choose if they want to do anything with it. For example, by sending additional data like the name of the calling object, or some flag variable to let the receiver know if they should be interested.

cloa513

@Erich_L said:

Don't signals have to be closed? Does that mean I have send the signal to an every single game button even >though only one of them needs it.

I'm not sure what you mean by closed. Do you mean one to one? A signal can be connected to more than one node.

disconnected. Stop emitting.

cybereality

You can use disconnect if you never want to process that signal again on any object. https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-disconnect

Or you can simply not emit the signal again.

Erich_L

ah. I did show connecting and disconnecting in code in that video. It might be helpful after all :3

cloa513

@cybereality said: Signals can pass data around. So like @Erich_L says, you can have a manager script that handles the button interaction (this would be the script with all the code, which connects to the child buttons, and has the logic for when buttons are pressed). When the button gets clicked, it will send the data about the button (such as the name or other data you can define on export variables). This is one way to do it anyhow. Otherwise you could set custom functions for each button (still in the manager class) that will be easier but the same idea.

For the mouse cursor, if you set a custom image in the project settings I don't think you can alter it. But you can also just use a Sprite and have a script that sets it's position equal to the mouse position each frame. This is more flexible, and you can change the color with modulate or scale it or do whatever you want. But there is a 1 frame lag due to the way the mouse logic works in Godot.

How about visual delay is in one frame lag on the mouse cursor- the sprite cursor can be tiny circle? If I add a sprite to follow the mouse then I could destroy sprite following the mouse and add a new one and trigger a script in the new one or simply trigger it on a mouse click or something like that.

I get "connect() returns a value but it is never it " error from the connect to the toggle for which assert(get_tree().connect("toggled", self, "_on_toggled") == 0) is supposedly a good solution but it worked a bit then failed again. > @Erich_L said:

I think an easier way to get where you want to go is this way: have a menu manager node and give it a script. Have your buttons as a child to that node or at least have them in the same scene. Then connect each button click to a function in the menu manager with signals. With each button going to a different function in that script you can decide more specifically what those button presses mean to you. As for the color part- I haven't tried to do that yet myself.

Edit: I did try to make a video on signals a few days ago if you're not super comfortable with them.

You could give each button a script called ... uhh.. MyButton and give it export vars that you can set in the editor. Then when you make your own signals you could send those parameters through to your menu manager. But I don't think that's the easiest way to do it.

Your video is nice but I don't see what it adds over GDScript's one, It doesn't descriptively explain how signals internally function and your reasons for doing particular actions is a big miss by lots of tutorials.

DaveTheCoder

assert(get_tree().connect("toggled", self, "_on_toggled") == 0) is supposedly a good solution

Not using the return value of connect() results in a warning message, which you can disregard. It's not an error.

If you want to suppress the warning message, which I think is good practice, the above code is not a good solution, because assert() is called in a Debug build but not in a Release build. So in a Release build, that connect() won't get called. (I was making the same mistake until I saw a post about it.)

Another way of suppressing that warning message is to precede the statement with this line: #warning-ignore:RETURN_VALUE_DISCARDED

(In 3.4+, you can also put that directive on the same line as the statement to which it refers.)