The cloud is still a new idea with many limitations. However, as this eventually changes, I think it would be necessary to have a block that runs upon a project being stopped (via a stop all block, clicking the red square, or even the user x-ing out of their browser. I am pretty sure this is possible code-wise.).

Being able to make sure I can do certain things if someone leaves my project would make me feel much more secure - especially in the prospect of online multiplayer games, which I am currently attempting to make work decently. I could register if someone leaves a match and notify the other player, I could save any information I might want to recover upon their return to my project, I could save resources by ending any cloud data associated with their session, etc…

The worst damage this block could do is crash the webpage (and not allowing it to close) if someone intentionally overloads the block with infinite commands, but the Scratch Team can choose how to handle this. The block should run without the delay that all other blocks experience, so a reasonable script should be completed in milliseconds. Thus, any more time the script says it needs could be deemed unnecessary and the project force-ended.

To help with that issue, it would work to simply blacklist the following blocks, as they shouldn't be used for this type of purpose anyways:

No support. The stop sign is meant to stop the project.

stickfiregames wrote:

No support. The stop sign is meant to stop the project.

Well, it's still gonna stop the project practically instantaneously.

Bump…

But if the user closes out of their browser, that means that the script will have to be run on the Scratch server.

If someone just did this:

then the Scratch server would be running a very computationally-heavy process. This could eventually crash the servers unless scripts were force-shut-down after a few seconds, which might not be enough for some people's scripts to run.

