Does addSprite() prevent manual drag movement?

Million Tile Engine
#1

I had a setup whereby I moving a displayObject with drag commands without using MTE’s moveSprite (standard drag Corona code), it was working fine but now I’m not getting anything.

I’ve logged statements on the object’s x and y properties in the touch handler function and these are changing as expected, however the image doesn’t move at all.

I add the image with addSprite() and I know I should use MTE’s move API’s; however I’m baffled why this isn’t working anymore. If I remove the addSprite() statement or don’t run MTE.update() it works as expected, so I’m really confused.

Would adding the displayObject via addSprite negate being able to manipulate the object via Corona’s standard method of shifting x and y values in the touch handler?

I’ve spent all day going back through previous versions and just completely baffled why this isn’t working any longer?

#2

Two questions; Did your drag code work in previous versions of MTE? Is the object a physics object?

#3

Hey Dyson, thanks and always for being so quick…

It’s so weird - it’s something I’ve done but having attempted to go through previous versions my eyes are bleeding :slight_smile:

a - I haven’t changed MTE between it working and not

b - Nope no physics whatsoever.

It’s definitely not an issue with MTE, it’s something I’ve done but I really can’t figure it out - just can’t understand why when I can see the x/y values of the display object changing as expected, the object isn’t actually moving.

#4

MTE manages the raw x/y position of non-physics sprites added to it. The engine calculates the x/y position based on level position and the position of the parent group. If you try to move the sprite, the sprite will snap back to where MTE thinks it should be the next time update() executes. Physics objects work the opposite way around; MTE calculates their level position based on their x/y position, and so you can move them by changing their x/y position.

This is one of those problem that will go away with the MTE rewrite. The new engine code will allow all the normal methods of moving display objects rather than requiring the use of MTE’s movement functions.

#5

Hey Dyson - thanks for confirming what I suspected. The weird thing is I can’t work out what I’ve changed that has allowed this, I guess perhaps I wasn’t running mte.update() or something.

Would there be an easy fix or should I just use moveTo() in my touch handler? Or is there any downsides to not adding sprites to mte? I’m employing a strict object approach to my code, so is there any disadvantage to not registering sprites/images with MTE and handling their logic outside of the engine?

#6

Follow-up question if I may; what would your advice be towards a simgame (think Sim City, Simpson Tapped Out), essentially I want the user to be able to create units and drag the unit to its placement - snapping to the grid?

#7

Ignore that questions - got it working :slight_smile:

#8

Two questions; Did your drag code work in previous versions of MTE? Is the object a physics object?

#9

Hey Dyson, thanks and always for being so quick…

It’s so weird - it’s something I’ve done but having attempted to go through previous versions my eyes are bleeding :slight_smile:

a - I haven’t changed MTE between it working and not

b - Nope no physics whatsoever.

It’s definitely not an issue with MTE, it’s something I’ve done but I really can’t figure it out - just can’t understand why when I can see the x/y values of the display object changing as expected, the object isn’t actually moving.

#10

MTE manages the raw x/y position of non-physics sprites added to it. The engine calculates the x/y position based on level position and the position of the parent group. If you try to move the sprite, the sprite will snap back to where MTE thinks it should be the next time update() executes. Physics objects work the opposite way around; MTE calculates their level position based on their x/y position, and so you can move them by changing their x/y position.

This is one of those problem that will go away with the MTE rewrite. The new engine code will allow all the normal methods of moving display objects rather than requiring the use of MTE’s movement functions.

#11

Hey Dyson - thanks for confirming what I suspected. The weird thing is I can’t work out what I’ve changed that has allowed this, I guess perhaps I wasn’t running mte.update() or something.

Would there be an easy fix or should I just use moveTo() in my touch handler? Or is there any downsides to not adding sprites to mte? I’m employing a strict object approach to my code, so is there any disadvantage to not registering sprites/images with MTE and handling their logic outside of the engine?

#12

Follow-up question if I may; what would your advice be towards a simgame (think Sim City, Simpson Tapped Out), essentially I want the user to be able to create units and drag the unit to its placement - snapping to the grid?

#13

Ignore that questions - got it working :slight_smile: