I support, but it may be too difficult to implement. I myself would find it very useful however. And there would have to be a limit of how many bridge variables an account can have most likely, similar to how a project can only have 10 cloud variables.

Nice idea. I support for sure. Also, would it require cloud lists to be added?

If ST adds bridge variables, I will become angry D: and quit scratch.

24691357 wrote:

If ST adds bridge variables, I will become angry D: and quit scratch.

Why

Do you think its time to tell the scratch team about this yet

Paddle2See commented on the suggestion:

Paddle2See wrote:

Seems like it adds a fair amount of complexity. Can somebody explain some typical use cases that this feature would allow?

Remember, you can already communicate between projects by using the Export / Import feature of lists.

We've made progress, but I guess we're still waiting on a definite yes or no for the suggestion.

zorket wrote:

Paddle2See commented on the suggestion:

Paddle2See wrote:

Seems like it adds a fair amount of complexity. Can somebody explain some typical use cases that this feature would allow?

Remember, you can already communicate between projects by using the Export / Import feature of lists.

We've made progress, but I guess we're still waiting on a definite yes or no for the suggestion.

2 questions. #1 - how long ago did he comment on it? #2 - how do you keep changing the topic's name?

Saiid wrote:

2 questions. #1 - how long ago did he comment on it? #2 - how do you keep changing the topic's name?

He commented in March this year, and you can change a topic title while you are editing the post, it's above the main text.

zorket wrote:

Saiid wrote:

2 questions. #1 - how long ago did he comment on it? #2 - how do you keep changing the topic's name?

He commented in March this year, and you can change a topic title while you are editing the post, it's above the main text.

K. I talked to him today, and he said:

Well - I don't think it has been out-right rejected at this point. But there doesn't seem to be much interest on the team in expanding the role of cloud variables. At least, I haven't heard anybody talking about it.

So…
And k, thx

24691357 wrote:

If ST adds bridge variables, I will become angry D: and quit scratch.

Is there any specific reasons for this? Bridge variables will do nothing more than connect your own projects with each other. Other than that, they act like normal cloud variables. You can just not use them if you don't want.

Semi-support. It would help, but it might confuse some people.

Ziggy741 wrote:

No support. It would help, but it might confuse some people. Also what if a project with a bridge variable got remixed, and the user who remixed the project set the bridge variable to an amount that wasn't supposed to be that amount? Would it affect the other project (not the original project) with the bridge variable? Because users could purposely remix the project just to set the bridge variable to an unwanted amount if it affects the other project (again, not the original project).

Sorry if I necroposted.

Ziggy741 wrote:

No support. It would help, but it might confuse some people. Also what if a project with a bridge variable got remixed, and the user who remixed the project set the bridge variable to an amount that wasn't supposed to be that amount? Would it affect the other project (not the original project) with the bridge variable? Because users could purposely remix the project just to set the bridge variable to an unwanted amount if it affects the other project (again, not the original project).

But it wouldn't affect the other project, because to link to projects you would have to go into that project and load the bridge variable. Therefore, it would only work with your projects. Other services might link two projects with the project ID, but this would load it into one of the user's projects, even if it originally loaded into someone else's project. Hope this makes sense

Saiid wrote:

Ziggy741 wrote:

No support. It would help, but it might confuse some people. Also what if a project with a bridge variable got remixed, and the user who remixed the project set the bridge variable to an amount that wasn't supposed to be that amount? Would it affect the other project (not the original project) with the bridge variable? Because users could purposely remix the project just to set the bridge variable to an unwanted amount if it affects the other project (again, not the original project).

But it wouldn't affect the other project, because to link to projects you would have to go into that project and load the bridge variable. Therefore, it would only work with your projects. Other services might link two projects with the project ID, but this would load it into one of the user's projects, even if it originally loaded into someone else's project. Hope this makes sense

OK. I'll switch to semi-support.

Support, but this would be really expensive in terms of data.

LP_Play wrote:

Support, but this would be really expensive in terms of data.

true

IcyCoder wrote:

LP_Play wrote:

Support, but this would be really expensive in terms of data.

true

How would it be any more expensive than cloud variables?

BoyKetchup wrote:

IcyCoder wrote:

LP_Play wrote:

Support, but this would be really expensive in terms of data.

true

How would it be any more expensive than cloud variables?

Getting the new data needed to store it.

LP_Play wrote:

Support, but this would be really expensive in terms of data.

Wait. Really?

zorket wrote:

Paddle2See commented on the suggestion:

Paddle2See wrote:

Seems like it adds a fair amount of complexity. Can somebody explain some typical use cases that this feature would allow?

Remember, you can already communicate between projects by using the Export / Import feature of lists.

We've made progress, but I guess we're still waiting on a definite yes or no for the suggestion.

I feel like Paddle2See actually has a point. Sure, you can use it for, a multi stage game, but why not combine them? They are, after all, one project. I asked my little brother, and he thought it was too complicated. For emerging Scratchers, doesn't it make sense for one project to be self contained?

Don't get me wrong - I do see how the potential upsides. If you make the second half based on popularity, it would be nice to transfer their “User Stats” to the second project. Or maybe, if you have something that goes pass the storage limit, you may want that, or multiple servers… but all of this is hard.

Paddle2See wrote:

Seems like it adds a fair amount of complexity.

In the end, you have to consider Scratch's target audience - Should new programmers be exposed to such complexity?

In conclusion, I have to make another point. Reading past posts, I feel like the question has changed from “Why should we have it?” to “Why shouldn't we?”, which, in my opinion, is not the correct way to frame a suggestion. Example: Why shouldn't we have a Veloceraptor head run across the screen every page load on the forums?

I hope you have heard and understood my doubts, and recognized that I'm not one of the “already a workaround”, “servers can't handle it” or “No support” people.

Thanks!

PS: Does your suggestion help the target audience have a smoother experience? Example: the steps block.