[SOLVED] Can't "move" in Power Points of Cloudrip Mountain

[DoesNotCompute]

I’ve noticed lately that I cannot use the “move” method reliably on Cloudrip Mountain.

I thought I was going crazy, but was able to work around it for a while by using moveXY instead.

But this level makes that workaround untenable, so I need to understand what is going wrong here.

Code snippet:

hero.moveXY(21,5);
hero.move({x: 40, y: 7});

For multiple heroes with multiple pairs of boots the hero moves to 21,5 just fine. Then they turn around and move a few pixels, and that’s it. The code moves on to the next steps (not included), as if the action were complete.

I’ve tried slightly different syntax: for the object literal:

{“x”: 40, “y”: 7}
{‘x’: 40, ‘y’: 7}
{x:40,y:7}
and so forth.

Even this:

hero.moveXY(21,5);
var location = {x: 40, y: 7};
hero.move(location);

Would someone please point out the blindingly-obvious mistake I must be making here? This cannot be a bug that passed QA, surely. So it must be me, and I’m starting to get distressed.

Update: This problem is officially ruining other levels for me, (and blocking access to still others) even where the code for movement is provided and I am getting seriously frustrated.

Is this a bug, and not my incorrect coding? If so, with whom might I communicate about the problem of such an intrusive bug not being caught in QA?

[Aya]

@DoesNotCompute

{“x”: 40, “y”: 7}

It works with me when I usually do this

[Deadpool198]

Hero.move() only works when inside a loop. It is a continuous and interruptible action. This is a good example of its usage:

while True:
    enemy = hero.findNearestEnemy()
    if enemy:
        hero.attack(enemy)
    else:
        hero.move({"x": 10, "y": 10})

This is much better than using hero.moveXY(10, 10), which would mean that the hero might be attacked whilst moving to 10, 10, because moveXY is a single action and no code can be run whilst the hero is moving to the desired location, unlike hero.move(), which is run many many times to get the hero to a certain location, and can be overrun by another command (like hero.attack()) if you set up your conditional statements suitably.
If you are using:

hero.moveXY(21,5);
hero.move({"x": 40, "y": 7}); # by the way it does need the " " as well

Then you’ve only called move() once, meaning your hero will not go very far at all. And even if this code is inside a loop, that means that the moveXY is also looped, taking you back to (21, 5) constantly.
If you want to use move() like moveXY you can use:

while hero.distanceTo({"x": 10, "y": 10}) < 2:
    hero.move({"x": 10, "y": 10})

Although this is slightly buggy. You shouldn’t need to do this though.
Move() is just a very different function from moveXY() and requires different usage (it is much superior though, as it can be interrupted and changed constantly, for example to make a curve or a circle, and yet also capable of providing the same function as moveXY if needed.)
I hope this has explained the problem, and sorry if I’ve misunderstood your understanding of it.

[DoesNotCompute]

Thank you Deadpool! I am actually very glad that this was user error, as opposed to a bug.

I think I understand the difference between move and moveXY a little better now, and yes, I think I had written it without a loop, so my hero was only taking one step before moving on to other instructions.

(It was a little sneaky that the provided function in the pre-written code returned an object literal. This led me to believe that the “move” method was expected, not “moveXY”. Even though I could have changed the provided function code to return something else instead, or handled the identification of the position without calling that function, I thought that would be “cheating”, or at least missing some part of the lesson. As it happens, I obviously was missing part of the lesson, but not the part I had thought!)