Move method stuttering when MoveXY does not


#1

On the multiplayer treasure trove level. If i use the old moveXY method (finding nearest item, move to items pos.x pos.y.) it works fine. If i swap in move({x: pos.x, y: pos.y}); it just stutters nonstop. moving very very slowly…

anybody know whats going on? the line it’s on is the move line when its stuttering


Mine Sweep Bug with Jumping Boots
#2

Ah, I need to fix a bug with movement where it pauses in between movement frames, which makes it stutter and go slowly. Hope to get it soon!


#3

Thanks. i’m stuck using the last pair of MoveXY boots you can buy because the faster boots are actually in practice much much slower due to the stuttering.


#4

moveXY

  • Player moves towards the target. The moment he reaches, the position the parser will jump to the next line.

move

  • Player moves towards the target. The moment the action is triggered, the parser will jump to the next line.

This behavior influences both, single- and multiplayer levels. In the worst case your character will just stutter at the same place, because of a changing objects next to him.

Any progress in your work?


#5

Sorry, it’s on me and i’m really behind, but hopefully I can focus on fixes like this and introducing more of the higher-tier items if we get this Chief Artisan hiring gig complete!


#6

Please, correct me if I’m wrong since I still can’t test move: will it work as a lerp?

I know the moveXY won’t. It basically freezes the loop, which is actually a very bad thing.

If not, what is the difference then?


#7

Move will move part of the way toward the coords specified. It won’t lock the loop as much.


Errors due to equipment comands when going on older levels
#8

Oh, so I really need it! I was trying to implement a lerp without def and without generators. Quite complicated. Too bad it needs at least level 37… :frowning:

Do you need boots that fast even with the amazing ring?


#9

I have moved this post from another thread

In python, the following code makes you move reasonably smoothly using moveXY. It makes you move towards a green flag, but you do not have to move all the way, which is the intended benefit of having move instead of moveXY. Note that the code uses removeFlag, for which you have to buy a flag shaped item.

#this means green flag close distance
gFCDist = 5

loop:
    sPos = self.pos
    sX = sPos.x
    sY = sPos.y
    greenFlag = self.findFlag("green")

    if greenFlag :
        gFPos = greenFlag.pos
        gFDist = self.distanceTo(greenFlag)
        gFDiffX = gFPos.x - sX
        gFDiffY = gFPos.y - sY
        div = 2
        
        if gFDist > 30:
            div =  10
        elif gFDist > 15 :
            div =  5
        elif gFDist <= gFCDist :
            self.removeFlag(greenFlag)
            
        gFTX = sX + gFDiffX / div
        gFTY = sY + gFDiffY / div
            
        self.moveXY(gFTX, gFTY)
    #this is just so that there is no infinite loop. Really we should use self.wait
    else:
        self.moveXY(sX, sY)
        #self.wait()

Bonus

  • you can solve the level keeping-time using only this code.

  • the green flag gets removed if you are close to it, so that it is easier to remove the green flag from the battlefield.

Remark

The code will not give your character an instruction if the green flag is too close. This should really be handled differently, but the code would more complex/longer.

Related

The issue on github


#10

Does it work well? I tried a similar thing previously using a distance of 5 and it really destroyed the simulation and locked up the browser very quickly (and movement was super choppy)


#11

Just try it out I guess :). I did test it before posting, though I made at least one minuscule edit. Just backup your code for some level and paste this and run it. Come to think of it there should be a much more elegant smooth way of doing this by the way (with less if and elif).


#12

Sorry, I don’t understand what that got to do with the subject?

This thread is about the different behaviour of two methods which should work the same way - not the usage.

It’s out of the question that moveXY(pos.x, pos.y) runs well ^^


#13

I just figured especially beginning players/coders may want to see an example of how to move like this. I felt this might help players use strategies that would ideally use move.


#14

The strategies are exactly the same as moveXY the only difference is your code is more responsive and you wont get stuck unable to respond to enemies as you walk to the point


#15

There are actually some interesting advanced strategies you can do when you can change your movement pattern every frame, but I won’t give them all away… :wink:


#16

Yay, the bug has been fixed.