No support. There are better ways of finding out if someone has left a cloud game. I implement something like that here which kind of works, as well as here (although the second one actually doesn't work).

AonymousGuy wrote:

But if the user closes out of their browser, that means that the script will have to be run on the Scratch server.

If someone just did this:

then the Scratch server would be running a very computationally-heavy process. This could eventually crash the servers unless scripts were force-shut-down after a few seconds, which might not be enough for some people's scripts to run.

No support. There are better ways of finding out if someone has left a cloud game. I implement something like that here which kind of works, as well as here (although the second one actually doesn't work).

Well there aren't better ways, it's actually kind of impossible unless cloud variables had millisecond-scale delay instead of second-scale delays. You specifically state in your first project that “people will not disconnect, which needs to be fixed.” If you actually find a fix, please let me know (I don't mean that sarcastically, because this is would be what I'm looking for).

I totally understand the problem with scripts being stressful / problematic if they are too long, but I think it would be better to find solutions (instead of dismissing the concept altogether). Also, scripts of this type should not take “a few seconds” to run. *Updating OP*

In my second project there are scripts which disconnect users, and in my first project there might also be and I just forgot to update the description.

But anyways, what about the scripts running on the server problem? How would you solve that?

stickfiregames wrote:

No support. The stop sign is meant to stop the project.

Yeees, check out my stick former project which has a way of constantly playing even with pressing the stop sign

RPFluffy wrote:

stickfiregames wrote:

No support. The stop sign is meant to stop the project.

Yeees, check out my stick former project which has a way of constantly playing even with pressing the stop sign

Wow that is quite a sneaky timer trick. But it doesn't do anything if a player closes their browser…

AonymousGuy wrote:

In my second project there are scripts which disconnect users, and in my first project there might also be and I just forgot to update the description.

But anyways, what about the scripts running on the server problem? How would you solve that?

Well your second project kind of crashes chrome…. So I can't run it

As for the scripts running on the server, what's the problem again? The whole project is stored on scratch servers, and this would obviously include the on close block. Thus, whenever a project is closed it can be temporarily stored under the user's username (and take up as much space as if they remixed the project, I assume), run the on close block for whatever time limit (not even necessary if said blocks above are blacklisted/banned), then delete the instance. Remember, the whole point is to update cloud variables (as I see it, anyways).

dont suggest blocks like

The problem with projects running on the Scratch server is that it would require server CPU to run them.

And if someone did something like I mentioned on their on close script, it could very well eat up a large amount of CPU, no matter how good Scratch servers are, because it's essentially a forkbomb.

Aside from that, the project will not know when the user closes their browser, so it would actually have to be running on the Scratch server the entire time or pinging the user constantly and getting updates from what was happening. For the first option, that would mean that the Scratch server would essentially be streaming the project to the user, which might work but could also result in buffering with bad internet connection. For the second option, it would be the other way around, and if the Scratch server lost connection for a second, variables and other things might not be updated correctly or if the server timed out while the user closed their browser, the script wouldn't be run.

So please explain how to solve this.

I have less experience with computer-based programming languages, but I know with mobile applications, an app will call a method when it is closed, called onDestroy();. This is so that, when your app closes, it has a chance to destroy references it made and save space/ram on the phone. Basically, I want to be able to do that. If a client (say, my google chrome tab that holds scratch.mit.edu/myproject in it), can indeed ping the server with its intent to close, then scratch (which already has both the project stored and variable data - that's how projects are saved to our account in the first place) can simply run the block. It won't cause cpu issues if said blocks are disabled, and there is an appropriate force-close time limit. It's just one script. Although, I am not 100% sure of either case, so if at least the possibility of this could be confirmed/denied by ST….

But yeah, if I am wrong on the onDestroy thing, then this would be implausible.

Penguin9090_new wrote:

dont suggest blocks like

Why?

I guess, yes, you could detect a close event and request the server to do something based on that, or run the scripts locally on the close event.

The problem of detecting when a user forcibly disconnects from a near-real-time cloud project has been mentioned several times before.

The bottom line is that the job of clearing up a player who has left really falls to (one of) those who remain in the game. This is usually done by having a regularly updated per-user ‘flag’ or time-stamp within the cloud variables, and those are watched by others in the game. If a player's flag doesn't update for a few seconds, then one of the remaining players should take action to ‘kick’ them from the game.

The only slightly problematic case is when the last player leaves. At that point the cloudvars could be ‘stuck’ in some funny state. But it actually doesn't matter right then, because there's nobody around to care!

It's only when someone does join the game again later on that they have to sort out the mess. This means they will start off by seeing someone still in the game (the last player who left), but notice after a short time that their ‘flag’ is not changing - and so kick them out.


Actually, I'd like to see a cloud server time-stamp reporter. This would have the effect of providing a global value that all those connected can use to compare absolute time when putting into a per-user time-stamp in their cloudvars.

It would mean the clean-up by remaining players is just as I described above - except that it would have the advantage that someone who joins a game with no players left can immediately tell that the previous player left a long time ago, and so does not have to act like they are still in the game until they notice that their time-stamp is no longer updating.

Hope that makes sense!

DadOfMrLog wrote:

Actually, I'd like to see a cloud server time-stamp reporter. This would have the effect of providing a global value that all those connected can use to compare directly as a per-user time-stamp in their cloudvars.

The days since 2000 blocks always uses UTC. It should be pretty much the same for every user.

djdolphin wrote:

DadOfMrLog wrote:

Actually, I'd like to see a cloud server time-stamp reporter. This would have the effect of providing a global value that all those connected can use to compare directly as a per-user time-stamp in their cloudvars.

The days since 2000 blocks always uses UTC. It should be pretty much the same for every user.

Assuming the user's clock is correct on their computer - that's why I'd prefer it to be server time…

0bitasy0 wrote:

-snip-

Penguin9090_new wrote:

dont suggest blocks like

Why?

Because the stop sign is to STOP everything, not to start new scripts

Okay, ignore everything I said previously - just because I use lots of words doesn't actually mean I know what I'm talking about.

However, no matter if I was wrong (at least partially), there still is the problem of scripts like the following:

This has to be run one of two places: The user's client when they close the window (that definitely won't work, as that would literally force their browser to stay open (at least in the background) until the script crashed) or on the Scratch servers, where the script would be activated when the user closed their browser.

We obviously don't want to lag the Scratch servers even a little bit from a bad user script, so some sort of safeguard would have to be in place:
1) Disallow custom blocks from being used with the “on close” hat - this definitely isn't a good idea, because cloud projects often use custom blocks for encoding / decoding cloud variables.
2) Kill high-memory Flash processes on the Scratch server - this might work better, as in this way any bad scripts would be killed. Of course, this wouldn't be good if somehow a user's legitimate script ended up using a bunch of memory and the cloud data got corrupted, but it's a chance that would had to be taken.
3) Any other solutions? If you have any, I would like to hear them.

