- When I create one sprite in Design mode, I see two sprites in the working app.
What is my mistake?
- When I try to reflect a sprite at the edges without activating bounce (!) but by calculating the new angle of movement, it does not work
Hi there, @approeduc.
I couldnāt solve your second question about the block structure of canvas.
The ātwo spritesā,I can tell you that is originally and this is no mistake you did.This is default setup by the developer.
OK,
but what do I do, if I only want one sprite?
I think it is impossible to do it with one sprite.
The block ācreate spriteā is one too much. Without this there is only the one sprite designed in design mode.
But changing the direction is confusing.
What is the difference between the block categories āmotionā and ādirectionā.
For me I would think that changing the angle in the motion blocks would solve the problem. But they do not.??
You just use the wrong block to determine the angle. Use this to get the angle.
Thank you actech,
but there are still problems:
You cannot determine the angle with this block between the ball sprite and the edge of the canvas.
And if you change the angle of the sprite (e.g. as a test with a number) then the motion of the sprite-movement does not change - the orientation of the sprite changes. This does not solve my problem to change the direction of the movement after colliding with the edge of the canvas.
It is necessary to use sprites instead of the edges of the canvas. To do this, create 4 sprites in the form of rectangles that will replace the edges of the canvas. Is such a solution suitable for you?
When you create a sprite in design mode, you should only see one sprite in the working app. In the tree, it shows you the type of sprite, in case you want to make more than one sprite of that type (ie you want multiple enemies in your game that all behave the same way). If you see two separate sprites in the app, but only added one, send me a link and Iāll take a look.
Setting the angle (both in the direction drawer and the motion drawer) sets the direction that the sprite is pointing (not moving).
With the blocks that exist now, you can point a sprite in a direction and move it in that direction to simulate a bouncing effect: https://x.thunkable.com/copy/17af106c6ab74e175603e17903ff43f9
For now, Iād recommend using the bounce property: https://x.thunkable.com/copy/8bdccb28365fd3ca654531788949c224
Eventually weāll give you blocks that allow you to know the angle you are moving at, and the ability to set the speed at a particular angle, but we havenāt released those yet.
If you want multiple sprites that behave the same way, you can make them part of the same sprite type and they will share properties and code. In the example below, all of the sprites are in SpriteType1 and they all have a bounce of 100. Also when any of them hit any edge their angle changes by 10.
https://x.thunkable.com/copy/6e7c3e612f7ee7e162c52c88236f940a
Thank you!
This answer explains the problems, I ran into.
So simplifying I understand:
We cannot determine the direction a sprite is moving and we cannot change the direction of the movement via programming an angle.
We cannot determine the direction a sprite is moving and we cannot change the direction of the movement via programming an angle.
For now, yes. There is probably fancy trigonometry you could do to calculate the arctan2 from the x and y speed to find the moving angle, and to set the speed, but Iād just wait until we get the blocks released
Ok, this is what changing the angle does:
https://x.thunkable.com/copy/28a653620ac7b77425ddb61515a185b5
An example of obtaining the angle of movement of a sprite.
https://x.thunkable.com/projects/5d78020ff0a03f3f9502e551/project/properties/designer/
Clever
Just delete the object called āballā below the āSprite_Type1ā. This is an individual sprite, drawn on the stage, but it is in the sprite group āSprite_Type1ā. You can place new sprites of type āSprite_Type1ā onto the stage by dragging them from the bottom drawer on the left. This is useful to test out the placing of a sprite in the group, or the size of the sprites in the sprite group.
Your create blocks create an individual sprite programmatically. That is the way to go to keep track of the sprites in Your app. The sprite You create can then be reached via the green component block. The block where You show āballā can be omitted.
In the collide block, You should change āballā to āspriteā, by dragging the green block into the places where āballā is in the set angle block.
Particle movement in thunkable, for those interested. The particles however, slow down over time, and stop. I think this happens because of rounding errors as the collitions commence.