I need a way to receive broadcasts by using a variable. I saw that you can input variable when sending a broadcast

broadcast [(Variable) v]

But what is the point if you can't receive the variable? Lol…

I am apparently not allowed to do this

when I receive [(Variable) v]

I'm pretty sure I already know the answer to this question. But I wanted to make sure I wasn't missing something right in front of me.

I really really need this so that I can send broadcasts to specific sprites rather than having them ALWAYS be globally received. It seems like a giant weakness in scratch's armor

The scratchblock didn't turn out as I had thought, hopefully this will do it xD (but maybe not)

broadcast [(Variable]


when I receive [(Variable)]

when I receive [() v]

That should do the trick…

Gosh, I always thought that would be useless. Wouldn't it be? As it is, each broadcast someplace must be defined to do anything, and the desired result would be, well… broadcasts doing things. So if you fire off

(join (type) [cats])

It only makes sense to have a

when I receive [1cats v]

somewhere in the scripts.

Where would

when I receive (cats)

come in?

JoeyTheChicken wrote:

Gosh, I always thought that would be useless. Wouldn't it be? As it is, each broadcast someplace must be defined to do anything, and the desired result would be, well… broadcasts doing things. So if you fire off

(join (type) [cats])

It only makes sense to have a

when I receive [1cats v]

somewhere in the scripts.

Where would

when I receive (cats)

come in?

Hi again

So here is why this would be amazingly useful.
Imagine if you did not want each and every sprite to receive the same broadcast.
For example, lets say you have 5 clones, each clone has a unique ID number. So the first clone's ID number would be ‘1’ and second one would be ‘2’ and so on. This way you can tell which clone is which by their ID.

Now lets say you only want clone #2 and clone #5 to receive a broadcast that tells them to jump in the air. But you can't do that because not only will clone #2 and #5 receive the broadcast. Every other clone will also get the broadcast, meaning everything will jump. It's not under your control to decide who jumps and who doesn't because broadcasts are global.

But what if you put a variable and a “Join” block into the block

broadcast (join [Jump] (CloneID))

when I receive (join [Jump] (CloneID))

Using this block, you could specify which clones you want to have receive the broadcast by using their CloneID number in combination with the word “jump”. This way, you would prevent every single clone jumping

Or you could do it the hard way by creating a new broadcast for every.. single.. clone.. by.. hand xD. Which I can't do cause there is no limit to how many clones there may be in my game

GameArchitect wrote:

JoeyTheChicken wrote:

Gosh, I always thought that would be useless. Wouldn't it be? As it is, each broadcast someplace must be defined to do anything, and the desired result would be, well… broadcasts doing things. So if you fire off

(join (type) [cats])

It only makes sense to have a

when I receive [1cats v]

somewhere in the scripts.

Where would

when I receive (cats)

come in?

Hi again

So here is why this would be amazingly useful.
Imagine if you did not want each and every sprite to receive the same broadcast.
For example, lets say you have 5 clones, each clone has a unique ID number. So the first clone's ID number would be ‘1’ and second one would be ‘2’ and so on. This way you can tell which clone is which by their ID.

Now lets say you only want clone #2 and clone #5 to receive a broadcast that tells them to jump in the air. But you can't do that because not only will clone #2 and #5 receive the broadcast. Every other clone will also get the broadcast, meaning everything will jump. It's not under your control to decide who jumps and who doesn't because broadcasts are global.

But what if you put a variable and a “Join” block into the block

broadcast (join [Jump] (CloneID))

when I receive (join [Jump] (CloneID))

Using this block, you could specify which clones you want to have receive the broadcast by using their CloneID number in combination with the word “jump”. This way, you would prevent every single clone jumping

Or you could do it the hard way by creating a new broadcast for every.. single.. clone.. by.. hand xD. Which I can't do cause there is no limit to how many clones there may be in my game

If you want to filter clones then use if statements;

when I receive [jump v]
if <(cloneid) = (clone to jump)> then
... // do jump    
end

Each clone would receive the broadcast anyway and you'd still have to do the filtering that @drmcw mentions so you actually haven't gained anything.

Or what you're suggesting isn't variable receives so much as clone-specific receives. Clones can be confusing enough for most people when they first use them and adding to that would be undesirable.

When I first realised variable broadcasts were possible I did ponder the usefulness of variable receives and came to the conclusion that actually there was little point.

As others have said, this is the whole point of giving ids to clones. You just do the filtering after the hat block (rather than on it) to control which clones act on a broadcast. As long as stuff is properly serialised (broadcast and wait etc) you shouldn't have any issues with this method.

Psiborg wrote:

As others have said, this is the whole point of giving ids to clones. You just do the filtering after the hat block (rather than on it) to control which clones act on a broadcast. As long as stuff is properly serialised (broadcast and wait etc) you shouldn't have any issues with this method.

In order to control it the way you and drmcw have suggested, the variable would have to be local. So that each clone has its own variable saying whether or not it can jump. This means that you cannot use this variable outside that sprite. So if I wanted to have some clones jump from out of a different sprite this wouldn't work. However, this problem would probably exist anyways because of the local cloneID, but there could be a work around of some kind.

But the biggest problem is this. What if you used the jump broadcast again while some clones are already in the middle of jumping?
Well, all the clones would receive the broadcast, including the ones that are jumping. The clones that are already jumping would then stop mid-air because the script got interrupted half way through its loop. The only way I can see to combat this is to literally have a different broadcast for each clone by using the ID number. That way sprites in the middle of jumping won't be interrupted when other sprites are told to jump.

GameArchitect wrote:

Psiborg wrote:

As others have said, this is the whole point of giving ids to clones. You just do the filtering after the hat block (rather than on it) to control which clones act on a broadcast. As long as stuff is properly serialised (broadcast and wait etc) you shouldn't have any issues with this method.

In order to control it the way you and drmcw have suggested, the variable would have to be local. So that each clone has its own variable saying whether or not it can jump. This means that you cannot use this variable outside that sprite. So if I wanted to have some clones jump from out of a different sprite this wouldn't work. However, this problem would probably exist anyways because of the local cloneID, but there could be a work around of some kind.

But the biggest problem is this. What if you used the jump broadcast again while some clones are already in the middle of jumping?
Well, all the clones would receive the broadcast, including the ones that are jumping. The clones that are already jumping would then stop mid-air because the script got interrupted half way through its loop. The only way I can see to combat this is to literally have a different broadcast for each clone by using the ID number. That way sprites in the middle of jumping won't be interrupted when other sprites are told to jump.

Enlightening, actually There are plenty of things I just don't think about. Clone communication is hard. We get lots of people on these forums looking for help with clones, but you might have taken the cake here. But then, where might this be necessary? However, broadcasts can be simulated, as you may see, with a variable, so there's always that. Anyhow, I can imagine something broadcasting “jump1” when clone1 should jump. Maybe

when I start as a clone
forever
    
wait until <(clonejump) = (cloneID)>
jump ::custom
end

would do. It'd cause more lag, but I don't think it has many other issues.

GameArchitect wrote:

Psiborg wrote:

As others have said, this is the whole point of giving ids to clones. You just do the filtering after the hat block (rather than on it) to control which clones act on a broadcast. As long as stuff is properly serialised (broadcast and wait etc) you shouldn't have any issues with this method.

In order to control it the way you and drmcw have suggested, the variable would have to be local. So that each clone has its own variable saying whether or not it can jump. This means that you cannot use this variable outside that sprite. So if I wanted to have some clones jump from out of a different sprite this wouldn't work. However, this problem would probably exist anyways because of the local cloneID, but there could be a work around of some kind.

But the biggest problem is this. What if you used the jump broadcast again while some clones are already in the middle of jumping?
Well, all the clones would receive the broadcast, including the ones that are jumping. The clones that are already jumping would then stop mid-air because the script got interrupted half way through its loop. The only way I can see to combat this is to literally have a different broadcast for each clone by using the ID number. That way sprites in the middle of jumping won't be interrupted when other sprites are told to jump.

The clone id is local as it is a unique identifier for the clone, that doesn't make it jump though; the broadcast and a variable you set to compare with, which would be global, would trigger the jump. The jump shouldn't be a function call from the when I receive jump because, as you state, another broadcast would reset the script; so the jump must cause a state change in the clone, maybe set a variable or change costume.

drmcw wrote:

GameArchitect wrote:

Psiborg wrote:

As others have said, this is the whole point of giving ids to clones. You just do the filtering after the hat block (rather than on it) to control which clones act on a broadcast. As long as stuff is properly serialised (broadcast and wait etc) you shouldn't have any issues with this method.

In order to control it the way you and drmcw have suggested, the variable would have to be local. So that each clone has its own variable saying whether or not it can jump. This means that you cannot use this variable outside that sprite. So if I wanted to have some clones jump from out of a different sprite this wouldn't work. However, this problem would probably exist anyways because of the local cloneID, but there could be a work around of some kind.

But the biggest problem is this. What if you used the jump broadcast again while some clones are already in the middle of jumping?
Well, all the clones would receive the broadcast, including the ones that are jumping. The clones that are already jumping would then stop mid-air because the script got interrupted half way through its loop. The only way I can see to combat this is to literally have a different broadcast for each clone by using the ID number. That way sprites in the middle of jumping won't be interrupted when other sprites are told to jump.

The clone id is local as it is a unique identifier for the clone, that doesn't make it jump though; the broadcast and a variable you set to compare with, which would be global, would trigger the jump. The jump shouldn't be a function call from the when I receive jump because, as you state, another broadcast would reset the script; so the jump must cause a state change in the clone, maybe set a variable or change costume.

So, it wouldn't reset if the code wasn't a function?

JoeyTheChicken wrote:

GameArchitect wrote:

Psiborg wrote:

As others have said, this is the whole point of giving ids to clones. You just do the filtering after the hat block (rather than on it) to control which clones act on a broadcast. As long as stuff is properly serialised (broadcast and wait etc) you shouldn't have any issues with this method.

In order to control it the way you and drmcw have suggested, the variable would have to be local. So that each clone has its own variable saying whether or not it can jump. This means that you cannot use this variable outside that sprite. So if I wanted to have some clones jump from out of a different sprite this wouldn't work. However, this problem would probably exist anyways because of the local cloneID, but there could be a work around of some kind.

But the biggest problem is this. What if you used the jump broadcast again while some clones are already in the middle of jumping?
Well, all the clones would receive the broadcast, including the ones that are jumping. The clones that are already jumping would then stop mid-air because the script got interrupted half way through its loop. The only way I can see to combat this is to literally have a different broadcast for each clone by using the ID number. That way sprites in the middle of jumping won't be interrupted when other sprites are told to jump.

Enlightening, actually There are plenty of things I just don't think about. Clone communication is hard. We get lots of people on these forums looking for help with clones, but you might have taken the cake here. But then, where might this be necessary? However, broadcasts can be simulated, as you may see, with a variable, so there's always that. Anyhow, I can imagine something broadcasting “jump1” when clone1 should jump. Maybe

when I start as a clone
forever
    
wait until <(clonejump) = (cloneID)>
jump ::custom
end

would do. It'd cause more lag, but I don't think it has many other issues.

Yea, that's what I've resorted to. It goes against every fiber in my being though xD. But I'll get over it.
In my case, the use would be tremendous. Basically I have a bunch of clones waiting in a simulated “line” waiting for the elevator. The elevator can only hold 4 people at a time before it goes up the hotel to drop off its passengers.
These clones are given a predetermined time as to when they will arrive at the hotel (i.e. 4:00AM). Once the hour has reached the time they are set to arrive, they will appear on the screen and are put at the back of the elevator queue. I do all this communication using broadcasts and Custom Blocks.
So I have Custom block called “Wait For Elevator”, which is a loop that continually checks to see if the elevator is loading passengers or not.
If the elevator is currently loading passengers, the clone will wait until either it is its turn to get on the elevator, or the elevator runs out of room.
If the elevator runs out of room, the clone will simply repeat the process until it is its turn (which takes times cause the elevator takes time to deliver its passengers to their floors).

In the mean time, more clones are arriving at the hotel to get on the elevator each hour, which causes the “Wait for the elevator” broadcast to be broadcasted again. This broadcast tells every clone to “Wait for the elevator”, but this causes problems for the clones that are already waiting for that elevator. I

If only I could have used something like "Broadcast " or something, so as to not interfere with the other clones.

It may be hard to understand my whole system cause it takes a lot of typing to explain it all, but I hope I did ok.

This is what I said about serialisation. If you are running loops within the receiver then you aren't likely to be using “broadcast and wait” and hence you will lose your serialisation and it won't work. Personally I only run the one loop so I won't hit issues like that - everything processes one tick at a time with countdown or cool down timers etc for things like jumping, shooting and other animated actions.

If I was doing this I think I'd have a list which contained the ‘state’ for each clone. These would be in the form of codes - eg 1=waiting, 2=in elevator etc. Then each clone has a forever loop that watches its own list item (a global list so clones don't have their own copies) and behaves accordingly. Rather than broadcasts use custom blocks so each clone can call a custom block whenever it has something to do.

