Constrain X Y of Actor1 to Actor2 ..fails

TheGabfatherTheGabfather Member Posts: 633
edited May 2013 in Working with GS (Mac)
It's my first time trying my hand at a platformer game and I thought I'd make use of a separate Actor for a Weapon. I'm used to creating puzzle games with GS so I'm feeling totally alien right now :)

Just doing some experiments and I've come across a weird behavior where I've Constrained the X and Y coordinates of the Weapon to that of the Character Actor, but at a certain consistent point in the scene the Weapon "flies" ahead of the Character (It goes right back to the Character when I move back).

Using Display Text to print each Actor's X coordinate shows that they should be at the same point -- but they aren't.
image

I've only implemented a couple behaviors so far:
-Basic Collisions
-Moving using Motion.LinearVelocity
-Jumping using Motion.LinearVelocity
-Crouching
-And the X and Y Constraints

Disabling the Jump and Crouch does not remedy the situation, so it has to either be the Rules for Moving / Constraining?

The Rules for those are simple enough -- followed tshirtbooth's tutorial on Moving to the letter, and did self.position.x/y to scene.Background.Hero.position.x/y for Constraining.


Any help/insights would be awesome! Feel free to make me feel stupid if I did a stupid mistake anywhere! I don't mind the education :)

Comments

  • CodeMonkeyCodeMonkey Head Chef, Member, PRO Posts: 1,803
    Are both actors on a scrollable layer or both on a non-scrollable layer?
  • TheGabfatherTheGabfather Member Posts: 633
    @CodeMonkey For some reason, the Weapon Actor was placed in the non-scrollable HUD layer I made for testing. I moved it back to its proper place in the scrollable Background layer and it's working fine now! Thanks a ton :D

    I'm just overly curious about what happened there -- where they were displaying the same X Coordinate even though the one that was on the non-scrollable layer was obviously in a greater position? Bizarre.
  • CodeMonkeyCodeMonkey Head Chef, Member, PRO Posts: 1,803
    The difference is the camera offset because it scrolled over.
  • TheGabfatherTheGabfather Member Posts: 633
  • joshiwujoshiwu Member Posts: 207
    FIrst of all! is there any hard forum to sign into! yall know you have some issues to fix with that don't you! the sign in button disappears when u mouse over, And not just graphicly. Dear codemonkey IDK if gabfather really has resolved his problem but I am having the same problem with tshirts' "throw ana object in IOS" tutorial. it seems that if the camera is scrolled over the item I grab to throw is offset much the same way. BUt I am looking for an actual solution maybe a way to change origin points! bc its making it hard to line my hud up with the camera. since when I made the scene bigger it is lopsided and Ill need to center it. is there a control scene origin?
  • joshiwujoshiwu Member Posts: 207
    The difference is the camera offset because it scrolled over.
    so to be clear mY actor is only offset when my player has moved the camera too far from the origin
  • CodeMonkeyCodeMonkey Head Chef, Member, PRO Posts: 1,803
    I'm afraid I don't have the time to explain the video.

    Hopefully this will help though:

    If you made your scene 10000x10000, it means that in scrollable layers, actors would be able to have positions between 0 and 10000 in either x or y axis. (Ignore that you can actually go outside of that area a little before the actor gets destroyed)
    Your legacy iPhone screen only has 480x320 in coordinates that you can access for the mouse and touch attributes.
    When the camera is all the way at the bottom left, the origin of the camera is 0,0.
    If it is all the way to the top-right of this scene, the origin is (10000-480,10000-320)=
    (9520,9680).
    If you wanted to spawn an actor when you touch the middle of the screen, but when the camera is at the top right, you need to add the camera origin to the mouse position. So in this case, the spawn point would be (9520+480/2,9680+320/2) = (9760,9840)

    You'll need to have an unlocked instance to get to that camera.Origin.X/Y value, but that should probably fix the offset issue.
Sign In or Register to comment.