8to16 wrote:

May I suggest adding the

when (::obsolete) clicked :: events hat

workaround?

when gf clicked
forever
set [timer v] to (timer)
end

when [timer v] > (timer::variables)
...

when @stopSign clicked:: hat events

Spaceandmoon1 wrote:

Small question: Why does my ‘pen down’ block not work? I want my pen to be able to draw.

secretuch wrote:

when @stopSign clicked:: hat events

This is better block

when green flag clicked
forever
reset timer
end

when [timer v] > (0)

...                      //Put what you want to happen when stop is pressed here!

Spaceandmoon1 wrote:

Small question: Why does my ‘pen down’ block not work? I want my pen to be able to draw.

WsDanzel wrote:

Spaceandmoon1 wrote:

Small question: Why does my ‘pen down’ block not work? I want my pen to be able to draw.

I think u should use pen up instead LOL

The_Cool_Scratch_Guy wrote:

There's a workaround for timezone detection.

I'm too lazy to write it all in bbcode but I'll give you the gist of it.
It works because the days since 2000 block is in gmt, the timezone in the uk.
You can manually calculate days since 2000, take the difference, multiply by 24 and round to the nearest quarter. This gives you the gmt timezone, e.g. -5 for us east (or -4 in dst).
You would probably figure out why to round if you thought of it carefully, but as for why to the nearest quarter not nearest half, blame Nepal for having a quarter hour offset from India's timezone.
If you want the exact code for manually calculating days since 2000, you can go to my project Custom Date Countdown and find the my block calculate days since 2000.

define fast-forward (time) seconds of sound
set [pitch v] effect to (500)
wait ((time)/(6)) seconds
set [pitch v] effect to (0)

The_Cool_Scratch_Guy wrote:

A partial workaround for fast-forwarding sounds:

define fast-forward (time) seconds of sound
set [pitch v] effect to (500)
wait ((time)/(6)) seconds
set [pitch v] effect to (0)

It's not a perfect skip, but it goes pretty fast. It works fast enough that it can be used for cloud music syncing long as the track isn't too long.
If you don't want the high pitched sound, you could set the volume effect to -100 at the beginning then back to 0 at the end.

define skip forward (n) secs
if <(n::custom)=(0)> then 
  stop [this script v]
else
  set volume to (0)%
  set [pitch v] effect to (360)
  set [audio end timestamp v] to ((days since 2000) + (((n)/(86400))/([10^ v] of ((9)/(10))::operators)))
  wait until <(days since 2000) > (audio end timestamp)>
  set volume to (100)%
end

jmdzti_0-0 wrote:

//higher pitch available on other mods, like turbowarp, but this iss scratch’s limit.

jmdzti_0-0 wrote:

set [audio end timestamp v] to ((days since 2000) + (((n)/(86400))/([10^ v] of ((300)/(400))::operators)))

jmdzti_0-0 wrote:

set volume to (0)%

Remove sprites fencing:: motion

The_Cool_Scratch_Guy wrote:

The limit is 500, not 360. See this little demonstration project and you will find that 500 is higher pitched than 360, but anything after that is the same.

I wrote:

set [audio end timestamp v] to ((days since 2000) + (((n)/(86400))/([10^ v] of ((300)/(400))::operators)))

secretuch wrote:

Does anyone has an idea for the block

Remove sprites fencing:: motion

?

remove fencing and go to x:(x position) y:(y position) with size: (size) and costume: (costume [name v])

define remove fencing and go to x:(x) y:(y) with size: (size) and costume: (costume)
switch costume to [a blank costume v]
set size to [big number like 99999]
go to x: (x) y: (y)
set size to (size)
switch costume to (costume)

([10^  v] of ((exponent) * ([log v] of (base)::operators)) :: operators)

([10^  v] of ((exponent) * ([log v] of ([abs v] of(base)::operators)) :: operators) :: operators) * (((2)*<((exponent)mod(2))=(1)>)-(1))

The_Cool_Scratch_Guy wrote:

secretuch wrote:

Does anyone has an idea for the block

Remove sprites fencing:: motion

?

Just use the size hack

remove fencing and go to x:(x position) y:(y position) with size: (size) and costume: (costume [name v])

define remove fencing and go to x:(x) y:(y) with size: (size) and costume: (costume)
switch costume to [a blank costume v]
set size to [big number like 99999]
go to x: (x) y: (y)
set size to (size)
switch costume to (costume)

change x by () offscreen:: motion

change y by () offscreen::motion

secretuch wrote:

What about

change x by () offscreen:: motion

and/or

change y by () offscreen::motion

?

jmdzti_0-0 wrote:

so, uh… for the power with the log method, negative bases don’t work like that. For instance, (-5)² is not -25, but rather 25 (you can calculate this manually), opposed to what the output says.

if <(base ::custom-arg) < (0)> then
  set [power v] to ((-1) * (power)) // Whyyyy???
end

jdzti_0-0 wrote:

Also, negative bases in general tend to not work, since raising a negative number to any non-integer will usually result in a complex number, for example, (-2)⁰ˑ¹³ is approximately 1.00429 + 0.434596i (according to Wolfram Alpha), but the script returns -1.094294 (which surprisingly is the negative absolute value of 1.00429 + 0.434596i).

if <<(base ::custom-arg) < (0)> and <not <(exponent ::custom-arg) = (round (exponent ::custom-arg))>>> then
  set [power v] to ((1) / (0)) // I'm assuming this outputs NaN
  stop [this script v]
end

_nix wrote:

jmdzti_0-0 wrote:

so, uh… for the power with the log method, negative bases don’t work like that. For instance, (-5)² is not -25, but rather 25 (you can calculate this manually), opposed to what the output says.

You're right. I really wonder where that came from, since it's literally “accounted for” as though that *is* how they work, even though… it obviously isn't.

if <(base ::custom-arg) < (0)> then
  set [power v] to ((-1) * (power)) // Whyyyy???
end

_nix wrote:

jdzti_0-0 wrote:

Also, negative bases in general tend to not work, since raising a negative number to any non-integer will usually result in a complex number, for example, (-2)⁰ˑ¹³ is approximately 1.00429 + 0.434596i (according to Wolfram Alpha), but the script returns -1.094294 (which surprisingly is the negative absolute value of 1.00429 + 0.434596i).

That makes sense. I wanted to make sure I wasn't missing something obvious so I tried a couple of digital calculators and yeah, (-3) ** 2.2 [etc] just comes up with a NaN or error. However, short of a method to specifically output two values (real and imaginary), I think it's fair to acknowledge this as a shortcoming of the workaround, right?

Maybe we should acknowledge the limitation right in the code by making the workarounds actually output NaN when the result would be imaginary—as opposed to just giving incorrect output!

if <<(base ::custom-arg) < (0)> and <not <(exponent ::custom-arg) = (round (exponent ::custom-arg))>>> then
  set [power v] to ((1) / (0)) // I'm assuming this outputs NaN
  stop [this script v]
end

Let know what you think or would recommend, if you have the chance. It's obviously true that we aren't really adding new workarounds to the guide at this time, but I want to make sure ones we do have all work correctly and as expected!

edits are to get around very angry forum filter

jmdzti_0-0 wrote:

so, uh… for the power with the log method, negative bases don’t work like that. ~snip~

_nix wrote:

~snip~

ispretty wrote:

~snip~