Buggy sendSpriteTo in 0v918b

Million Tile Engine
#1

Hi sendSpriteTo appears to be buggy in 0v918b in that it is not sending sprites to the correct location when called, this used to work in 0v872.

the failing call:

mte.sendSpriteTo({sprite=sprite,levelPosX =startx ,levelPosY=starty})

I have managed to work around this by using moveSpriteTo instead? see:

mte.moveSpriteTo({sprite=sprite,levelPosX =startx ,levelPosY=starty})

I assume that move sprite to is doing something prior to calling sendSpriteTo (due to time == nil or < 1)?

could this be due to:

toggle1 var being present in moveSpriteTo call to sendSpriteTo?

moveSpriteTo using sendSpriteTo vs sendSpriteToExt in external api?

Best,

S

#2

A cursory check shows sendSpriteTo to be working on my end.

Are the sprites physics objects? What are the values in startX, startY? What is the current position of the sprite? Is sendSpriteTo moving them at all, and if it is, how far off from the correct position are they? Are you sending them out of the map, or across the wrap if worldWrap is enabled? In order to fix problems I must replicate them, and in order to replicate problems I need as much information as possible. 

#3

Hi dyson some more info.

camera is not at default location it is centered in a map, and scrolled down to the bottom of the map at least 4 screen heights.

The objects are indeed physics objects

the objects are being moved just to not where they should be (this may be a physics capping issue again, it looks that way as it looks like the object is moving some ways toward its intended location. Is the physics capping  fix present in sendspriteto?)

world wrap is not enabled

constrainToMap=false,
park=false,

the move is NOT the result of a physics  collision

#4

Hmm… well, it can’t be caused by toggle1, which is only set when worldWrap is enabled.

What triggers the sendSpriteTo command, and is it running before or after update() executes for that frame?

I’ll keep looking into it on my end, but as a shot in the dark, have you tried commenting out the “if object.bodyType then” block of sendSpriteToExt? That is the only obvious change between 0v872 and 0v918.

#5

good shootin tex!

it looks as though these lines of sendSpriteToExt are the culprit :

if object.bodyType then &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;object.x = object.sX + displayGroupData[object.layer].sX &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;object.y = object.sY + displayGroupData[object.layer].sY &nbsp;end &nbsp;

after commenting above out i am no longer presented with the  bug

#6

Huzzah!.. of course, I put those lines there for a reason, so now my job is to find out what commenting them out is going to break.

It would help me a lot if you could send me a representative example of the problem, when you have the time. In all my tests, commending out those lines prevents sendSpriteTo from moving a physics object at all.

#7

A cursory check shows sendSpriteTo to be working on my end.

Are the sprites physics objects? What are the values in startX, startY? What is the current position of the sprite? Is sendSpriteTo moving them at all, and if it is, how far off from the correct position are they? Are you sending them out of the map, or across the wrap if worldWrap is enabled? In order to fix problems I must replicate them, and in order to replicate problems I need as much information as possible. 

#8

Hi dyson some more info.

camera is not at default location it is centered in a map, and scrolled down to the bottom of the map at least 4 screen heights.

The objects are indeed physics objects

the objects are being moved just to not where they should be (this may be a physics capping issue again, it looks that way as it looks like the object is moving some ways toward its intended location. Is the physics capping  fix present in sendspriteto?)

world wrap is not enabled

constrainToMap=false,
park=false,

the move is NOT the result of a physics  collision

#9

Hmm… well, it can’t be caused by toggle1, which is only set when worldWrap is enabled.

What triggers the sendSpriteTo command, and is it running before or after update() executes for that frame?

I’ll keep looking into it on my end, but as a shot in the dark, have you tried commenting out the “if object.bodyType then” block of sendSpriteToExt? That is the only obvious change between 0v872 and 0v918.

#10

good shootin tex!

it looks as though these lines of sendSpriteToExt are the culprit :

if object.bodyType then &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;object.x = object.sX + displayGroupData[object.layer].sX &nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;object.y = object.sY + displayGroupData[object.layer].sY &nbsp;end &nbsp;

after commenting above out i am no longer presented with the  bug

#11

Huzzah!.. of course, I put those lines there for a reason, so now my job is to find out what commenting them out is going to break.

It would help me a lot if you could send me a representative example of the problem, when you have the time. In all my tests, commending out those lines prevents sendSpriteTo from moving a physics object at all.