You don't need to divide anything. Just multiply the x velocity by -1 when it hits a vertical wall, and multiply the y velocity by -1 when it hits a horizontal wall.
You should start with making move at all first. Have a loop that runs forever with a 0.0 wait in it. In this loop, move the unit instantly by 0,1. This will get you started. When you get this to work, you should be able to figure out how to make it random.
Is this possible? I can easily do so with triggers and regions. But is it possible to use search effects to check collision, and apply an effect which causes the projectile to reflect at the desired angle using only data?
If not with only data, is it possible to use the search effect to check collision, and apply a dummer effect. And then use a trigger that runs off of this dummy effect to modify the direction the projectile is moving?
Is there any way to do this and still have the projectile's mover object do its moving and only using triggers to change its direction?
I don't think it's a good idea to force settings on a user no matter what the circumstance.
Working within the constraints of hardware is part of design. Normally, the graphics are tailored around the gameplay and the expectations of how much will be running. Since the graphics are already made for this game, you can't do that here unless you make your own models.
You're going to have to tailor your design slightly to the graphics.
This mindset is stupid. It's insulting enough that WoW looks like crap because they want as many players as possible to play it.
Some people aren't poor and can afford good computers. It's sad when people like you cater to the masses. If a person can't run it on highest settings, they can turn them down themselves. Don't cripple the game for everyone.
I would write a guide, but I'm not sure what I have to say for it to be understandable. I know this stuff because I've taken 2 years of physics courses and read many books on this subject.
If you could ask specific questions instead of say you don't know how to do it, I might be able to help more.
Hitting the wall does not matter which angle. If you hit a wall like this:
_
The x velocity will not change. When an object strikes another object, the object pushes back on the striking object perpendicular to itself.
Try dropping a ball on the ground straight down. Notice it will bounce right back up directly. Now try dropping a ball on the ground, but with a slight forward speed. Notice how it still bounces up the same way. As well, notice how after hitting the ground, although it's bouncing upwards now, the forward speed and direction have not changed at all.
As for hitting the right side of the pheonix, try this:
Get two balls. Place one still on a table. Roll another ball of the same size directly head on with the still ball. Notice how the still ball begins moving at the same speed and direction as the original rolling ball. As well, you will observe that the previously rolling ball comes to a complete stop.
Now, roll the ball into a rectangular box, and hold the box still. It will bounce off the box the same as a wall.
Now, roll the ball again into the box, but move the box slowly towards the ball as the ball is rolling. It will again bounce off the same way, but the ball will move faster in the new direction. The momentum of the box is transferred to the ball when it collides. Since you are holding the box, it's unlikely its momentum will change, so you can just add the speed of the box directly to the ball's new speed.
The angle of the ball does not matter. Only its position and cartesian velocity.
Look at this:
l <-
The arrow is pointing in the negative x direction. When it strikes the wall, it should directly bounce back. It will then be pointing in the positive x direction.
This is true no matter what the y velocity is when striking a vertical wall. Just keep a variable "x velocity" and "y velocity". Use "move unit instantly" to "point with offset". Have the point be the unit's current location, and the offset be the x and y velocity.
"Bounce of the balls". Is that a typo, or do you want the ball to bounce off multiple balls as well as the walls? If so, I've done it before, and could try to help you, but it is a bit more complicated, and probably really annoying to do with triggers without inline operators.
The first thing that comes to mind for me with bouncing is: If your field is vertical (moving from one paddle to the next results in a change in y direction), just negate the y velocity when it collides with a paddle. When it collides with a left or right wall, just negate the x velocity.
For moving the projectile, have a trigger with a loop that has a wait of 0.0 seconds, and have the action in the loop be to move the projectile ahead by the velocity you store. You could store the velocity in a variable, or as the custom value for the projectile unit.
Does this help?
I'm still curious as to whether it's possible to cause a unit to bounce in data. Or to at least use a trigger to bounce a unit that is being moved by a mover, not via the trigger.
0
@DarlD: Go
You don't need to divide anything. Just multiply the x velocity by -1 when it hits a vertical wall, and multiply the y velocity by -1 when it hits a horizontal wall.
0
@DarlD: Go
The square root of 2 divided by 2.
It's 0.7071067811865475244008443621048490392848359376884740365883
0
@DarlD: Go
You don't need to do that. Try this.
Make a variable called 'xVelocity' and set it to the sqrt(2)/2. Make a variable called 'yVelocity' and set it to the sqrt(2)/2.
Set the offset point to be (xVelocity, yVelocity)
Now, when it hits a vertical wall, do "set xVelocity = xVelocity * -1"
When it hits a horizontal wall, do "set yVelocity = yVelocity* -1"
sqrt(2)/2 is just an example. This will work for any starting velocity. You can have it start with random x and y velocities.
0
@DarlD: Go
You're not supposed to move it TO 0,1. You're supposed to move it to "point with offest"
Move it to to "position of ball" with "offest point(0,1)"
Doing so will move it to the ball's original position plus a y offset of 1.
Though, that might be really fast. You should probably change it to an offset of .25 to start with just to make sure you don't miss it.
0
@DarlD: Go
You should start with making move at all first. Have a loop that runs forever with a 0.0 wait in it. In this loop, move the unit instantly by 0,1. This will get you started. When you get this to work, you should be able to figure out how to make it random.
0
Is this possible? I can easily do so with triggers and regions. But is it possible to use search effects to check collision, and apply an effect which causes the projectile to reflect at the desired angle using only data?
If not with only data, is it possible to use the search effect to check collision, and apply a dummer effect. And then use a trigger that runs off of this dummy effect to modify the direction the projectile is moving?
Is there any way to do this and still have the projectile's mover object do its moving and only using triggers to change its direction?
0
@DarlD: Go
Could you please ask specific questions where you are stuck?
0
@Uberfuchs: Go
Where did you attach the picture?
One thing: I don't think there is a technical solution. The only solutions are altering your design or making your own models.
Taco: don't get me started on rooms you can see but can't go into.
0
@TacoManStan: Go
I don't think it's a good idea to force settings on a user no matter what the circumstance.
Working within the constraints of hardware is part of design. Normally, the graphics are tailored around the gameplay and the expectations of how much will be running. Since the graphics are already made for this game, you can't do that here unless you make your own models.
You're going to have to tailor your design slightly to the graphics.
0
@TacoManStan: Go
You only need the angle if you're using polar coordinates. I find x,y coordinates to be much simpler.
I don't think pong has gravity nor wind resistance.
0
This mindset is stupid. It's insulting enough that WoW looks like crap because they want as many players as possible to play it.
Some people aren't poor and can afford good computers. It's sad when people like you cater to the masses. If a person can't run it on highest settings, they can turn them down themselves. Don't cripple the game for everyone.
0
I would write a guide, but I'm not sure what I have to say for it to be understandable. I know this stuff because I've taken 2 years of physics courses and read many books on this subject.
If you could ask specific questions instead of say you don't know how to do it, I might be able to help more.
0
@DarlD: Go
Hitting the wall does not matter which angle. If you hit a wall like this:
_
The x velocity will not change. When an object strikes another object, the object pushes back on the striking object perpendicular to itself.
Try dropping a ball on the ground straight down. Notice it will bounce right back up directly. Now try dropping a ball on the ground, but with a slight forward speed. Notice how it still bounces up the same way. As well, notice how after hitting the ground, although it's bouncing upwards now, the forward speed and direction have not changed at all.
As for hitting the right side of the pheonix, try this:
Get two balls. Place one still on a table. Roll another ball of the same size directly head on with the still ball. Notice how the still ball begins moving at the same speed and direction as the original rolling ball. As well, you will observe that the previously rolling ball comes to a complete stop.
Now, roll the ball into a rectangular box, and hold the box still. It will bounce off the box the same as a wall.
Now, roll the ball again into the box, but move the box slowly towards the ball as the ball is rolling. It will again bounce off the same way, but the ball will move faster in the new direction. The momentum of the box is transferred to the ball when it collides. Since you are holding the box, it's unlikely its momentum will change, so you can just add the speed of the box directly to the ball's new speed.
0
@DarlD: Go
The angle of the ball does not matter. Only its position and cartesian velocity.
Look at this:
l <-
The arrow is pointing in the negative x direction. When it strikes the wall, it should directly bounce back. It will then be pointing in the positive x direction.
This is true no matter what the y velocity is when striking a vertical wall. Just keep a variable "x velocity" and "y velocity". Use "move unit instantly" to "point with offset". Have the point be the unit's current location, and the offset be the x and y velocity.
"Bounce of the balls". Is that a typo, or do you want the ball to bounce off multiple balls as well as the walls? If so, I've done it before, and could try to help you, but it is a bit more complicated, and probably really annoying to do with triggers without inline operators.
0
@DarlD: Go
The first thing that comes to mind for me with bouncing is: If your field is vertical (moving from one paddle to the next results in a change in y direction), just negate the y velocity when it collides with a paddle. When it collides with a left or right wall, just negate the x velocity.
For moving the projectile, have a trigger with a loop that has a wait of 0.0 seconds, and have the action in the loop be to move the projectile ahead by the velocity you store. You could store the velocity in a variable, or as the custom value for the projectile unit.
Does this help?
I'm still curious as to whether it's possible to cause a unit to bounce in data. Or to at least use a trigger to bounce a unit that is being moved by a mover, not via the trigger.