Can Move Block From BJC Snap! Cheat Sheet, Section Robot

[warped_wart_wars]

BJC Snap! Cheat Sheet, Section Robot

@BJC Snap! Cheat Sheet Section Robot

CAN_MOVE (direction)

In Snap!, there are several ways to detect what is around the sprite, but since there is no robot, there is nothing quite like CAN_MOVE (direction), which returns true or false depending on whether or not the robot can move in that direction without running into a wall or walking off of the maze.

In Snap!, you can use these blocks to help your sprites determine how to move: , , and

I decided to make this block in Snap! here.

[bh]

That's cool -- it'll work for a robot on a grid, where you're only trying to move one square. (Although the grid is likely to be stamped on the pentrails rather than being other sprites.) In general, though, it runs the risk of jumping over another sprite.

[warped_wart_wars]

@bh

In general, though, it runs the risk of jumping over another sprite.

Yes, if you go forward a lot, like 40x40 pixel sprites checking >80 pixels.

[joecooldoo]

Why not use
[scratchblocks]
warp {
repeat (times)
move (1) steps
if <touching [sprite v]> then
set [touched? v] to <<true (:: #ffffff) :: #00ff00> :: operators>
} :: grey
[/scratchblocks]
to fix that?

[warped_wart_wars]

[scratchblocks]can move in direction (90 v) distance (12.5) :: sensing boolean[/scratchblocks] 12.5.

[dardoro]

tells the distance to the nearest costume pixels ahead, in sprite direction, in one go.

[warped_wart_wars]

I think ray length is something like this:

whereas I would need something like this:

[warped_wart_wars]

How about
[scratchblocks]
warp {
repeat (times)
move (1) steps
if <touching [sprite v]> then
set [touched? v] to <<true (:: #ffffff) :: #00ff00> :: operators>
} :: grey
[/scratchblocks]

[scratchblocks]
warp {
repeat (times)
move (1) steps
if <touching [sprite v]> then
set [touched? v] to <<true (:: #</a>ffffff) :: #</a>00ff00> :: operators>
} :: grey
[/scratchblocks]

(Why is the %bool input type so hard to make with scratchblocks?)

[sir_kitten2]

[scratchblocks]<<true (:: #dcdcdc) :: #00ff00> :: operators>[/scratchblocks]

[scratchblocks]<<true (:: #</a>dcdcdc) :: #</a>00ff00> :: operators>[/scratchblocks]

My version.

[warped_wart_wars]

Here's the real thing:

Do you not see that the circle is white, not gray?

[bh]

@warped_wart_wars

Do you not see that the circle is white, not gray?

It actually is a light gray, specifically 0xdcdcdc.

[sir_kitten2]

@bh

0xdcdcdc.

fixed.

[warped_wart_wars]

It still looks a little bit darker in the scratchblocks.

[warped_wart_wars]

It looks white to me, even if the RGB is 0XDCDCDC.

[sir_kitten2]

It's off-white.

[warped_wart_wars]

Even [scratchblocks]:: #cccccc reporter[/scratchblocks]

[scratchblocks]:: #</a>cccccc reporter[/scratchblocks]

looks white to me

[bh]

How colors look (a subject about which I know far too much, although still not enough) depends a lot on the background. Take this Exploratorium exhibit:

The effect is clearer in person than in a photo, but this looks like a uniform light gray with a rope hanging in front of it, until you move the rope:

Now the two colors are very clearly different.

If the dot in the Boolean input block were against a white background instead of a green one, the difference would be more obvious.

[warped_wart_wars]

[scratchblocks] ( :: #dcdcdc) :: #ffffff boolean[/scratchblocks]

[scratchblocks] ( :: #</a>dcdcdc) :: #</a>ffffff boolean[/scratchblocks]

You're right.

[warped_wart_wars]

@bh

In general, though, it runs the risk of jumping over another sprite.

I just realized how to fix this! I used a slightly modified version of

@joecooldoo

Why not use
[scratchblocks]
warp {
repeat (times)
move (1) steps
if <touching [sprite]> then
set [touched v] to <(true :: operators) :: operators>
end
end
}
[/scratchblocks]
to fix that?

Here it is:

[bh]

TOUCHING takes a list as input? Who knew!

You should also save and restore the pen state, and do a PEN UP before the loop.