Should we introduce a "when cloud variable updates/changes" hat block?

[thisandagain]

In discussions about cloud vars, users have expressed desire for an easier, more straightforward way to take action when a cloud var has changed.

This can be done using various patterns -- e.g., use a local variable to mirror the cloud variable, and have a forever loop check the cloud value against the local value.

But a "when cloud variable updates/changes" hat block would greatly simplify this.

Could be easier to do after/as part of moving cloud variables into an extension (see LLK/scratch-blocks#1889 )

---

Moved from LLK/scratch-blocks#1890 /cc @benjiwheeler

[towerofnix]

Quoting my comment from the original issue:

This reminds me of an extension I made a couple days ago:

Thoughts on implementing an extension like that instead of this block? Obviously it would work nicely with cloud variable blocks, so I think it would be an interesting way to encourage users to mix and match extensions so that they work together.

(The overall benefits to my extension are that it's very generally useful, both practically and educationally; I just think it fits extra well with cloud variables as discussed here.)

[mrjacobbloom]

Doing anything multiplayer using cloud vars has always been super difficult (not to mention that you need to share the project and have a second Scratcher-status'd account before you can even test it). The more new blocks that can abstract this kind of stuff away, the easier it'll be to create complex multiplayer games and to do them right.

Also, this block would parallel real-world event-driven http request code, which I think is pretty cool. Not that teaching kids how to write event-driven servers is an express_(.js) goal of Scratch.

[griffpatch]

The problem I have with cloud vars limited in update frequency the way they are, you almost certainly need to learn how to encode data into number strings to use them... But if you can do so, then you can then send chat room style messages? So is the fact that you need to be proficient at scratch the hurdle used to decide that a scratcher is morally capable of behaving too ;)

I do like the idea of being able to know a cloud var has changed, but a hat block would only be useful if say it let you know 'which' cloud var had updated, and preferable which user updated it (username). That still has the added complication that you then need to get the data for the correct cloud var using lots of if elses...? But hey, that's better than what we currently have. ish...

On Wed, 6 Feb 2019 at 07:15, Jacob notifications@github.com wrote:

Doing anything multiplayer using cloud vars has always been super difficult (not to mention that you need to share the project and have a second Scratcher-status'd account before you can even test it). The more new blocks that can abstract this kind of stuff away, the easier it'll be to create complex multiplayer games and to do them right.

Also, this block would parallel real-world event-driven http request code, which I think is pretty cool. Not that teaching kids how to write event-driven servers is an express(.js) goal of Scratch.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LLK/scratch-gui/issues/4489#issuecomment-460923462, or mute the thread https://github.com/notifications/unsubscribe-auth/AGbNvlT_DR49ZKPjXuuVaNVHpEs0Xl4Wks5vKoEogaJpZM4ajgv9 .

[TheLogFather]

Several things...

I don't see such a hat block being as important as other cloudvar info (specifically time since cloudvar last changed [note that wording it like that removes any questions about time-zone...], and the name of user who last changed it).

The most important missing thing w.r.t. cloudvars (apart from that they actually work, which is barely the case at the moment!) is being able to see, in a sense, from the cloud-server's point of view – i.e. to know that any change (including a local one) happened remotely, and was visible to the 'outside world'.

If a "when cloudvar changes" hat block does exist, it's really most useful if it only triggers when the cloud-server itself detects there was a change. Note this can include a change made locally, but only if that local change actually made it to the cloud server (i.e. the hat block gets triggered because it's the cloud server 'reporting back' that it detected the change). Having this knowledge (i.e. that you really are still making a difference that others can see) really is a game-changer when dealing with cloudvars!

[TheLogFather]

One thing perhaps worth mentioning w.r.t. edge-triggered hat blocks is that, even though they give the impression that Scratch scripting is becoming more like modern event-driven coding, the way they really behave isn't how many Scratchers actually think of them.

That means they can sometimes end up being more confusing than helpful.

For example, for a hat block which detects when a variable exceeds a certain value, many Scratchers might expect that it would get 'triggered' at any point the condition occurs while a script is running – even if the variable might change back at the very next block.

I've come across this confusion fairly often (and I suspect adding something like the 'when touching' hat block[s?] will make that become even more apparent – indeed, see https://github.com/LLK/scratch-gui/issues/2300, for a relevant example...). I guess in one sense it's not really that different from the oft-seen 'timing' problems that come about when having two (or more) sprites checking "if touching" each other, with at least one responding immediately in such a way that the other then hasn't got chance to detect that touch.

I think for the case of 'when cloudvar changes', though, the word "changes" gives a generic enough condition, whilst still useful to indicate that something really did happen to that cloudvar (–as long as it's the cloud-server that 'drives' it, as mentioned above).

[Mr-Dave2]

Could this change mean that there would be less concern for the simple references to cloud variables be appear to be in sync with the cloud server, and if so would that allow you to increase the throttling of cloud var updates to the server, and would that decrease the load on the cloud server, which could increase its available capacity, which you could then use to allow cloud lists as an option?