Position being constrained absolutely (i.e. collision has no affect)

MobileRocketGames

Hey Guys,
I'm customizing the Slingshot Template to suit my needs and I've run into a bit of a snag.
I decided rather than adjusting the code to only allow the slingshot to be pulled within a certain range of its radius (about 135 to 290) I would take the lazy mans path and just section off parts of the radius using squares (think putting two pieces of paper on top of a circle). For some reason, regardless of Collide behaviors, the actor moves through the other objects.
The actor which is being shot does not seem to collide with other objects until the mouse button is released. Its as if its position is being constrained absolutely. You can recreate this issue by opening the template, selecting the wall actor, placing it directly beside the ball actor in the scene and previewing the game. Try dragging the ball across the wall, it goes right through.

This obviously has something to do with the balls position being constrained to ReticuleX and ReticuleY which are a very complicated equation.

Ideally I can get them to collide while still being constrained. Worst case scenario I will need to figure out how to constrain the available radius to a quarter circle shape.

For Reference:
ReticuleX is constrained to =
game.CueX +min(100, magnitude( game.CueX - game.Mouse.Position.X , game.CueY - game.Mouse.Position.Y ))*cos( vectorToAngle( game.Mouse.Position.X - game.CueX , game.Mouse.Position.Y - game.CueY ))

The same for ReticuleY but vice versa. CueX and CueY are constrained to the balls respective position.
From what I can tell ReticuleX is constrained to the x position of the ball + the length of the distance between the ball and the actual mouse or 100, whichever is smaller. Then it gets even more complicated -_-

Bonus points to anyone who can break down that expression into proper english.


Oh Wise and powerful GameSalad Gods, please hear my plea!

MobileRocketGames

Thank you very much for that Tshirtbooth. You seem to be the most active member on the boards!
This does answer the question about whether GS constrains positions absolutely regardless of collision. It seems it doesn't except under certain circumstances.
Unfortunately this is one of those circumstances.

Ive spent two days trying to frankenstein these systems together to get what I need but im not having much success.
What I've done so far is create a new actor and place it on top of the ball actor, then I added your system to that new actor. I created two new game attributes called "newx" and "newy" and I've constrained those attributes to the new actors x and y positions respectively. This has the effect of the actor following the mouse when its pressed and colliding with the other actors I need it to.

From here I've tried two things:
1. Constraining the balls X and Y positions to the newx/newy positions.
2. Constraining the balls x and y velocities to the mouse position.

Using both methods the actor collides as it should, but doesn't constrain to the circular radius.

It seems no matter what I try, I cannot create a system where the ball constrains to its original circular radius and constrains to another actor at the same time. Its one or the other. As I've only been using GS for 4 days, these past two included, I am way out of my depth.

Technically, I can use this and just cordon off the areas I don't want the ball to be pulled to using other actors. But that means using a bunch of transparent boxes to create a sort of arc. That also wont give me a nice smooth circular rotation when the ball/string is pulled back to its max distance.

Is that the best/only way to go about doing this? Am I going to take a performance hit for using a bunch of invisible boxes?

MobileRocketGames

What about this:

Lets say the ball is at 0,0

• The ball accepts input in the -x to -y range only. (this has the effect of the player being able to move the ball only left and down from the starting point.
• The ball uses the magnitude function to calculate the distance between itself and its starting point.
• Using a rule we tell the ball that if the magnitude between it and its starting point is (greater than) whatever the radius is, set to radius distance.

Wouldnt that get me a nice smooth curve?
If that works, then i wouldnt need to worry about collision before it launches.

Something like this seems infinitely easier to accomplish than what I've got so far.
Should I keep working on what I have or scrap it and try to do this?
Is this even a good idea?
If anyone has another solution please feel free to toss it in!
Thanks guys.

RThurman

@MobileRocketGames

Part of the challenge of the slingshot template is that it is based upon CodeMonkey's original pool table template. See the original at: http://gamesalad.com/game/1111

That's where all the strange names like CueX, CueY, ReticuleX, and ReticuleY come from. The ball was originally a cue ball. When you drag it with the mouse, it actually gets hidden (alpha changed to 0). And is replaced by an instance of the pullback actor (which was originally the reticule actor).

If that all sounds like a mess, well that's because it is! Actually that's not fair. Both the pool table template, and the slingshot template are really ingenious. Its just that the attribute names and actor names don't make much sense in the context of a slingshot. And its hard get what is going on.

Did you know that the slingshot template has a hidden "pullback" instance in the "balls" layer. (Sounds kind of salacious!) You can modify the pullback actor in the library all you want, but it won't make a bit of difference on the scene. You need to find the hidden pullback instance (in the scene) and modify it. When you do, you can mess with the distance formula and get it to behave like you want.

For example, if you go to the hidden "pullback" instance in the scene and and add just one rule you can achieve your grid system you described above. It would look like this:

When
--Attribute game.Mouse.Position.X < game.CueX
--Attribute game.Mouse.Position.Y < game.CueY
----Constrain Attribute:game.ReticuleX To: (That long equation you found)
----Constrain Attribute:game.ReticuleY To: (That long equation you found)


And that's it! The ball can now be pulled back in the lower left quadrant like you want, but not anywhere else.

Hope this helps!
RThurman

MobileRocketGames

I had an epiphany.
It came to me while i was constructing the system i suggested to myself in my last post.
Although Collision is not absolute, Constraining is.

It works flawlessly and is actually quite simple. I've drawn a diagram to help anyone else that may be trying to create a launching system limited to a specific range in the future.

• A. This is the start location of the actor that is being launched (Cueball). This actor contains two constrain attribute behaviors that assign its x and y position to game.CueX and game.CueY respectively. The point of this is that you can drag the Cueball around and it will change the starting position of the launcher without modifying anything manually.
• B. This is the radius of the launcher from the slingshot template.
• C. This is the X position stored in game.CueX. In the actor "pullback" add a rule that activates when its self.Position.X is greater than game.CueX+20 and constrain it to the same. The +20 is so the line does not end up in the middle of your actor, for collision purposes this wouldnt be good. Adjust this to suit your range needs.
• D. This is the same as C except in the Y axis and linked to game.CueY.

The result of this is that the actor is constrained to its perfect arc AND a specific range.
to adjust the range you need to add more to the CueX and CueY constraining behaviors.

Using this method, technically the smallest range you can have is a quarter circle (180°-270°) and the largest is three quarters of a circle (90°-0°). I am using just above a quarter circle for my needs. I cant really see any reason you would need to go above a half circle, and if you do, you might as well just not constrain it and use the full circle.

Hope this helps someone.