Blocks vs. Nodes

[upost]

Dear team,
let me first say that I'm a developer and I'm really willing to help here, neither asking stupid questions nor being offensive, but your plans are a bit intransparent to me, so I'd like to understand some things first :-) I have written a book about Godot and I have a class of pupils with some Scratch knowledge and they'd like to code games with blocks ...

1. Clone vs. SimpleSpawner
   In Scratch, there's a "clone myself" command block and a "when I am created as a clone" event. Those are regularly used to spawn multiple sprites. In block-coding, we're supposed to use the SimpleSpawner node.
   My question is: shouldn't such a node be part of Godot itself, while block-coding only adds, well, block coding? ;-) The SimpleSpawner produces some overhead because it instances scenes which has propably a bit more performance impact than just duplicating a node.
   That said, we can clone a node by using the call method block with "duplicate". But the reference to the duplicated node is not available, so we cannot call another function and there's no (at least no easy) way for a block script attachted to the node in question to determine if it is a duplicate or not. (i.e. the original node could be an asteroid outside of the screen, and the duplicates should be thrown at the player when created)

2. call_group
   I see that the "call method x for group y" block just produces get_tree().call_group(x,y) - without parameters. So the available uses cases are quite narrow. Could we have a "for each node in group" or "for each child node" with a variable holding the node? Then we can call a function on each of that nodes. But again, if those nodes are duplicates, can we even call a block script function this way? I didn't test that yet. (Of course, due to the Single Responsibility Principle the duplicated node would be responsible for itself, the calling blocks should not manipulate its transform or whatever else, and it can't, as all transform blocks affect the block's owning node and not the iterated ones)

Thanks!
Uwe

[manuq]

Dear team, let me first say that I'm a developer and I'm really willing to help here, neither asking stupid questions nor being offensive, but your plans are a bit intransparent to me, so I'd like to understand some things first :-) I have written a book about Godot and I have a class of pupils with some Scratch knowledge and they'd like to code games with blocks ...

Good to know about your background. Your help and feedback will be very appreciated!

1. Clone vs. SimpleSpawner
   In Scratch, there's a "clone myself" command block and a "when I am created as a clone" event. Those are regularly used to spawn multiple sprites. In block-coding, we're supposed to use the SimpleSpawner node.
   My question is: shouldn't such a node be part of Godot itself, while block-coding only adds, well, block coding? ;-) The SimpleSpawner produces some overhead because it instances scenes which has propably a bit more performance impact than just duplicating a node.
   That said, we can clone a node by using the call method block with "duplicate". But the reference to the duplicated node is not available, so we cannot call another function and there's no (at least no easy) way for a block script attachted to the node in question to determine if it is a duplicate or not. (i.e. the original node could be an asteroid outside of the screen, and the duplicates should be thrown at the player when created)

What you tried with using the "call method" block with "duplicate" as parameter is basically what you'll get from adding a "duplicate" block. As you figured, the problem is not having the reference to the new node. And by design the blocks in a canvas affect the parent node. The "remove" block is going to remove that node, not any other. This is to avoid confusion in learners, and seems related to the "Single Responsibility Principle" you mentioned.

By the way, instantiating a scene is quite common in Godot. Which performance impact do you anticipate?

That being said, feel free to give it a try, PR welcome!

2. call_group
   I see that the "call method x for group y" block just produces get_tree().call_group(x,y) - without parameters. So the available uses cases are quite narrow. Could we have a "for each node in group" or "for each child node" with a variable holding the node? Then we can call a function on each of that nodes. But again, if those nodes are duplicates, can we even call a block script function this way? I didn't test that yet. (Of course, due to the Single Responsibility Principle the duplicated node would be responsible for itself, the calling blocks should not manipulate its transform or whatever else, and it can't, as all transform blocks affect the block's owning node and not the iterated ones)

Yes this is very much needed for advanced usage. See: #126

[upost]

about 1.: being aware that we can easily instantiate scenes, as pointed out before, many blocks users might come from Scratch where they only have objects to clone which would be a simple, basic solution for beginners (and no need for a special node which is not a block and which, as a teacher, I need to explain first).

about 2.: thanks for referencing #126, so I will go and add my +1 there and I'll concentrate on the clone thingy.

[manuq]

about 1.: being aware that we can easily instantiate scenes, as pointed out before, many blocks users might come from Scratch where they only have objects to clone which would be a simple, basic solution for beginners (and no need for a special node which is not a block and which, as a teacher, I need to explain first).

The way we found to add high-level abstraction blocks like "set player 1 score to..." is through custom nodes, and embraces the way Godot works. It would be odd to have a "set player 1 score to..." in every Label node. Feel free to explore other options, though!