Using "move to" behavior for orbit?
Tryangle
Member Posts: 37
I understand how to use constraints to orbit an object around a center. But this method causes the object to lose its bounce. I've discovered that it is possible to use the "move to" behavior for orbit and have a bounce, but the problem is that I can't seem to get orbit to work properly using the "move to" function.
Orbiting objects that retain bounce property: any ideas?
Best Answer
-
nickname5862 Posts: 51
Indeed, when using constrain, it will do anything to remain that constrain and will not collide. I have got two methods, similar, that might work, but I am not sure. They both work without "move to" but "move" instead.
I will put a link here:
https://www.dropbox.com/sh/iwrzazdeeedtxxo/AAD2Jju-MxwjPYx5CC0sYLf2a?dl=0(it is "Orbitting" not the other one or ones. Those were or that one is for (an) other example(s).)
And sorry for not putting a "move to" behavior in it. I just have no idea how that might work...
If the link does not work, tell me.
Answers
Yours is a method that works if and only if one wants the orbiting object to change its trajectory once a collision takes place, and the orbiting object still retain the circular path. But nonetheless its useful for such circumstances and I will keep it for use when I do that (which I will!). However I was looking for a means for the object to retain its orbiting path while causing a bounce to another object.
After working on it for the entire day, this is what I came up with. It works perfectly with the one problem that it takes a moment for the object to get into orbit. But once in orbit it works perfectly:
Make attributes:
Set attributes:
Density: 1000
Bounciness: 2
Drag: 1000
Code:
Move to (relative to scene):
for position x: self.controlSpeedcos((game.Time/self.controlTime)self.controlSpeed1%self.controlAngle+self.AngleOffSet)+self.centerX
for position y:
self.controlSpeedsin((game.Time/self.controlTime)self.controlSpeed1%self.controlAngle+self.AngleOffSet)+self.centerY
for speed:
abs(self.Time*(self.controlSpeed2))
The object will not deviate from its trajectory, and what little it does, it corrects itself.
I will add that if one keeps the controlTime divisible to controlSpeed1 by 100, then changing them will cause the object to always take the same time to rotate around the center, so that one can have numerous objects at different distances orbiting around the center at the same speed. So an object at 300 and 3 will orbit around at the same speed as an object at 200 and 2, or 100 and 1.
Actors do collide with constrained objects ?
Example attached.
@ Socks:
Yes, but the white squares do not bounce correctly against that red rectangle. Notice how the white squares often overlap into the red bar and do not bounce away. While a bounce can happen, it is not at all reliable. In my project, an object needs to be moving at a certain speed to enact a bounce. When constraints are used in an orbit, if the object that needs to bounce lacks a certain threshold of velocity, it will simply get pushed, not bounce, despite the speed the rotating object is moving that hits it.
My above code solves the problem, although it is a bit finicky and needs to be consolidated to one or two self.attribute inputs that can handle all the differentials of orbit in a single broad-stroke: distance and speed (that is equal across distance).
Here's another idea, it's a bit rough, but it gives you the basic idea, a guide actor (which would be made invisible) uses Constrain to plot out the path and a second actor that handles the collisions follows the guide actor using Move To.
@Tryangle,
First: Can you please send the project where you put all those attributes and codes in. It is much better to see that way. Only if you want, if this is already answered (by me, yeah!!), you don't have to.
Second: Is this already answered? I know that I have got the best answer, but the many comments posted is confusing me...
@Socks,
First: I said: "Indeed, when using constrain, it will do anything to remain that constrain and will not collide." not Tryangle, but that doesn't matter.
Second, with that I meant that the red block that has been constrained is not affected by collision, not the objects it bounces to.
@nickname5862 Well it was partially answered by you and I figured some stuff out too, which I posted.
@Socks Well mine can be done without the extra object - as long as the density is significantly higher than the objects it collides with enough to knock whatever objects it collides with out of the way. So in my project I set the orbiting objects to a density of 10,000 and the density of objects they collide with to 50 and it works perfect. Drag can be set to preference.
Good for you