Dale_Mahalko wrote:

I am trying to find a simple and reliable way to determine if a sprite is a clone or not, for beginning programmers working with clones. There is no sensing block that is simply named “Am I a clone?” that reports True or False.

All I can determine so far is that the original sprite will have a name but a clone will not, so apparently it works to check if the length of the sprite's name is greater than zero. Apparently it is not possible set a sprite's name to null, so this should be reliable?

No need use some hack that should be reliable when you could do it gracefully

Basically, in both Scratch and Snap!, clones can have “sprite-local” variables. That just means that each clone (and the original sprite) has its own separate copy of the variable. So you could try something like this:

when green flag clicked
set [I am a clone? v] to <false :: operators>

when I start as a clone
set [I am a clone? v] to <true :: operators>

when I receive [show clone status v]
if (I am a clone?) then
  say [I am a clone!]
else
  say [I am the original sprite.]
end

To make a sprite-local variable, you'll need to click on “for this sprite only” in the variable name popup:



Here's a recent discussion about clones which you might find helpful: https://scratch.mit.edu/discuss/post/2826194/

lb3344 wrote:

but I had some problem with the “trail” left behind by the player characters. Unless it is offset from the player character slightly, the player character registers it as a game over, as the player character is touching the trail.

There are several different ways to deal with this. I don't know anything about Tron; does the player lose when intersecting its trail, as in Snake? If it's a question of hitting a wall or other obstacle, just use a different color for the trail and for the wall, and test for touching the wall color. Another technique is to use sprite nesting (SnapManual.pdf page 9) so that the pen drawing is done by one sprite and the test for touching is a different sprite, but they always move together. I hope that helps.

Dale_Mahalko wrote:

Also it is unclear to me if it is a “good coding practice” to delete clones as a standard script initialization step.

Yes, I generally do that too.

lb3344, your Tron project intrigues me, as this project could also be adapted to the classic “Snake” game. I tried a couple different ways to do your script, but they are all terrible one way or another.

I have tried to optimize this, but Snap! is just ridiculously slow doing some things. I have no idea how to make this run better. Enabling Turbo mode does nothing.

http://snap.berkeley.edu/snapsource/snap.html#present:Username=lhs-dmahalko&ProjectName=Tronn-dmahalko%200.12%20two%20sprites

It seems to work okay with just the one sprite from earlier in the development… I do not know why two sprites seems so much slower.

http://snap.berkeley.edu/snapsource/snap.html#present:Username=lhs-dmahalko&ProjectName=Tronn-dmahalko%200.11b%20-%20do%20not%20step%20on%20yer%20tail
,

Anyway, the trick here is that the pen trail closest to the sprite is a light blue color that is not detected as a collision, and only when the sprite is far enough from its own trail is the trail colored dark blue. So this script is constantly going back and drawing over its previous trail, coloring it dark blue as it moves away.

At a turn, it needs to stop drawing dark blue on the previous trail, until the sprite is far enough from the corner. Then it finally goes back and repaints the trail dark blue.

I am mainly using the very light blue to show you what is going on. In an actual game, if the light blue is only different by a few color values, probably players won't even notice there is a different color right up next to the sprite.

How do you get the direction a sprite is facing? I need the rotation of the sprite in degrees.

Rotation.X and Rotation.Y have unknown output. Set rotation of the default sprite to 90 degrees, and both Rotation.X and Rotation.Y equal zero. ?? Apparently I need to manually initialize the facing direction at script start and use that. I can't just read the sprite's current rotation.

Also how do you store the color for “touching” in a variable? It's rather annoying that you can store most other data in variables, but this is locked to a single color only, which can not be changed within a program.

Dale_Mahalko wrote:

How do you get the direction a sprite is facing? I need the rotation of the sprite in degrees.

Rotation.X and Rotation.Y have unknown output. Set rotation of the default sprite to 90 degrees, and both Rotation.X and Rotation.Y equal zero. ?? Apparently I need to manually initialize the facing direction at script start and use that. I can't just read the sprite's current rotation.

Also how do you store the color for “touching” in a variable? It's rather annoying that you can store most other data in variables, but this is locked to a single color only, which can not be changed within a program.

