yes I made one of these so there is a work around but it is a little bit unorganized and uses a cloud variable. (we only get ten so that is not exactly a good workaround though it can easily be done)



to see a working won look at my most recent project I added an example

does anybody know this is on the 666th page on suggestions

Hello! I am going to bump this for the scratch team to see and take into consideration.

Uhm…

set [number v] to [0]
forever
    broadcast ☁ (number) :: events
    change [number v] by (1)
end

SuperMarioHome wrote:

Uhm…

set [number v] to [0]
forever
    broadcast ☁ (number) :: events
    change [number v] by (1)
end

close ur blocks and also could you explain more?

+1
this sounds like a cool idea

thats a great idea!

SuperMarioHome wrote:

Uhm…

set [number v] to [0]
forever
    broadcast ☁ (number) :: events
    change [number v] by (1)
end

Simple. Add a limit per minute for cloud broadcasts. Also, please explain your argument in a way other than

Uhm…

[insert blocks here]

Bump

Bump

Design (3.0 blocks)

Boardcast blocks

Broadcast [message1 v] over cloud :: variables
Boardcast [message1 v] over cloud and wait :: variables

Cloud gat blocks

When [message1 v] over cloud received:: hat :: variables 

Announcements block (with filter)

Send out an cloud announcement with text [Text] :: variables

(current announcement)
(Announcement by)

When an announcement is sent ::hat :: variables 

here (better)

☁️ broadcast [ v] :: events
☁️ broadcast [ v] and wait :: events

when I receive [ v] ☁️ :: hat :: events

gdfsgdfsgdfg wrote:

here (better)

☁️ broadcast [ v] :: events
☁️ broadcast [ v] and wait :: events

when I receive [ v] ☁️ :: hat :: events

However I made one

gdfsgdfsgdfg wrote:

here (better)

☁️ broadcast [ v] :: events
☁️ broadcast [ v] and wait :: events

when I receive [ v] ☁️ :: hat :: events

Cloud broadcasts should definitely have a ton less limitations because they can’t be custom set to a value I don’t see a reason not to allow you to have a ton of them. Because broadcasts are just a binary value it’s only 1 extra byte for each broadcast so we could at least have up to 256

As other have mentioned above you would only be able to broadcast any cloud broadcast once every 1/10th of a second like with cloud variables
But unlike them it apllies to every cloud broadcast so you can’t broadcast 1 and then broadcast another within 1/10th of a second

or

broadcast [☁️ message v]
broadcast [☁️ message v] and wait

when I receive [☁️ message v]

Bump!

Would there be a section for them in events?
Also ignore the name LOL I got the broadcast name from another project.

bobbybee wrote:

+3.14159265858979323

clearywalsh wrote:

+1

Tbtemplex97 wrote:

+1 useful idea.

savaka wrote:

Support!

People were so unconstructive back in 2.0…

Anyways, this seems like a good idea because to do it now you would have to make a cloud variable, set it to, I don't know, 1, and use the <() = ()> block. And it's not like this could really be used to make cloud chats any more than cloud variables can.

k7e wrote:

bobbybee wrote:

+3.14159265858979323

People were so unconstructive back in 2.0…

I was laughing when I saw the 3.141592 one and your message LOL
Also, support!

k7e wrote:

Anyways, this seems like a good idea because to do it now you would have to make a cloud variable, set it to, I don't know, 1, and use the <() = ()> block. And it's not like this could really be used to make cloud chats any more than cloud variables can.

Well, I guess you could kind of do this?

+3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679