Player cannot go down in several columns when at the very top (and never in the leftmost column)

[JogoShugh]

I'm using code derived from stepControls from Quintus (http://www.html5quintus.com/api/classes/stepControls.html)

Problem

When the player is in the left-most column it cannot go Down if the stepping = false line is inside the step: function for the playerControls component. It doesn't matter where on this left-most column the sprite is, when attempting to go DOWN, angle 180, it doesn't budge. Debugging shows that the collision detection is registering that it's colliding with the tile above it. It also messes up every fourth column in the down direction only but ONLY when at the very top of the column. It doesn't affect other columns or other directions.

File and code

File: client/views/game/game.next.js

Lines of code for playerControls and the Player sprite:

https://github.com/JogoShugh/SpaceMiner/blob/developing/client/views/game/game.next.js#L776-L914

How to test

I have a production and a staging deployment of this up on Modulus.io. The staging branch is deployed out of the developing branch for now in this repo.

Production, not based on stepControls / playerControls:

• Navigate to http://spaceminer.mod.bz/lesson?id=training&sec=6
• Using your arrow keys, move the player to the top left cell, and then attempt to go DOWN
• Expected: it should go down.
• Actual: it goes down.

  Staging, based on stepControls / playerControls:

• Navigate to http://spaceminerstg.mod.bz/lesson?id=training&sec=6
• Using your arrow keys, move the player to the top left cell, and then attempt to go DOWN
• Desired/Expected: it will go down.
• Actual: It's stuck :-(

  Testing with automation code

Students use these levels to incrementally learn basic coding skills, and we added a game.player.move(...) API. In prod and staging, if you paste the following code and press the Execute button you can see how it still works in prod, but based on staging where I'm trying to use the more rigid and predictable stepControls based approach, it has the issue described above:

function getCols(startX, startY,
 totalCols, distanceBetween)
{
  var colsPickedUp = 0;

  function pickup() {
   if (colsPickedUp < totalCols) {
     var nextX = startX + 
      (distanceBetween * colsPickedUp);
      console.log(nextX);
     game.player.move(
       nextX + ' ' + startY,
       '11 d', pickup);
    colsPickedUp = colsPickedUp + 1;      
   }
 }
 pickup();
}

getCols(0, 0, 6, 3)

How to develop

To run locally requires Meteor.js, but unfortunately there were some ES6 hacks I had to do, so it would be better to just work off of Nitrous with me directly over Google Hangouts or something for now.

[JogoShugh]

I've created a developing branch and also refactored the playerControls step function make it clear what I think the original intent was (by the Quintus author).

In the process, I tried bumping the origY downward (positive direction from origin of top, left), and this does get past the problem because the collision stops reporting col.tile === true. Obviously, this is a hack, but it helps zero in on what the heck is happening. Here's where I changed this:

https://github.com/JogoShugh/SpaceMiner/blob/e0cfe1891fea588fef07b425aa7cd06ca9e12ff4/client/views/game/game.next.js#L807

The problem you can see by removing the + 5, and then moving the player manually to the first column, and then pushing the down key. Move 4 or 5 to the right on the first row, and press down again. You should see the console log out that it has hit a tile. The tileX and tileY are reported as tileY of 0, which would be the topmost, static tile. It's just really bizarre that this DOES NOT happen on tiles adjacent to it.

[JogoShugh]

Fixed