What's going on???? (emLEFT_BUTTON and emRIGHT_BUTTON)

[MusicallyInspired]

These aren't working. Or rather, they only seem to work part of the time and I can't figure out why/how.

I've been debugging some code, and as I've been digging into it I have vague memories of having problems with this years ago for KQ2SCI as well. In this code a method checks if there is a mouse event and whether that mouse event is the left button. If both are true, the code executes. There is a similar following block of code checking for mouse release. The problem is this seems to only randomly work some of the time. Randomly as in, sometimes it works all the time and sometimes it doesn't work at all, not that it will randomly work and not work within the same game runtime instance. Here is the code:

Code: [Select]

(if
(and
(== (pEvent type?) evMOUSEBUTTON)
(== (pEvent modifiers?) emLEFT_BUTTON)
) 

And here is the following code to check for mouse release.

Code: [Select]

(if
(and
(== (pEvent type?) evMOUSERELEASE)
(== (pEvent modifiers?) emLEFT_BUTTON)
)

As I said, this seems to work sometimes and not others without any change. Sometimes it will not respond at all and other times it works without a hitch. I've been trying to nail down exactly why and I simply can't. I've also tried this on period hardware and get the same random results (random between game runtime instances) so it's not a DOSBox issue or a Windows issue. This is with the game interpreting the script only. It works without a hitch if I remove the modifiers check and just do any mouse event. But then both buttons will execute the block of code; two separate instances at the same time. I could fix this with some extra conditional statements to isolate the action, but this is just bugging me now when event modifiers should be working. I had wondered if this was an issue with using the "==" operator instead of "&" but in recent attempts with that method I've found that it will work with the right mouse button and explicitly not the left mouse button. Switching to emRIGHT_BUTTON instead in that instead yields exactly the same results. It only works with the right mouse button. I'm at a total loss. Is this a compiler issue? It's just weird that the results are erratic and inconsistent with the *same compiled script* at two different instances at a time of loading DOSBox (or running on period hardware) and I just cannot track down what the missing factor is.

I've also tried changing "modifiers?" to "modifiers:" as I've seen some code use that invocation, but that doesn't work either. Any ideas?

EDIT: As well, I've seen several examples of invoking the left and right mouse buttons. emLEFT_BUTTON and emRIGHT_BUTTON in sci.h are both defined respectively as "1" and "3". But I've seen this invoked as "512" and "515" respectively and also "32" and "35" elsewhere in code examples on these forums and the Mega-Tokyo archives. What are the proper values/bitmasks for the mouse button event modifiers anyway? Doubly annoying is that using emRIGHT_BUTTON for right click look events works fine all the time. It's just this one case that I can't figure out. Can something else break this conditional check for mouse event modifiers that I'm just not aware of?

[Charles]

What about instead of checking explicitly if the the left button is a modifier, check if the right button is NOT a modifier?

As you've no doubt already seen, here are the other event modifiers defined in sci.sh:

Code: [Select]

(define emRIGHT_SHIFT 1)
(define emLEFT_SHIFT 2)
(define emSHIFT 3)
(define emCTRL 4)
(define emALT 8)
(define emSCR_LOCK 16)
(define emNUM_LOCK 32)
(define emCAPS_LOCK 64)
(define emINSERT 128)
(define emLEFT_BUTTON 1)
(define emRIGHT_BUTTON 3)

So you're checking for modifier == 1, which logically means if you're holding shift, or have numlock, scroll lock, or caps lock on, or insert turned on, then the result will NOT be 1. and so the logic check will fail.  I've never checked that in code, if numlock, scroll lock, or caps lock are properly detected or cause havock with right-clicking.

I have checked that a right-click is the same as holding shift and left clicking.  So that's also something that may be messing with your debugging... seemingly random, but maybe you're accidentally pressing caps lock every other time you type or something.

[lskovlun]

The broader issue here is that modifiers is a bitfield. Which means AND, OR, XOR and so on. For the shift modifiers, you could do several things:

Test a single shift key and ignore the state of the other one:

Code: [Select]

(if (== (& (event modifiers:) emLEFT_SHIFT) emLEFT_SHIFT) ...)
or test both shift keys and see if just one of them is held:

Code: [Select]

(if (== (& (event modifiers:) emSHIFT) emLEFT_SHIFT) ...)
or test if any of the shift keys is pressed:

Code: [Select]

(if (!= (& (event modifiers:) emSHIFT) 0) ...)

[MusicallyInspired]

What about instead of checking explicitly if the the left button is a modifier, check if the right button is NOT a modifier?

That's.....a good idea. I'm so lost in the weeds on this that I didn't think of that. (not (& (pEvent modifiers?) emRIGHT_BUTTON)) does indeed seem to work. And of course, just as weirdly as the previous inverse behaviour, referencing emLEFT_BUTTON in the same code instead of emRIGHT_BUTTON also works.

So you're checking for modifier == 1, which logically means if you're holding shift, or have numlock, scroll lock, or caps lock on, or insert turned on, then the result will NOT be 1. and so the logic check will fail.  I've never checked that in code, if numlock, scroll lock, or caps lock are properly detected or cause havock with right-clicking.

I have checked that a right-click is the same as holding shift and left clicking.  So that's also something that may be messing with your debugging... seemingly random, but maybe you're accidentally pressing caps lock every other time you type or something.

Surely this wouldn't be the case with the additional conditional check for this being specifically a evMOUSEBUTTON/evMOUSERELEASE event, right? The game shouldn't care about the keyboard modifiers even though they use the same bit values. At any rate, Activating/deactivating caps lock/numlock doesn't seem to change any behaviour in-game.

[Charles]

Surely this wouldn't be the case with the additional conditional check for this being specifically a evMOUSEBUTTON/evMOUSERELEASE event, right? The game shouldn't care about the keyboard modifiers even though they use the same bit values. At any rate, Activating/deactivating caps lock/numlock doesn't seem to change any behaviour in-game.

I don't know from checking the sci source, but I'm pretty sure that modifiers are the same regardless of event type. That's why holding shift and clicking is the same as a right-click. Hold Shift or press the right mouse button, get the same results.

I suspect this was more a feature than a bug... Don't forget, back in those days mice were a new novelty... not standard on every computer. They didn't all have right buttons either. And not just for macs. I can't find any evidence for it on a quick google search, but I'm pretty sure I remember an early box-shaped mouse for PC that only had one button.

[Kawa]

You suspect correctly, considering the manuals for the games spell it out.

From the original system scripts I see this:
1. There are no defines for mouse buttons, only modifier keys.
2. The icon bar checks for a shift-click to cycle through its icons and a ctrl-click to toggle between walk and the last icon.

Like this:

Code: [Select]

(if (& evType evMOUSEBUTTON) ;mouseDown
  (cond
    ((& (event modifiers?) emSHIFT) ;shiftDown, both left or right
       ;cycle icons
    )
    ((& (event modifiers?) emCTRL) ;ctrlDown
       ;toggle
    )
  )
)

Now, emLEFT_BUTTON is 1, which makes it equal emRIGHT_SHIFT. emRIGHT_BUTTON is 3, so emSHIFT. That sounds like a mistake to me.
The keyboard modifiers seem fine (though only alt, shift, and ctrl are in the Sierra header) but perhaps emSHIFT could stand to have a better name.