When you create a new block named CUSTOM_BLOCK (INPUT 1) and then define another block called CUSTOM_BLOCK (INPUT 2), the first block definition becomes obsolete. Regardless of which instance of the block you use, the second one is always executed.
This happens because, internally, Scratch maps custom blocks to a generic identifier: CUSTOM_BLOCK %s (for block 1) and CUSTOM_BLOCK %s (for block 2), where %s represents an input (and %b represents a boolean). Since both blocks share the same mapping, Scratch cannot distinguish between them, leading it to always execute the most recently defined version.
There are two possible solutions:
- Modify
scratch-blocks to correctly recognize and obey the internal custom block ID. (Each block currently does have a unique internal ID, it just not being used (you can actually successfully parse a custom block into the editor without specifying its id at all)).
- (Probably easier) Prevent users from creating custom blocks that would result in duplicate mappings with an existing block.
When you create a new block named
CUSTOM_BLOCK (INPUT 1)and then define another block calledCUSTOM_BLOCK (INPUT 2), the first block definition becomes obsolete. Regardless of which instance of the block you use, the second one is always executed.This happens because, internally, Scratch maps custom blocks to a generic identifier:
CUSTOM_BLOCK %s(for block 1) andCUSTOM_BLOCK %s(for block 2), where%srepresents an input (and%brepresents a boolean). Since both blocks share the same mapping, Scratch cannot distinguish between them, leading it to always execute the most recently defined version.There are two possible solutions:
scratch-blocksto correctly recognize and obey the internal custom block ID. (Each block currently does have a unique internal ID, it just not being used (you can actually successfully parse a custom block into the editor without specifying its id at all)).