1. Use the

(direction)

block.
2. I don't think you can.

BookOwl wrote:

2. I don't think you can.

Can’t you do

<touching color (foo) ?>

I don’t think Snap! has first-class colours yet, but perhaps you can pass 32-bit numbers, like in Scratch?m

EDIT: perhaps (call <touching color> with inputs (foo)) ?

blob8108 wrote:

BookOwl wrote:

2. I don't think you can.

Can’t you do

<touching color (foo) ?>

I don’t think Snap! has first-class colours yet, but perhaps you can pass 32-bit numbers, like in Scratch?m

EDIT: perhaps (call <touching color> with inputs (foo)) ?

Nope and nope. Snap! wont let you put a variable in a color slot, and color slots aren't considered to be empty so implicit parameters don't kick in.

Probably the only way then would be to use the javascript block to access the touching colour predicate drecly

Hi Jens !

It's a pleasure to hear of you….after such a long time !
In the meantime I had “simulated” FILL with FOR (rather akward I admit) like in :

http://snap.berkeley.edu/snapsource/snap.html#present:Username=xleroy&ProjectName=fillsqaxl and …fillcirclenew

But later on I've extensively used JSnap add-on to turnaround the FILL issue like in this example :
http://snap.berkeley.edu/snapsource/snap.html#present:Username=xleroy&ProjectName=109-flowers

First class colors: Not in 4.1, but once that's out (the one now in /dev/ modulo bug fixes) colors will come pretty quickly. Colors are already Javascript objects in the implementation, so it's really just getting HSL as the color space for purposes of the PEN SHADE block (to make Joan happy), getting 100 crayons and their ordering pinned down (to make Brian happy), and deciding on a few UI details. (For example, if you have a list of three numbers, are they RGB or HSL? One way to handle that would be two reporters RGB→color and HSL→color, but it'd be nice to be able to drag the list of numbers into the primitive SET PEN COLOR block. I'm thinking maybe we take lists of length 4, whose fourth item is the word RGB or HSL, and if you just have a list of three numbers I guess it defaults to RGB for backward compatibility or whatever. But I just invented that idea right now as I'm typing. We'll want to keep it simple (to make Jens happy).)

There's ages old pre-4.1 discussion on first class colors on Github. The PR I made is still open, I think.

Dale_Mahalko wrote:

Wow the post editing time window on this forum ABSOLUTELY SUCKS. Good lord. How am I supposed to render something as a scratchblock if I can't preview or even edit my scratchblock posting mistakes for more than 1 minute?

There is a preview function, but it is not that obvious. Click on the green checkmark on the toolbar above your editing window and a preview of your post will appear below the editing window.

Hey, speaking of colors (since I know that's always been a fun topic of debate ), Scratch 3.0 is most likely going to be splitting up its “set pen color to (number)” block.

Here's the new palette they have in mind. The “set pen (hue) to (number)” block is going to have a dropdown which lets you select hue, saturation, brightness, or transparency.

Interesting. Are they sticking with 0-100 for those values, or moving to 0-255?

If you do HSL, then H is and S and L should be . Any other thing seems wrong. (Well, I suppose H could be , but that'd be confusing too.)

cycomachead wrote:

If you do HSL, then H is [0, 360] and S and L should be [0, 100]. Any other thing seems wrong. (Well, I suppose H could be [0, 2π], but that'd be confusing too.)

I agree with those values. Except 2pi; Scratch doesn't use radians for its angle system.

cycomachead wrote:

If you do HSL, then H is [0, 360] and S and L should be [0, 100]. Any other thing seems wrong. (Well, I suppose H could be [0, 2π], but that'd be confusing too.)

Michael's post with the missing bracketed numbers.
Edit: Aw, you beat me!

What is the purpose of “X Position” and “Y Position” under Motion, compared to “My Center X” and “My Center Y” under Sensing? These appear to be redundant.

,

Also what does “My Rotation X” and “My Rotation Y” do under Sensing? There is no help provided for the “My ….” block, even though if you right-click it, there is a Help… menu selection.

quote=cycomachead sheesh I didn't see the new page. Only the third person to do that