Gah, now I wish we had this. I could run things smoother by having the clones update one by one instead of all at once.

Here's a quick project with my list idea for this, don't know if it helps. https://scratch.mit.edu/projects/59620728/

GameArchitect wrote:

drmcw wrote:

GameArchitect wrote:

Psiborg wrote:

As others have said, this is the whole point of giving ids to clones. You just do the filtering after the hat block (rather than on it) to control which clones act on a broadcast. As long as stuff is properly serialised (broadcast and wait etc) you shouldn't have any issues with this method.

In order to control it the way you and drmcw have suggested, the variable would have to be local. So that each clone has its own variable saying whether or not it can jump. This means that you cannot use this variable outside that sprite. So if I wanted to have some clones jump from out of a different sprite this wouldn't work. However, this problem would probably exist anyways because of the local cloneID, but there could be a work around of some kind.

But the biggest problem is this. What if you used the jump broadcast again while some clones are already in the middle of jumping?
Well, all the clones would receive the broadcast, including the ones that are jumping. The clones that are already jumping would then stop mid-air because the script got interrupted half way through its loop. The only way I can see to combat this is to literally have a different broadcast for each clone by using the ID number. That way sprites in the middle of jumping won't be interrupted when other sprites are told to jump.

The clone id is local as it is a unique identifier for the clone, that doesn't make it jump though; the broadcast and a variable you set to compare with, which would be global, would trigger the jump. The jump shouldn't be a function call from the when I receive jump because, as you state, another broadcast would reset the script; so the jump must cause a state change in the clone, maybe set a variable or change costume.

So, it wouldn't reset if the code wasn't a function?

Gone through script resets already here https://scratch.mit.edu/discuss/topic/109828/

Events reset, but everything else will run its course like it should.

If not already said:

when green flag clicked
...
broadcast [Sprite1 Jump v]

when I receive [Sprite1 Jump v]
Jump
define Jump
repeat (10)
    
change y by (1)
end
wait (1) secs
repeat (10)
  change y by (-1)  
end