I know when I receive any message exists as well as the message block but those can be very buggy and most people likely don’t know that the message block even exists
So instead of all messages how about making it so you can put a list in the message input
The block would listen for messages of the names in the List, if it gets one then it will run the hat
Making multiple hats with identical code underneath isn’t a workaround because you could trigger 2 different ones at the same time
I don't think that's quite what you meant to post 
That is what I meant to post...
OK.....
could you explain how it's meant to work then?
It doesn’t make sense
Oh, I meant to stick the data block in the second slot in the contains block (where it says thing)
Yes but that involves the (message) block that’s not known by a lot of people, as well as if you broadcast any message during the script than it completely stops if it’s not listening for it. This block wouldn’t do that just like the other message blocks
It doesn't use the message block, it uses the data variable that you can easily access by selecting any message in the when I recieve dropdown.
But that requires you to send the message name as well as any other data with it
The data variable is the message name. If you also send data, then the data variable will be a list, with the first item being the message name, and the second being the data that was sent.
I never knew that..
Still the solution isn’t fully airtight, still if you broadcast another different message that it isn’t listening for than it stops the script, what if you are broadcasting a message without data and some with data
It doesn't stop any script
Edit: oh, I just tested it, and it does stop the script...
That’s a big big issue because in complex projects you can have multiple messages running at the same time all the time
A solution would be to launch the scripts. Another option is, use different when I recieve blocks for scripts that are meant to do different things.
Snap! has two ways of handling overlapping events. The default way (inherited from Scratch) is that a second event restarts the script, dropping the processing of the first event in the middle. This has the obvious disadvantage that it can leave data structures in an inconsistent state, but it has the advantage of prompt handling of events, which is especially important for timing the playing of music. The second way, which you get by choosing "Thread safe scripts" in Settings 
, just drops the second event, so it never gets handled at all, but any event that starts is guaranteed to finish.
Of course neither of these is the Official Right Thing. I've long been advocating for a real event queue, so all events are handled in the order received, not necessarily promptly if users' event handlers are slow. I would like any of the three strategies to be choosable on a per-script basis, not as a global option.
Jens doesn't exactly argue against this, iirc, but it isn't a priority for him. Maybe he worries that it would slow things down too much.
It could in fact slow things down, but I don’t see how much as it’s basically just adding another hat block
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
