Drag and drop bug?

MarkOnTheIronMarkOnTheIron Member Posts: 1,447
edited November -1 in Working with GS (Mac)
I was working with firemaplegames Snap to grid example when I got to a point where i get strange behaviors: if my actors are set to movable everything works fine, but if the actor is set to non movable when I release it in a point it continue to follow the mouse pointer even if it isn't pressed (the same behavior happen on the iDevice).

Anyone experienced this?

Comments

  • MarkOnTheIronMarkOnTheIron Member Posts: 1,447
    I tried to trigger an action that set the actor to non movable but even if it release it fine it will remain movable

    When Attribute "DoNotMove" = 0
    Change Attribute "self.Physics.Movable" = false)
  • CodeMonkeyCodeMonkey Head Chef, Member, PRO Posts: 1,803
    The Movable attribute can not be changed during gameplay.
  • MarkOnTheIronMarkOnTheIron Member Posts: 1,447
    Why not?

    Are you planning on correcting this or it won't change?
  • firemaplegamesfiremaplegames Member Posts: 3,211
    It would be nice if it was an easy toggle like that. Visible is similar.

    For now, you just have to wrap it in a Rule and keep a global attribute like you said.

    When game.unableToMove is FALSE
    Pick me up...
  • MarkOnTheIronMarkOnTheIron Member Posts: 1,447
    I managed to keep my actor still by constraining his x and y position but the problem is that it rotate when collide with other actors and if I check Fixed rotation I get an absurd collision.
  • firemaplegamesfiremaplegames Member Posts: 3,211
    you could try constraining the rotation as well...
  • MarkOnTheIronMarkOnTheIron Member Posts: 1,447
    Tried that and I get the same results as with fixed rotation
  • firemaplegamesfiremaplegames Member Posts: 3,211
    Yes, constraining and collisions don't work well together.

    Setting the Density to 0 does the same thing as Movable = false, but alas, it too cannot be changed at runtime.

    In that case I would try an invisible, unmovable actor that handles the collision. and another other one for would be there just for looks. the second one would be constrained to the position of the first.

    I did this in one of my test games and it worked great:
    I had an invisible block that handled collisions and was what the player actually controlled, and I constrained an animated sprite to its position. (I needed the animations to be larger than the collision area.)
  • MarkOnTheIronMarkOnTheIron Member Posts: 1,447
    Yes, that at the moment seems the only solution. Thanks.

    I will try as soon as I can (when I finish changing my more than 300 instances position and orientation for my other game to fit portrait mode)
  • firemaplegamesfiremaplegames Member Posts: 3,211
    I would wait until they fix the bug first! None of my games work in 0.08...
Sign In or Register to comment.