Please, just say if you support, semi-support, no-support, or don't understand how it works

blump

Support.

jokebookservice1 wrote:

EDIT: Reminder; the workaround exists, but it seems inconvenient, and uses lists + broadcasts

How would you work around global blocks in this?

Jonathan50 wrote:

Support.

jokebookservice1 wrote:

EDIT: Reminder; the workaround exists, but it seems inconvenient, and uses lists + broadcasts

How would you work around global blocks in this?

broadcast and wait + you would need to combine the scripts together because you will have race conditions there anyway so why not predefine which goes first…

Bump.

But from now on, please don't just state your support, or lack thereof. Instead please add to the discussion.

b u m p

SUPPORT HAHAHAHAHAHA

In reality though, I don't quite understand the suggestion. Could you explain it to me?

Lythium wrote:

SUPPORT HAHAHAHAHAHA

In reality though, I don't quite understand the suggestion. Could you explain it to me?

So currently, every custom block created can only be invoked from the sprite that it is in. Sometimes you have projects where you need to have a sprite call another to do something. Broadcasting basically. Maybe for a cloud list engine. You need the broadcast to take arguments.

So if the Cat sprite has

then (with different wording)

(It would say “Tell cat:” but yeah..)

Unlike the problems with other global broadcasts, here, only one sprite executes the custom block, but others can call another block to run it (with arguments)

Support I like your idea as per making this run the block in the scope of the sprite it is defined in. Though it could simply run in its own little sandbox like a clone.

jokebookservice1 wrote:

joefarebrother wrote:

Support!

Maybe in other sprites than the one defines, they could be prefixed with the sprite name, for example if “Sprite1” had

and this option was checked, other sprites would do (and see in their more blocks pallet)

to call it.

Good Idea!

Or maybe there could be global and local custom blocks, like local and global variables and lists, so

could only be used by Sprite1, but

could be accessed by any sprite in the project.

I'm thinking; this is the only efficient method for variable broadcasts. Otherwise you'd need to be looking for random broadcasts all the time.