I have a script which has three variables and zero, which looks like this:

switch costume to [(join (join (join (foo) (foo)) (foo)) [0]) v]

At one point the first variable will be set to -2, the second variable set to 0, and the third variable set to 2, so with everything joined it should result in
-2020.
However, the script does nothing, and the block just stays highlighted/outlined. I have tried multiple configurations to no avail, and any other combination of variables works fine.

This may also be a bug, but I thought it might be better to put this in “Help With Scripts” first.
Does anyone know what is happening here?

be wary of naming costumes using numbers. leads to all sorts of unforseen problems.

gtoal wrote:

be wary of naming costumes using numbers. leads to all sorts of unforseen problems.

The problem is the join script itself. It works perfectly fine with any other variable combination, but does nothing with -2020. I can't even manually click it. it just remains highlighted and does nothing.

OverlordXeniaux wrote:

I have a script which has three variables and zero, which looks like this:

switch costume to [(join (join (join (foo) (foo)) (foo)) [0]) v]

At one point the first variable will be set to -2, the second variable set to 0, and the third variable set to 2, so with everything joined it should result in
-2020.
However, the script does nothing, and the block just stays highlighted/outlined. I have tried multiple configurations to no avail, and any other combination of variables works fine.

This may also be a bug, but I thought it might be better to put this in “Help With Scripts” first.
Does anyone know what is happening here?

Do this in two steps instead of one. Create an intermediate variable

set [TEMP v] to [bunch of complicated join stuff]
switch costume to [TEMP v]

If I create 3 variables and join them together with a 0 at the end I get -2020 so you're doing something else wrong. Share the project; take note of gtoal's comment as well.

See https://scratch.mit.edu/projects/164621676/

Are you using clones, by any chance?

And do you click and drag any of these clones while playing the project?

And then you clicked stop and the clones disappeared?

And then you clicked the “switch costume” block…?

If so, that will cause the behaviour you describe (i.e. the block remains highlighted after you click it) – the reason being that when you dragged the clone you selected that clone, and scripts you manually run then get applied to that clone. But if you stop the project, the clone no longer exists – but Scratch continues to try to reference that clone when you run a script. In particular, an attempt to switch costume then causes the block to ‘hang’ (since the clone no longer exists).

If this is what you are doing (and it's a bit of a long shot, but it's one way I know of that can cause the behaviour you describe), you should ensure that you deselect the clone before you attempt to switch costume. You can do this by clicking on the original sprite in the sprite panel just below the project screen.

So, I've done some testing, and it seems that I probably should've mentioned that this script was in the backdrop, and not in a sprite.
I moved the scripts to an actual sprite, disabled the backdrop version, and tested it, and it seemed to work fine.
You can test it yourself here (Bokoblins included)

https://scratch.mit.edu/projects/164577348/

As you may be able to tell by the variable names, the script is for a form of movement through different areas, which makes it a little more confusing.
-2020's opposite, 2020, works perfectly fine. Every other location, works perfectly fine. It just simply breaks at -2020. So perhaps backdrops aren't the best for having a location system and I was simply unaware. Or perhaps it's the issue gtoal suggested.

Ah, interesting, yes, looks like a bug in Scratch, in the part that takes a backdrop value that's numerical and turns it into an actual valid backdrop number.

First of all, let me just say that it was mentioned already above that you shouldn't use numerical values for backdrop/costume names – it's bound to cause confusion since Scratch can't read your mind, so it cannot tell if you are referring to the backdrop by number or by name.


Anyway, it looks to me as though Scratch isn't dealing with negative backdrop numbers correctly when its magnitude is greater than the number of backdrops, because it's not doing the modular arithmetic correctly here:
https://github.com/LLK/scratch-flash/blob/develop/src/primitives/LooksPrims.as#L153-L156

Compare with what happens when switching to a costume number:
https://github.com/LLK/scratch-flash/blob/develop/src/scratch/ScratchObj.as#L115-L116
(Note how it does the mod operation first [the %], and *then* checks if the value is negative. –I'd guess that means that in ActionScript, when mod is applied to a negative number it gives a negative return value [unlike the mod operator in Scratch], and so needs the number of costumes adding. in the backdrop code it happens the other way around – adding the number of backdrops *before* it does the % operation, thus meaning that an input value that's *too* negative will still give a negative number even after having the number of backdrops added to it and then the mod operation applied…)

I ran it through the Flash Debugger app, and it causes an exception (in backdropNameAt, as expected), which is why it can lead the script to hang when running in the online player.


Should be a simple fix in Scratch – but when it's fixed your script will still not do what you want, because it'll still be treating -2020 as a backdrop *number* rather than a name, so you should still apply the fix mentioned above (i.e. joining a non-digit to the names).

Hope that helps!


(I've submitted the bug into Scratch's issue tracker: https://github.com/LLK/scratch-flash/issues/1321)