Blocks that report information about the project and creator of it:

loves::sensing reporter
favorites::sensing reporter
comments::sensing reporter
remixes::sensing reporter
studios::sensing reporter
followers::sensing reporter
# of projects::sensing reporter

I don't see how this is necessary, but it's too complicated, don't you think so?

I believe this would just create more competition among scratchers.

I'd like these, but it could be used for terrible contraptions like:

if <(loves :: sensing reporter) = [100]> then
say [I'M BETTER THAN YOU!! HAHAHA!!]
end

LionHeart70 wrote:

I'd like these, but it could be used for terrible contraptions like:

if <(loves :: sensing reporter) = [100]> then
say [I'M BETTER THAN YOU!! HAHAHA!!]
end

Well, the username block can already be used for terrible contraptions that are more personal.

if <(username) = [FancyFoxy]> then
say [U SUCK]
end

But that doesn't mean it also has a use.
I think I could see an instance where this would be useful.

I don't see how this can be abused, though I also don't see many applications for these blocks other than in statistical projects or About Me projects. Also, unless the data is fetched while the project loads and not updated while the project is running, it may cause a bit of lag since it'll have to pause the script temporarily as it fetches the data from the server

EDIT: What would some of these blocks report in the offline editor?

What would the

(# of projects :: sensing)

block do anyways? It's for studios, not for projects. Even though it shows up as a statistic in My Stuff.

Sheep_maker wrote:

What would some of these blocks report in the offline editor?

Probably just return nothing; that's what the username block returns.

FancyFoxy wrote:

LionHeart70 wrote:

I'd like these, but it could be used for terrible contraptions like:

if <(loves :: sensing reporter) = [100]> then
say [I'M BETTER THAN YOU!! HAHAHA!!]
end

Well, the username block can already be used for terrible contraptions that are more personal.

if <(username) = [FancyFoxy]> then
say [U SUCK]
end

But that doesn't mean it also has a use.
I think I could see an instance where this would be useful.

That's true.
I never really said I didn't support it. I did say I liked the idea. And yeah, seems weird to say no to a block that has a chance of being used as an attack - unless, of course, there's literally almost no usage except that.
I can see these blocks being put to good use, though. Don't know how often it'd be used, however..

FancyFoxy wrote:

What would the

(# of projects :: sensing)

block do anyways? It's for studios, not for projects. Even though it shows up as a statistic in My Stuff.

I would assume this would report the number of (shared?) projects the creator has.

I could assume that these blocks could be functional…

when green flag clicked
forever
if <<(loves :: sensing) = (1000)> and <(favorites :: sensing ) = (1000)>> then
switch backdrop to [I got 1000 loves and favorites! Thank you! v]
end
end

...
say (join(remixes :: sensing )[ projects have been remixed from this project.])
...

...
say (join[Wow, we received](join(comments :: sensing )[comments!]))
...

I mean, we do have a username block.

Charles12310 wrote:

I could assume that these blocks could be functional…

when green flag clicked
forever
if <<(loves :: sensing) = (1000)> and <(favorites :: sensing ) = (1000)>> then
switch backdrop to [I got 1000 loves and favorites! Thank you! v]
end
end

...
say (join(remixes :: sensing )[ projects have been remixed from this project.])
...

...
say (join[Wow, we received](join(comments :: sensing )[comments!]))
...

I mean, we do have a username block.

The username is far more useful than these. I can't think of a single project that would use these, aside from projects people made specifically trying to use them.

duckboycool wrote:

Charles12310 wrote:

I could assume that these blocks could be functional…

when green flag clicked
forever
if <<(loves :: sensing) = (1000)> and <(favorites :: sensing ) = (1000)>> then
switch backdrop to [I got 1000 loves and favorites! Thank you! v]
end
end

...
say (join(remixes :: sensing )[ projects have been remixed from this project.])
...

...
say (join[Wow, we received](join(comments :: sensing )[comments!]))
...

I mean, we do have a username block.

The username is far more useful than these. I can't think of a single project that would use these, aside from projects people made specifically trying to use them.

So why did I have to demonstrate some codes then?

I mean, back then, there wasn't really a true use for usernames, because only the project can identify it and use it.

That was until cloud variables came.

And you just haven't seen what the purposes might be yet. If it doesn't go out well, fine. If it does, you must understand.

I can actually think of a use for this, lets say there is a game where the villain revels at the end that they were doing things the whole time because they felt as if no one knew who they were, with these blocks the villain could break the 4th wall and realize that they are loved with the ending changing based on how many loves a project gets. However this could be done manually, or it could be done with a cloud variable that counts how many people get up to the climax.

This could also be done on about mes where it says I have # followers and have made # projects.

This is actually a good idea but you would definetly get some scripts like:

say [Love this project to continue!!!!]
wait until <Project Loved>
broadcast [game v]

EliteProgramming wrote:

This is actually a good idea but you would definitely get some scripts like:

say [Love this project to continue!!!!]
wait until <Project Loved>
broadcast [game v]

The block wouldn't actually detect whether a given user loved the project or not - but you could still make something like

set [love detector v] to ((loves) + (1))
say [love this project to proceed!]
wait until <(loves) = (love detector)>
broadcast [startgame v]

No support.

cul8er wrote:

EliteProgramming wrote:

This is actually a good idea but you would definitely get some scripts like:

say [Love this project to continue!!!!]
wait until <Project Loved>
broadcast [game v]

The block wouldn't actually detect whether a given user loved the project or not - but you could still make something like

set [love detector v] to ((loves) + (1))
say [love this project to proceed!]
wait until <(loves) = (love detector)>
broadcast [startgame v]

No support.

I'm assuming the block only loads once (as the project is loading) and doesn't update after it's loaded; otherwise this block would be laggy

^ not really, data could be loaded asynchronously (updated every 30 seconds or so) – just like cloud data, which doesn't pause to fetch a value, it uses the last one it got (especially if it's in fallback mode)

Sheep_maker wrote:

cul8er wrote:

EliteProgramming wrote:

This is actually a good idea but you would definitely get some scripts like:

say [Love this project to continue!!!!]
wait until <Project Loved>
broadcast [game v]

The block wouldn't actually detect whether a given user loved the project or not - but you could still make something like

set [love detector v] to ((loves) + (1))
say [love this project to proceed!]
wait until <(loves) = (love detector)>
broadcast [startgame v]

No support.

I'm assuming the block only loads once (as the project is loading) and doesn't update after it's loaded; otherwise this block would be laggy

Then I suggest using if and forever blocks.