I am making a concept of a resizable square. I am trying to implement a rotation feature, and I’m practically certain that all my code is right. When you rotate the square, the dots just start bouncing up and down. Why is this happening? https://c.gethopscotch.com/p/zy49hmphy

You don’t need to use that complicated of a sine/cosine code. You can also make the sine value universal and use it in the y position code as well. Just have the sine match up with the sine of the square, and add 45 x the clone number. The number of times you add 45 is depending on the clone.

(I hope I’m right)

Edit: you will have to change the first number (the “100” when you first spawn in the sine code) as the square changes size. That’s pretty much it

I’m not entirely sure what you mean. Do you reckon you could explain it a little more simply?

@MISSION_IMPOSSIBLE

The height and width properties of the square are changing as it’s rotated (they’re changing to reflect the vertical & horizontal dimensions relative to the screen) which is making the dots bounce.

Why are the height and width values changing when it is rotating? That makes no sense. A 200w x 100h square should still be a 200w x 100h square even if it is at a 45˚ angle.

The properties don’t literally mean the height & width of the square. They mean the height & width of a “bounding box” that encompasses the image.

I agree that’s not intuitive, but that just what the properties mean…

Edit:

(The values also include invisible “padding” around the image, so even when the square isn’t rotated, the height & width properties still don’t reflect the actual height & width as displayed on the screen)

Yes, this is just so you can start to get an understanding of what explanations will be added on later

@MISSION_IMPOSSIBLE

Something weird’s occurring that I can’t explain (yet)

What I described above is definitely how the width/height properties were working on your project

The properties don’t literally mean the height & width of the square. They mean the height & width of a “bounding box” that encompasses the image.

However… I went back and looked at my 3D rendering projects and while using the Set Width/Height block, the input values I used matched * your* expectation of how the image’s height/width should work.

I need to do some more testing when I have time later on…

Edit: I see now. The input values to the Set Width/Height block refer to the width/height of the image when at a 0 deg angle (regardless of the current angle of the image)

The Width/Height * properties* reflect maximum horizontal and vertical dimensions (“bounding box” dimensions) of the rotated image

Both include invisible spacing around the native images.

Maybe because it doesn’t match the square size?

I’m not really sure, sorry.

I’m fairly sure I get it, but do you think that you could make a project showcasing the functioning thing? You could remix my project, and then change the bits where I went wrong. I’ll give credit. @ThinBuffalo

Yes, this is very annoying. There should be a setting that differentiates between the two.

@MISSION_IMPOSSIBLE

I’m thinking about making a tutorial to explain the differences… but it’ll be a new project.

Let me work out the trig for how to do what you want, and I’ll post the formulas…

Edit: Ok, since you’ve already created 2 object variables of Width & Height and stored the “square”'s real width & height in these variables, your fix becomes easy.

In the Corner Position & Side Position custom rules, just change the (Square)Width & (Square)Height in the formulas from the object properties (orange background) to the variables you created (yellow background)

Check again. I’d guess that you didn’t change all of the instances.

Yep. That’s a different problem though than the “bouncing”. Let me see if there’s a simple fix…

Ok, so the formulas in Corner Position & Side Position abilities need to be changed up a little.

First off, I defined a new iPad variable “Scale” so I only needed to change it one place. You can do this or just substitute the value for the variable in the formulas below.

In Square’s When Game Starts

Set Scale = 4.38

**Corner Positions**

Consider the upper right Dot. You have the angle offset from the square set to 45deg. That’s fine when it’s actually a square but if the width or height is changed so it’s a rectangle, then the angle is no longer 45. The angle can be calculated using inverse tangent, where Tan(theta)=Opposite/Adjacent

To fix, first change the (self)Angle to 0 for the upper-right Dot and increment the others by 90deg. So counterclockwise; 0, 90, 180, 270

Then the angular part of the formula (the bit *in* the Cos or Sin) is:

(Square)Rotation + arctan[(Square)Height/(Square)Width] + (self)Angle

Also the radius part of the formula (the bit *before* the Cos or Sin) should be calculated using Pythagorean theorem (A^2 + B^2 = C^2):

Sqrt[((Square)Height/Scale)^2 + ((Square)Width/Scale)^2]

Note: the scale value accounts for the transparent space around the image

Note: the scale value is doubled so we don’t have to add an extra divide by 2

*Note: Width & Height are the object variables (yellow), not the object traits (orange)*

**Side Positions**

This has to be split into 2 separate abilities. One for the dots on the midpoint of the width & one for the dots on the midpoint of the height.

The radius part of the formula should be:

(Square)Width/Scale for width midpoints

(Square)Height/Scale for the height midpoints

Note: Same notes as above

The angular part of formula you have is fine as is:

(Square)Rotation + (self)Angle

I saved a draft copy of your project with these edits but rather than remix I’d like you work through the edits yourself. I can publish it later if you’re having trouble.

Oh boy. This may take some time. Thanks, though.