Already in various programming languages as i
Working principe
1.when forever, repeat or repeat until block is started, it reset to 0
2.when the script inside them ends and the block loops, it increase by 1
3.you will only able to put this reporter to the block mentioned above and local to the block. Which means if you have 2 loops running, the counter won’t be messed up
Mock-up using scratchblocks

(loop increment :: control)

or

(times looped :: control)

There is a workaround by using a variable but just like the change block, it is common enough that it deserves it own reporter block

That exists through hacked blocks, you can backpack it from here (look at the “Historical” sprite).

Bump

Duplicate.

k7e wrote:

Duplicate.

That’s a manual counter, I want an integrated counter within loops that increase when it loops.
Like this example

define split (word) at blank
repeat (1000)
if <(letter (loop increment :: control) of (word)) = [ ]> then
add (var) to [list v] 
set [var v] to [0]
else
set [var v] to (join (var) (letter (loop increment :: control) of (word))
end
end

There is workaround of these blocks, but they are used frequent enough to add them in

define split (word) at blank
set [loop increment replacement v] to [0]
repeat (1000)
if <(letter (loop increment replacement) of (word)) = [ ]> then
add (var) to [list v] 
set [var v] to [0]
else
set [var v] to (join (var) (letter (loop increment replacement) of (word))
end
change [loop increment replacement v] by (1)
end
<[] = []>

Bump

Bump

Support, I don't like using variables as a workaround, this new block would save me time!

But there might be a problem, what if you put a loop inside a loop? which loop would it detect?

when green flag clicked
repeat until <(x position) = [40]>
repeat (3)
move (loop increment::control) steps
end
end

qwerty_wasd_gone wrote:

Support, I don't like using variables as a workaround, this new block would save me time!

But there might be a problem, what if you put a loop inside a loop? which loop would it detect?

when green flag clicked
repeat until <(x position) = [40]>
repeat (3)
move (loop increment::control) steps
end
end

Great question, looking for various Python document, seems like inside is more intuitive

TerryLeeStudio wrote:

qwerty_wasd_gone wrote:

Support, I don't like using variables as a workaround, this new block would save me time!

But there might be a problem, what if you put a loop inside a loop? which loop would it detect?

when green flag clicked
repeat until <(x position) = [40]>
repeat (3)
move (loop increment::control) steps
end
end

Great question, looking for various Python document, seems like inside is more intuitive

what do you mean by inside?

qwerty_wasd_gone wrote:

TerryLeeStudio wrote:

qwerty_wasd_gone wrote:

Support, I don't like using variables as a workaround, this new block would save me time!

But there might be a problem, what if you put a loop inside a loop? which loop would it detect?

when green flag clicked
repeat until <(x position) = [40]>
repeat (3)
move (loop increment::control) steps
end
end

Great question, looking for various Python document, seems like inside is more intuitive

what do you mean by inside?

I mean it will move 0, 1, 2, 0, 1, 2 steps etc.

TerryLeeStudio wrote:

qwerty_wasd_gone wrote:

TerryLeeStudio wrote:

qwerty_wasd_gone wrote:

Support, I don't like using variables as a workaround, this new block would save me time!

But there might be a problem, what if you put a loop inside a loop? which loop would it detect?

when green flag clicked
repeat until <(x position) = [40]>
repeat (3)
move (loop increment::control) steps
end
end

Great question, looking for various Python document, seems like inside is more intuitive

what do you mean by inside?

I mean it will move 0, 1, 2, 0, 1, 2 steps etc.

ok

Bump

Bump

Bump

I cease to understand what's so difficult about implementing your own indexes, it's just setting the initial and how much it increments with two blocks of code and an index variable.

However, many other people and I use indexes extremely often, so it wouldn't necessarily be a waste of yet another “not used so often” reporter.

Bump

Bump

Bump

like the 6502 asm right? then you can just make a variable.