collinhover / impactplusplus

Impact++ is a collection of additions to ImpactJS with full featured physics, dynamic lighting, UI, abilities, and more.
http://collinhover.github.com/impactplusplus
MIT License
276 stars 59 forks source link

moveTo posDraw issue #164

Closed itsOgden closed 10 years ago

itsOgden commented 10 years ago

I am having a very strange case where the moveTo function is moving the entity, but not changing it's posDraw. Here are the details:

Entity Performance: STATIC (if it is set to MOVABLE, this doesn't happen).

When I press the WASD keys, it moves my "reticle" up, down, left, or right on my queue. For 11 of the "slots" the reticle moves as expected. The reticle spawns on slot 11. Once I move from slot 11, with performance set to static, I can move anywhere on the queue EXCEPT position 11. I have testing having the starting position different, and the error is the same just with the new origin being a problem.

By using the debug and turning on collision and draw boxes, I was able to tell that it wasn't changing the draw position. I then confirmed this by logging the pos and posDraw at the same time and seeing them de-syncronize while on slot 11 and then resynchronize on any other.

Any thoughts? I updated the demo so you guys could see it happening. I am guessing this is a bug, but I have no idea really.

collinhover commented 10 years ago

This is the intended behavior. As you noted, if you need an entity to move, set its performance to MOVABLE or DYNAMIC, because STATIC has some optimizations in place for the assumption that the entity never moves.

itsOgden commented 10 years ago

The issue is that it can't move to only its origin. It can move all over the place, just not back to home. That seems like a really odd intended behavior.

The entity never ever moves itself, it is commanded to by functions based on mouse input. Based on the following statements in the tutorial, I assumed they either would be able to move themselves if movable and only move on command if static or they would be only movable if movable and permanently locked in place if static (clearly not the case since I can move it all over the place except home).

"Static entities skip all movement code in the update loop and only update their animations. Movable entities can move in addition to everything static entities do, but they ignore physics forces such as gravity and don't collide with the collision map."

The game gets noticeably faster if my entity is static, so I was really hoping to keep it Static. Am I missing something really obvious that makes it only move the pos and not the draw only in that single case?

collinhover commented 10 years ago

I can see what you mean, not being able to move back to the original location seems like odd behavior. Looking at the entity code, you should be able to call moveTo and have the entity moved correctly even if it is static. What you're saying is using the moveTo method is okay until it is moved back to the original location?

Try this for me, add a call to recordLast just EDIT: after the call to recordChanges on this line: https://github.com/collinhover/impactplusplus/blob/master/lib/plusplus/core/entity.js#L3607

Does that fix the issue?

itsOgden commented 10 years ago

@collinhover Sadly no; adding recordLast didn't seem to make any difference.

itsOgden commented 10 years ago

@collinhover Did you have any other thoughts on this one? Or does it seem like a bug that's going to take a more in-depth look?

collinhover commented 10 years ago

@itsOgden sorry man, I think I know how to fix it, but I just haven't had time to look into it.

collinhover commented 10 years ago

@itsOgden can you test with latest dev please? Also when you use the moveTo method on your entity, is it a single instant move or a tweened move?

itsOgden commented 10 years ago

I've been using a single instant move, and it does appear that it fixed the issue! Woohoo!

I actually have no idea how to use a tween move. Should I give that a try?

collinhover commented 10 years ago

If you tween move an entity, it forces the entity's performance to shift up to movable, so in your case you may not want to. Check out the comments/docs on the entity moveTo method for all the options related to tweening the movement. Glad this is fixed.