So yes, this is possible with a little tweaking. The other thing to think about is if the script was made to run on the Scratch server, could a malicious extension hijack any sort of data? (I would think not, especially because Flash is really picky with permissions, but some sort of exploit might be (and probably is) possible….)

DadOfMrLog wrote:

The problem of detecting when a user forcibly disconnects from a near-real-time cloud project has been mentioned several times before.

The bottom line is that the job of clearing up a player who has left really falls to (one of) those who remain in the game. This is usually done by having a regularly updated per-user ‘flag’ or time-stamp within the cloud variables, and those are watched by others in the game. If a player's flag doesn't update for a few seconds, then one of the remaining players should take action to ‘kick’ them from the game.

The only slightly problematic case is when the last player leaves. At that point the cloudvars could be ‘stuck’ in some funny state. But it actually doesn't matter right then, because there's nobody around to care!

It's only when someone does join the game again later on that they have to sort out the mess. This means they will start off by seeing someone still in the game (the last player who left), but notice after a short time that their ‘flag’ is not changing - and so kick them out.


Actually, I'd like to see a cloud server time-stamp reporter. This would have the effect of providing a global value that all those connected can use to compare absolute time when putting into a per-user time-stamp in their cloudvars.

It would mean the clean-up by remaining players is just as I described above - except that it would have the advantage that someone who joins a game with no players left can immediately tell that the previous player left a long time ago, and so does not have to act like they are still in the game until they notice that their time-stamp is no longer updating.

Hope that makes sense!

Yeah, not only did that make sense, but that is exactly what I thought of. The problem?

0bitasy0 wrote:

Well there aren't better ways, it's actually kind of impossible unless cloud variables had millisecond-scale delay instead of second-scale delays.

..I wish I could have a cloud variable update regularly per user, but the reality is that they're not fast enough at the moment. Even if there are only, say 6 users online at one point, the 6 people would be pinging the server via the same variable, which has a 1-ish second delay between computers. Thus, the others would be updating the variable with their own ping before the variable could come back to them, and it would seem as if nobody else is pinging on, and they would kick everyone else out of the game…. and this would be happening on each computer.
———————————————————————————————————————————————————–
@AonymousGuy yeah, I have been thinking your second option is the best bet - and honestly, for a block that should simply settles cloud variables at the end of a play session, there should be a fine line between a legitimate script and a broken one. As for the hacking… possible, but so extremely unlikely. It would ultimately be up to the scratch team to prevent this (using the same method that, say, Google does for blocking code in its search bar).

0bitasy0 wrote:

Thus, the others would be updating the variable with their own ping before the variable could come back to them, and it would seem as if nobody else is pinging on, and they would kick everyone else out of the game…. and this would be happening on each computer.

That's why you have to limit the number of players and have each one allocated to their own cloud variable - that way they cannot stamp on anyone else's toes. If you reserve two of the cloudvars for other more general in-game use, that leaves eight cloudvars, allowing up to eight players.

Take a look at my cloud ping test project for some ideas: http://scratch.mit.edu/projects/10577286/

I've actually experimented more recently with up to three players on one cloudvar, and it is just about ok (if none of them fall back to the http polling method, which has some really serious issues…) That might allow up to 24 players.