Like most people I find myself a recent refugee from the Unity fiasco. I've been trying to prototype a project in Godot and I've been running into an issue I would think would be pretty easy to find a solution to as it seems to be a pretty fundamental building block of any project in Godot. Perhaps I'm misunderstanding how to accomplish this in Godot, but essentially I'm instantiating a number of tiles to be used for a grid system in my game. I want these tiles to be able to emit their index and transform values and then have other scripts pick this information up as needed. From what I've read signals are the way to do this, however whenever I try to send a signal with or without parameters nothing seems to happen. I seem to be able to connect to the signal just fine but the method doesn't seem to be called.
Here's an example of me defining the signal and then emitting it:
signal index_transform()
index_transform.emit()
And here's how I am connecting and attempting to call the method in a secondary script:
Are you emitting in a function that gets called. If you are not sure, put a breakpoint in that line and see if you stop there. Also check to see if you connect first before emitting. One more thing, you don't need to make a callable, you can just use the function as it is a first class member of the class now, eg:
I'm emitting in the function that instantiates the tiles so it's definitely getting called. How do I verify that the connection is going through?
Also thanks for letting me know how to format it I was getting conflicting information regarding the syntax from various different tutorials and resources.
I believe there is a property on the signal to see the connections. From what you just said, it is possible that you are emitting before the connection is made. You can verify this using a couple print statements. If this is correct, the solution would be to either move the emission later or move the connection earlier (_init happens before _ready). Depending on what these functions are doing, feel free to pick whatever solution works best for you.
Signals are the same as events. It's just a different name. So, use signals to let other nodes/code know when something has happened (or is about to). It would only make sense to use a signal here if the values were changing and you wanted to let other nodes know about it. Like index_transform_changed(new_value).
I'm not sure what the tiles are for, but they're probably part of a collection or board of some kind. I would make this board it's own scene and have the board manage things. It could also make available transforms and indexes to other nodes, but that seems like something that would be best encapsulated within the board node itself. Then have the board get references to the children is controls via get_node, or using the $ syntax, etc.
Thank you! Okay so the tiles are part of a map, and I have a parent node called map with two separate children: hexgrid (where I'm instantiating the scenes) and spawn_objects( where I'm trying to gain access to the index and transform from hexgrid) my intent is to have hexgrid generate the grid and tiles and have spawn_objects instantiate an object within the tile at a certain position within it. Is this perhaps something I should combine into the same script? I typically like to have things modular and keep each component so a single specific task.
So, it seems spawn_objects needs a reference to hexgrid? Then you can export a property in the spawn_objects script that takes a reference to hexgrid. And then from the map scene, you set that reference as it has both as children. In Godot 4 you can use "@export var hexgrid: HexGrid" (this assumes you give the hexgrid node script a class_name of HexGrid.) In Godot 3 I think there's a bit more to it as the export is "export var hexgrid:NodePath" (note no @ symbol in Godot 3) and then later you have to use the NodePath to get the node like this "onready var _hexgrid:HexGrid = get_node(hexgrid)" (note the onready here means the get_node call will happen just before the call to func _ready()) You could do the get_node call in func _ready(), but I like the onready better because it makes any code in the ready function that much simpler.
That's just how I would do it given what I think I know. Now that you have these ideas, you can play with them and decide what you like best. Hope it helps!
Ok, tell me if I got it right. Your node structure is currently like this:
> Map
>> hexgrid
>> spawn_objects
And you want things to happen in this order:
Hexgrid instantiates the grid and tiles
spawn_objects will run for certain tiles
If I got it right, then this is a situation where signals are not needed. What I would do:
On the Hexgrid scene, add spawn_objects as a child node
> Hexgrid
>> spawn_objects
Within the Hexgrid script, when the desired tile needs to spawn something, call the function from the node. Either $spawn_objects.spawn_this_thing() or declaring the node as an @onready var spawner = $spawn_objects (...) spawner.spawn_this_thing()
Since you'll be calling the spawn code from within the hexgrid, you'll have full access to both nodes' variables, parameters and functions. If you needed to get a "spawn_here" variable from the parent while within the child, you could use get_parent().spawn_here
Signals are best used when you use the prebuilt ones for each node (on the editor, it's a tab on the top right side, besides the node's parameters). For most cases, a signal is emitted when a certain event happens, like _on_animation_changed(): for an AnimationPlayer node.
I never checked the prebuilt signals for a TileMap (which I'm assuming you're using), but my suggestion is for you to check when you need the function to happen. If you want it to fire once another entity enters it (say, a player controlled character came in), it's likely you'll want to use an Area2D + CollisionShape2D nodes, the signal firing from the Area2D with _on_body_entered(body) - In this case, the body parameter is a pointer to the entity. You can call any functions it has and you can directly alter any of its variables, so you could hit a player from there.
The trick is really in the "when" you need to access the data. So, when will you actually need it those index numbers?
Signals are best used when you use the prebuilt ones for each node
Thas not true at all, I use custom signals all the time.
However, custom signal are not particularly useful within a class. They are useful for passing information up the node hierarchy. As Kids Can Code says: get_node down the tree, signal up the tree.
Is this the intended purpose for signals? Moving info up and down the tree? If so how are we supposed to send information from one script to another if one is not directly a child of the other? Do we send it to a shared parent node then send the info back down to the secondary script?