Nested sprites rotation problem

I’ve made the Alonzo (anchor) plus nested arm (part) program as described in page 10 of the manual. Alonzo waves his nested arm alright but there is a problem when he hits the edge

nested_alonzo_arm by bravo1984 - Snap! Build Your Own Blocks (berkeley.edu)

The problem:

  1. if I let both alonzo and the arm rotate then alonzo turns upside down

  2. If I set both alonzo and the arm to only face left right then the arm doesn't wave

  3. If I set alonzo to only face left right and the arm to rotate then the arm goes to the wrong position when travelling right to left. The shared project is in this mode.

I’ve left the project in flat design because it’s easier to see the rotation options that way.

  1. Totally expected - standard sprite behaviour when edge bouncing

  2. As expected - arm can't wave if it not able to rotate

  3. I'm assuming this is the one that you want to actually look OK? :slight_smile:

If so try this out

Basically arm sprite checks the direction of alonzo sprite and alters its own direction and flips it's costume vertically
image

FYI When someone else opens your projects - it opens up in their editing mode not yours
[edit2 -slightly simpler]
A visually better method is to leave arm sprite script alone and alter the alonzo sprite

image

This alters the direction and flip state of the arm sprite when alozo sprite turns around and avoids the slight lag the previous method has but is a bit more complex

That's a fine workaround, but if the normal behavior is wrong we should fix it. I agree that it's only situation 3 that's wrong.

I'm not sure that the current behaviour is actually wrong, its just not what's wanted in this case.

I can easily imagine other scenarios where a user wouldnt want an attached sprite to change itrs direction/costume look.

But like you say,maybe this should be default behaviour if main sprite is in left right mode.

I'll have a bit more play around with different scenarios

One thing I'm noticing is that quite often, the arm shifts it anchor point while I'm trying things out and I have to stop everything, detach and re-attach it back in the right place

[edit] I've found that this happens if make Alonzo go in a non-90 direction - the anchor point seems to shift.

If I return the direction to 90, it returns to original position

well yeah

Thanks cymplecy for showing how it can be made to work. The coding would become more complex if alonzo was to move in any direction.

What I'm really looking for is an introductory example to sprite nesting which is simpler than Swimmer, in Examples, and doesn't require workarounds.

I think teachers need simple examples to introduce sprite nesting to young students.

The classic example of nested (IIRC) is to have a Fairground Wheel with attached buckets and make the wheel go round but keep the buckets horizontal

Very simple to program :slight_smile:

image

Also just make a sprites eyes blink or mouth operate as it moves around

Or car wheels spin as car body moves along. I actually remember getting pupils doing that in Scratch back in the day - much easier with attached sprites in Snap! :slight_smile:

Your idea just wasn't suitable for a beginner I'm afraid

Simplest I've come up with is this - rename arm costume to arm1 - duplicate it and flip it vertically in the editor

image

Then add these little extra scripts to each sprite

image

image

Is the arm's rotation center set to the point around which it should rotate? When I get this sort of problem it usually means that the rotation is working just fine, but around the wrong point.

Thanks for those suggestions cymplecy.

I did the ferris wheel. The only coding required was to rotate the wheel. The carriages can be put into dangle mode.
Snap! ferris_wheel (berkeley.edu)

I think so but I've spent too long trying stuff out so I'm giving up on it now :slight_smile:

I did the car spinning wheels example suggested by cymplecy.

Initially, when it turned at the wall the wheels shifted position. Then I altered the pivot point of the car to be horizontal (and half way between the wheels) with the pivot point of the wheels, at their centre. This solved the problem.

I also reset the spin direction of the wheels to correlate with the car direction. It also works fine if you change the size of the car.
Snap! car_spin_wheels (berkeley.edu)
I think this sentence in the manual, p. 10, is incorrect, "The precise place where you let go of the mouse button will be the attachment point of the part on the anchor."
What worked for me was placing the wheel part in the correct position on the car before dragging that wheel from the sprite corral onto the car.

Oh, good catch, thank you!

Nice work :slight_smile:

FYI There is an alternative way of accessing another sprites direction using the options in the costume of block
image

I think it's easier to understand for beginners and avoids grey rings

Thanks cymplecy for direction of car hint, I've made that change.

You can use an offset attach
It is even more complicated in js because u have to implement darn rotation urself which i often get sin for the x axis and wonder about the inverted rotation

Why on earth would anyone consider solving an animation problem like this in JS, when they have Snap! available?/

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.