`CardUI` Signal don't emit when put into custom dropzone

[Arcadia822]

I'm trying to make some custom Dropzone. Problem is any card dropped into custom dropzones lose ability to trigger _on_mouse_enter or _on_gui_input.

• CardUI in pile works properly and lose it's hook / signal after call card_ui_dropped.
• CardUI created manually with _create_card_ui and put into custom dropzone cannot trigger too. (Put into internal piles is OK)

What I figured out:

• It's not about z-index
• It's not about _card_can_be_interacted_with function. The hook doesn't triggered at all.
• Neither connect signals from CardUI nor CardPileUI work.

PS: I'm new to Godot and feel like this is a noob question. Please help. Thanks.

[mathrick]

Your question is pretty hard to follow, could you share the code for your custom dropzone? My guess is you need to add a super() call to your code, something like:

class_name MyDropzone extends CardDropzone

func card_ui_dropped(card_ui: CardUI):
    super(card_ui)
    # your code goes here
    do_something()
    do_something_else()

[mathrick]

Also note that you might not want to call super() if you don't want to do exactly what it does, and in this case you might need to reimplement bits and pieces of its functionality. I'm working on a series of PRs to modularise a lot of the add-on, so it will be easier to hook in your own code.

In case you're not familiar with super(), have a look at the Godot docs.

[Arcadia822]

My custom CardDropzone

extends CardDropzone

@onready var game = get_parent()

func _ready():
    pass # Replace with function body.

func card_ui_dropped(card_ui: CardUI):
    super(card_ui)
    # card_pile_ui.set_card_dropzone(card_ui, self)
    game.play_card(card_ui.card_data)

Thanks for the reply. I checked card_ui_dropped and found I didn't call it but insteadly manually called set_card_dropzone.

Though replace it with super(card_ui) didn't change the problem.

Also I checked the code inside set_card_dropzone. It looks nothing to do with the signal card_hovered, card_clicked since they are connected inside card_pile_ui._create_card_ui

I take some screenshots and my codes.

Custom Card Class

```gdscript class_name Card extends CardUI @export var gold: int @export var power: int @export var cost: int @export var description: String @export var mode: String = '' @export var highlighted: bool = false @onready var name_label = $Frontface/Name @onready var desc_label = $Frontface/Description func set_store(): print_debug('set store') set_mode('store') func set_mode(_mode: String): mode = _mode func highlight(): if (highlighted): return position.y += size[1] * 0.1 scale = Vector2(1.1, 1.1) highlighted = true func unhighlight(): if (not highlighted): return scale = Vector2(1, 1) position.y -= size[1] * 0.1 highlighted = false func _ready(): super() card_data.connect("card_data_updated", _update_display) _update_display() func _card_can_be_interacted_with(): print_debug('test mode: ', mode) if mode == 'store': return true return super() func _update_display(): name_label.text = card_data.nice_name desc_label.text = card_data.description ```

[Arcadia822]

[mathrick]

@Arcadia822: ah, I see. Just to confirm, since you say "custom dropzone", does it work with stock CardDropzone, without any of your modifications? Cards in dropzones generally don't respond to input at the moment, and my first instinct was to look at can_be_interacted_with(), but you've already done and answered most of what I was going to ask, so good job there :)

[mathrick]

Actually, I looked at your tree again, and I'm 90% sure I know what the issue is. Try dragging your CardPileUI so that it's below any dropzones in the tree (and just above UI in your case). The order of nodes is lower-on-top, ie. amongst siblings, the one that comes later will be the one on top. It's predictable, but can trip you up if you don't know it.

[Arcadia822]

Actually, I looked at your tree again, and I'm 90% sure I know what the issue is. Try dragging your CardPileUI so that it's below any dropzones in the tree (and just above UI in your case). The order of nodes is lower-on-top, ie. amongst siblings, the one that comes later will be the one on top. It's predictable, but can trip you up if you don't know it.

Instant fix. I even don't notice node order matters :joy: . Maybe I should read the docs again. Thanks a lot again.

[Arcadia822]

I checked the Node / Signal section of godot docs and didn't find an explain. This looks quite different from web / application development. Intuitively I thought script order should only affect execution order of setup hooks like _ready() and frame loop process like _process(). I don't understand why node order affect signal hooks.

[mathrick]

It doesn't! Signals are received just fine regardless of where the node sits in the tree, it's just that for display and input purposes, the nodes are drawn from the top of the tree down, meaning the ones further down will be drawn in front of the ones up the tree. And the ones that are in front are also the ones that receive input from the engine (unless you change their z-index).

Here are the docs describing some of that, and the little pictorial description of how input processing is ordered:

[Arcadia822]

It doesn't! Signals are received just fine regardless of where the node sits in the tree, it's just that for display and input purposes, the nodes are drawn from the top of the tree down, meaning the ones further down will be drawn in front of the ones up the tree. And the ones that are in front are also the ones that receive input from the engine (unless you change their z-index).

Here are the docs describing some of that, and the little pictorial description of how input processing is ordered:

That's pretty clear, Thanks. Now i'm trying to add some features to this project. Hope I could make some pr soon. Do I need to close this issue or leave it open?

[mathrick]

I'd close it, since it's not an issue with the project, though a mention in the docs probably wouldn't hurt.

On Tue, 11 Jun 2024, 00:17 Arcadia, @.***> wrote:

It doesn't! Signals are received just fine regardless of where the node sits in the tree, it's just that for display and input purposes, the nodes are drawn from the top of the tree down, meaning the ones further down will be drawn in front of the ones up the tree. And the ones that are in front are also the ones that receive input from the engine (unless you change their z-index).

Here are the docs https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html describing some of that, and the little pictorial description of how input processing is ordered:

[image: input_event_scene_flow] https://private-user-images.githubusercontent.com/179487/337732718-630def82-f6d6-460b-aebe-bd4591ddac1b.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTgwOTAyOTQsIm5iZiI6MTcxODA4OTk5NCwicGF0aCI6Ii8xNzk0ODcvMzM3NzMyNzE4LTYzMGRlZjgyLWY2ZDYtNDYwYi1hZWJlLWJkNDU5MWRkYWMxYi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNjExJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDYxMVQwNzEzMTRaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1kZGMyYzM1Y2M3M2U5NDNmYjRmOWMxOTNjNjc0ZDIxNGJiYjM0Njk1ZGVmNGIyZGRhYTg0NGQ2NjhlMjk2Yjg1JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.PLi0vq9JtbDnjPQF82VgcMntZIvBGrO2yolSq45bV6E

That's pretty clear, Thanks. Now i'm trying to add some features to this project. Hope I could make some pr soon. Do I need to close this issue or leave it open?

— Reply to this email directly, view it on GitHub https://github.com/insideout-andrew/simple-card-pile-ui/issues/6#issuecomment-2159970941, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABL2H5ETEUAKM57WQVEVADZG2QB7AVCNFSM6AAAAABIWR7MNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJZHE3TAOJUGE . You are receiving this because you commented.Message ID: @.***>