Toodchop wrote:

I can design the block:

set turbo mode to [on v] :: sensing

it wouldn't be sensing.

Toodchop wrote:

Support, it could be useful.

possibly the most unconstructive response ever. might as well just say “support” atp

tagrim123 wrote:

medians wrote:

medians wrote:

Bringing this topic up

You haven’t said anything,
Please don’t forget to say anything when quoting posts

secretuch wrote:

tagrim123 wrote:

medians wrote:

medians wrote:

Bringing this topic up

You haven’t said anything,
Please don’t forget to say anything when quoting posts

I don't think you get the point. We were bringing the topic up

Toodchop wrote:

I can design the block:

set turbo mode to [on v] :: sensing

I feel like it could make more sense in the Control category

set turbo mode to (on v)::control

<is turbo mode (on v)?::control>

Gamer_Logan819 wrote:

i assume rapidly switching turbo mode on and off would be an extremely easy way to crash a browser or device. not tested, just a hypothesis

Fair. There could be a time based debounce where you can't switch it for 2 seconds after the last switch.

bump

I wanted something more constructive to say than bump, so here goes nothing…

I have looked through all the posts, and have come to this general conclusion:

1. Among suggestions incorporated in this topic were an on/off turbo mode block in control and a turbo mode sensor, obviously in sensing.

a. Turbo Mode On/Off Block in Control:

 
turn turbo mode [on v] :: control 
turn turbo mode [off v] :: control 

i. Problems
1. People could do a forever loop with turn on and off inside. This has the potential to break things
2. There is a workaround using My Blocks setting run without screen refresh on
ii. Solutions
1.Adding a 2 second debounce after turbo mode has been turned off or on still allows functionality while stopping people from spamming it
2. In my project, the workaround doesn’t work. And in addition, this doesn’t allow the functionality of having turbo mode on for loading then off for the rest. My project: Image Generator Stage 5
iii. Pros
1. Allows turbo mode to be turned on while loading, and off when not loading
2. Examples of projects that could benefit:
i. Image Generator Stage 5
ii. 2D➔3D Maze Generator
iii. Mario Physics Simulator v 1.2
iv. Orbital Physics Simulator
v. Dynamic String Art
vi. And lots more. Reply with any others I should add to the list.
3. Since there is a workaround for sensing if turbo mode is on or off, which I address in the sensor block section, this can be used in conjunction with the sensor workaround to turn turbo mode off if someone is using it to cheat in a game.
4.This simplifies scratch for new scratchers who have no idea what to do when a really cool game that they want to play asks them to turn on turbo mode. This block would help a lot of kids be able to play and be inspired by the higher-level projects in scratch.
iv. Cons
1. It is another block in scratch. Surprise! No way around this one but it is pretty minor for what the block can accomplish.

b. Turbo Mode On/Off Sensor in Control

<Turbo Mode on? ::sensing>

i. Problems
1. There is a very easy workaround: Turbo Mode Detector
ii. Solutions
1. None. The workaround is easy and not worth adding another block
iii. Pros
1. None
iv. Cons
1.Adds another block with no real benefits

2. The on/off block has real value and use while the sensor does not and the on/off block has had a lot of support. 129 supports (as of 10-4/25), actually. Here is the breakdown for that:

a. Pages 1-10: 7, 6, 7, 6, 9, 10, 14, 5, 6, 5
b. Pages 11-20: 6, 7, 6, 2, 2, 6, 2, 3, 3, 3
c. Pages 21-24: 4, 3, 5, 0
d. 129 total (10-4/25)

3. Please give your thoughts and opinions. I will update this with new feedback.

bump