Not a bug
BYOND Version:486
Operating System:Windows 7 Ultimate
Web Browser:Chrome 12.0.742.100
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND Developer forums.
Descriptive Problem Summary:

When assigning macros to various commands, I notice that in some instances it does not call specific commands, but only in relation to specific macros.

Numbered Steps to Reproduce Problem:

1. Set proj_attack command to macro Z.
2. Step in the southeast direction and press Z.
3. Nothing produces. Every other direction, the command works.
4. Set proj_attack command to macro SPACE.
5. Step in the southeast direction and press Z.
6. It works. Try southwest direction, nothing happens.
7. Set proj_attack command to macro A.
8. Every direction works.

Code Snippet (if applicable) to Reproduce Problem:
I know for a fact my move() procedure isn't causing the issue via testing, but have determined it is not even calling proj_attack() when the macro is pressed. I'll relay all the client verbs.

client {
verb {
move_left() {
set instant=1
if(p.moving) { return}
// the same goes for up, down, and right.
// move() appends when left, right, up, and down variables are set
// so that way players can move diagonally

proj_attack() {
set instant=1
var/game/projectile/throw/arrow/new_proj = new /game/projectile/throw/arrow(p,p.current_angle)
new_proj.mob = new /mob(new_proj)

Expected Results:

It should work on any macro key, that shouldn't matter.

Actual Results:

Pending which macro I select (Z or SPACE or others), one of the directions will not work. However, it is always random and for some other macros (ie A), it works for every direction.

The verb proj_attack() is never even called.

Does the problem occur:
Every time? Or how often? Every time pending which macro is selected for proj_attack()
In other games? n/a
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur?

When I select a random macro that works, like A.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? n/a. Only tested with the latest.

Workarounds: Selecting a random macro that works.

I've had this problem myself recently, it's almost always southeast.
Might I make a note. The actual SOUTHEAST macro (numpad 3) is not set to anything. My move() procedure takes note of when LEFT, RIGHT, UP, and DOWN variables are set to TRUE, and has them move accordingly.
Is step 5 right or is that a typo?

Something smells fishy here and I still think a code problem is in play. The macro system shouldn't be treating keys any different depending on the direction you're in at all. The only difference between key behavior the macro system is even capable of is that it will shift focus to the input control under certain conditions and some keys won't function as macros when text and/or focus is in the input control. But the last direction you moved would have absolutely no bearing whatsoever on how the macro was parsed or whether a command was sent.

One thing you need to try is putting debugging output (to world.log, not just to world) in the beginning of proj_attack() to see if it is being called. I feel quite certain it is, which means if so that your projectile creation is in error.
I've already dealt with outputting and am certain proj_attack() is not being called. If I set the macro key to Z, if I am holding both EAST+REP and SOUTH+REP and then press Z, nothing happens.

If I set the macro key to A, it works.

I'd be willing to send you my source code if you'd like and you can test it for yourself. My e-mail is - I can send the source code via that either tonight or tomorrow.
Okay, I'm officially closing this. The issue isn't DS; it's your keyboard. Keyboards can only handle so many keys at a time and when they hit their limit there are certain combinations they can't do.

Your problem is hardware, not software.
That's interesting, because it has happened on more than one computer for me (and more than one keyboard, respectively). I'm not sure why every single keyboard I happen to own would single the Z key out - that's where I don't follow your logic.

Your response leads me to believe, however, that I'm SOL, and this bug will just have to remain.

Email me if you ever want to have a look at what was happening - until then I suppose I'll have to find a reliable hot-key system.
CauTi0N wrote:
That's interesting, because it has happened on more than one computer for me (and more than one keyboard, respectively). I'm not sure why every single keyboard I happen to own would single the Z key out - that's where I don't follow your logic.

Most low-end keyboards have the same basic wiring layout. Practically speaking, usually any given keyboard can usually handle at least two independent keys being pressed, with special exceptions for the various shift keys (including ctrl and alt) because they're meant to be used in combos. But if several keys are pressed that share the same wiring, the keyboard's controller may be unable to see more than so many of them, causing these "ghost" keypresses to get lost. If you tried this with a gaming keyboard, which are often designed to allow 4 or 5 independent keys to be pressed at once, you'd see the difference. In fact, if I had had a demo to work with I wouldn't have been able to replicate your issue, because I'm using a Logitech G510.

I knew something was wrong the moment you said keys behave differently based on direction, because that's not even remotely plausible from a software standpoint--the code responsible for handling the keyboard and firing off commands is completely divorced from that used for display.

When you mentioned the issue happened when holding the two other keys down, that's when I realized what was really going on. You didn't mention in your initial report that you were holding down those keys, which is a vital piece of information for a keyboard bug report. Your numbered steps only mentioned stepping in the given direction, which traditionally involves just pressing and releasing a key. The code you provided offered a clue as to how the movement system worked but it wasn't clear.

Your response leads me to believe, however, that I'm SOL, and this bug will just have to remain.

It isn't a bug; it is a physical limitation of your hardware. I recommend sticking to macro combinations that work with your current hardware, because the odds are that anyone else will be able to use those same key combos.
Okay, I appreciate that response a little bit more Lummox JR. I think I understand and I'll attempt to find some sort of work-around. I was hoping to implement a click-move system, so that should lighten the key-load.

Thanks for the help, Lummox.