Page 1 of 1

Bug: Movement, Full Cell vs Half Cell (1.03) (FIXED)

Posted: Sat Dec 31, 2005 1:42 pm
by Guest
Found the solution. I can not toggle visibility from the figure menu, but I can toggle it from H key.
But I have found another one: I can move the tokens by full cells or half cells in the 2 and 4 directions but only by full cells in the 1 and 3 directions.

Posted: Tue Jan 03, 2006 3:05 pm
by heruca
Heh, the half-cell movement (achieved by holding down the SHIFT key while moving in direction 2 or 4) will soon be taken out. It's legacy code from an older version that had a problem with units being deployed between cells.

Note that you can also rotate objects in smaller increments if you hold down the SHIFT key while pressing the left or right arrow key.

Posted: Thu Jan 12, 2006 5:54 am
by Kepli
Updated for version 1.03

The moving half a square by holding SHIFT for directions 2 and 4 is still in there. This is not a bug or even annoying. I actually would like to see this for the other directions too :D

Posted: Thu Jan 12, 2006 11:26 am
by heruca
Unfortunately, if you move a figure half a cell so it's no longer lined up with the grid, then that figure's AoE overlays will also not conform to the grid. That's why I was planning on taking it out.

Will wait for more feedback on this before deciding one way or the other.

Posted: Wed Jan 18, 2006 12:51 am
by Halebop
This appears to have been taken out/fixed? There is still a minor anomaly in that hitting [SHIFT]+4 will spin the object image or character token (but not the base).

Posted: Wed Jan 18, 2006 2:36 pm
by heruca
You might want to see if you can recreate that, Halebop. I can find no way to spin a figure graphic without also spinning its base. I tried it with all the modifier keys and couldn't get it to happen.

Posted: Wed Jan 18, 2006 10:46 pm
by Halebop
Slight change but confirmed: [Shift]+[4] will spin the whole character image and base similar to using the arrow keys.

Posted: Fri Jan 27, 2006 1:27 pm
by heruca
I've been looking into this. It's not anything in my code. It doesn't happen on a Mac. But it seems that PC keyboards use the number pad as an alternative set of arrow keys (2 = down, 4 = left, 6 = right, and 8 = up). On my Dell keyboard, those keys even have arrow symbols printed on them right below each of those four numbers.

So I was able to replicate this so-called bug (which it isn't), but I'm actually able to do it without even holding down the shift key.

By the same token, if I deselect the figure, I can use the number pad to scroll the map on my Dell, but not on my Mac.

So, is this a Windows OS issue, or a PC keyboard issue? I'm curious whether ALL PC keyboards behave this way, even if they don't have arrow symbols printed on the number pad keys.

Posted: Fri Jan 27, 2006 1:36 pm
by heruca
Update: Regarding my last post, I was using the number pad keys with "Num Lock" turned off. When I turned "Num Lock" on, I was able to move the selected figure not according to the arrow key symbols, but according to the movement guide numbers. It's with "Num Lock" on that holding down the shift key causes the unit to spin in place.

In any case, this still isn't a bug, it's just the way PC keyboards do their thing.

Posted: Fri Jan 27, 2006 6:47 pm
by Halebop
I'll check mine out later today. I suspect this is more likely to be impacted by keyboard design than O/S. My keyboard is Windows XP specific and the secondary functions of the number keypad do hardcoded things like open the Calculator, Launch MS Media Player, Launch Web Browser etc.