evKEYBOARD question

[doomlazer]

In Police Quest 2 room 8 the game responds to F8 and F10 key presses (PQ2's gun shortcuts), with the message, "Calm Down. You have no need of your gun here."

If I'm interpreting this code correctly CTL+ALT+SHIFT+SCR_LOCK also triggers the same message.

Code: [Select]

(== (= eventMessage (event message?)) 16384)
I'm making some assumptions here based on the enums in sci.sh, so maybe I'm mixed up, but I'm curious as to what that key combination would have been used for on a DOS machine. I checked the PQ2 manual and searched online for the key combination, but I'm not seeing anything relevant.

It seems like an odd way to trigger Sonny's firearm. Any clue what might have been intended here?

A question about the number 16384, because I'm still trying to wrap my head around this. Would 43168 return true as well or does it only match in that order?

A final question about PQ2. In the background pic the computer is branded HOYT +++, but in the game it overlays a sierra brand. Any idea what HOYT might be?   Edit: that would be PQ2 programmer Chris Hoyt I guess. The Sierra label that covers it is called "Shaw" in the decompiled code likely in reference to another PQ2 programmer, Jerry Shaw.

Can you guess what the two synonyms for DOS in PQ2 are?

[EricOakford]

A question about the number 16384, because I'm still trying to wrap my head around this. Would 43168 return true as well or does it only match in that order?

16384 translates to the hex value $4000. In keys.sh, this is the key code for F6, used to load the gun. F8 is used to draw or holster the gun, and F10 is used to fire the gun. This is all set up in the menu bar, but the decompiler wouldn't automatically know that. So yes, I need to go through that and make the code easier to understand.

[doomlazer]

Wow. I was way off. I was  also checking the manual for Scroll lock, when I should have verified the gun controls. Sorry, I haven't played PQ2 in at least 10 years.

Thanks.

[doomlazer]

Further down is this statement

Code: [Select]

(< (event message?) 127)
127 should be 7F in hex, so it's checking that it's in the value is less than the 'alt' key presses, but 7F itself doesn't seem to be defined. For the sake of clarifying the code, is there a better way to represent that statement?

[Charles]

the full context of the code:

Code: [Select]

(and
    (< KEY_SPACE (event message?))
    (< (event message?) 127)
    (< local154 13)
)

Those event messages correspond to the ascii codes of the keys being pressed on the keyboard.  You can see a list of all ascii characters here: https://theasciicode.com.ar/

So basically it's checking that a valid key was pressed.  Nothing less than (and excluding) KEY_SPACE (aka 32) and nothing above 126, aka tilde (~).

[doomlazer]

so It looks like according to that link 127 is Delete meaning

Code: [Select]

(< (event message?) KEY_DELETE)
Would improve readability for people like myself.

Thank you.

[doomlazer]

What control color would -24576 be in this context?

Code: [Select]

(or
(== (ego onControl: 1) cLMAGENTA) ;8192
(== (ego onControl: 1) -24576)
)

It should be $6000 in hex, but I can't match that to anything in the defines. There are only two control colors used in the room, the other being $4000 yellow.

[Kawa]

First of all, -24576 is $A000.

Second, you don't want to use the cl___ constants here. Actors can stand on multiple colors, so you want ctl___ (ctl for control, not cl for color), which can be combined. As such, $A000 is not a defined color either because it's ctlWHITE | ctlFUCHSIA. Likewise 8192 or $2000 is ctlFUCHSIA, not clMAGENTA.

[doomlazer]

The reason I'm using clMAGENTA is because I switched from sci.sh to SYSTEM.SH to get the original sierra names for Display, p_at, p_font, etc.. Sorry, I didn't mention that. This is from PQ2 in the SCI decompile archive.

from SYSTEM.SH:

Code: [Select]

; ******* CONTROL colors
;         -------------- ; color#
;          ; ------
(define cBLACK 1 ) ; 0
(define cBLUE 2 ) ; 1
(define cGREEN 4 ) ; 2
(define cCYAN 8 ) ; 3
(define cRED 16 ) ; 4
(define cMAGENTA 32 ) ; 5
(define cBROWN 64 ) ; 6
(define cLGREY 128 ) ; 7
(define cGREY 256 ) ; 8
(define cLBLUE 512 ) ; 9
(define cLGREEN 1024 ) ; 10
(define cLCYAN 2048         ) ; 11
(define cLRED 4096         ) ; 12
(define cLMAGENTA 8192    ) ; 13
(define cYELLOW 16384 ) ; 14
(define cWHITE 32768 ) ; 15
Which should be $2000. I think the online hex converter I used dropped the sign on -24576 which added to my confusion, so thank for the correct value.

Since it's returning true for standing on white, which should never be possible for this room, is it safe to conclude this is a superfluous addition by the decompiler?

[doomlazer]

I think this is the last piece I'm missing:

Would both $0080 and $00c0 return true on a control check for ctlSILVER?

If so, why does $00c0 (192) work? Is it rounding to a valid control value before checking? Maybe $00c0 is first value the decompiler found that worked? 

Edit: $0120 returns true for both ctlPURPLE and ctlBLUE which isn't proper game behavior. I'm thinking the result might be erratic when checking control colors against invalid values?

[Kawa]

Going by the list from SYSTEM.SH you just posted and completely ignoring the Studio defines:

$00C0 is $0080 cLGREY plus $0040 cBROWN. If you tell isOnControl to use the entire footprint instead of only the hotspot, and stand on both a gray and brown control pixel, you'll get $00C0. If you tell it to use only the hotspot and then stand exactly on the gray pixel, it'll return only $0080.

$0120 is $0100 cGREY plus $0020 cMAGENTA. There can be no invalid values since each possible control color you can stand on has its own unique bit. Since there are sixteen possible control colors and all numeric values in SCI are 16-bit, you literally cannot specify an invalid set.

[doomlazer]

Thank you it's starting to make more sense. I see this comment in Actor.sc:

   (method (onControl org)
      ;; If org is present and nonzero, return the control under the actor's
      ;; origin.  Otherwise, return a bit-mapped word indicating the controls
      ;; which the actors baseRect is on.
      

So I believe the following

Code: [Select]

(& cBROWN (ego onControl:))
returns true if cBROWN is anywhere in the bitmask of colors the actor baseRect is touching.

Code: [Select]

(== (ego onControl: 1) cBROWN)
only returns true if the hotspot/origin is on cBROWN. I can use this and your info about the bitwise color math to determine what the correct value should be. I believe that the decompiler is producing incorrect values occasionally, but at least now I have enough understanding to work that out.


Edit: Yep, the decompiler seems to be generating incorrect statements in certain places. In one such instance it produced

Code: [Select]

(& (ego onControl: 1) $0120)
where the condition should be:

Code: [Select]

(== (ego onControl: 1) $0020)
So both the operator and value were incorrect (normally the compiler does determine the correct condition). It's a big relief to finally understand enough to get consistent results. Thank you for helping me get there!

[Kawa]

If you want it extra readable, use something like (| cBROWN cLGREY) instead of $00C0. That will compile to the same thing.

Now...
(& (ego onControl: 1) $0120) means "get me all the bits in $0120 and whatever ego is standing on that are both set". If none of them are (ego is standing on only black?) then the result will be zero, a false-y value. If ego stands on dark gray ($0100), the result will be $0100, which is truth-y. If ego stands on magenta ($0020), the result will be $0020, which is also truth-y. Therefore, this condition will be true if ego is standing on magenta or dark gray. The code, as decompiled, makes sense. To replace it with "equals $0020" is to change the entire logical meaning of the check.

[doomlazer]

(| cBROWN cLGREY) instead of $00C0.

Great tip, I don't want to create new defines, so that's a great way to improve readability when checking for more than one color!

I'm not sure it was clear, but the problem with the statement:

Code: [Select]

(& (ego onControl: 1) $0120)
Isn't that it's doesn't makes sense, you've clarified things to where I understand the code now, it's just the wrong behavior for the game when compared to retail. I'm intentionally changing the logic of that statement.

In this specific situation the game should only allow you talk to the cops on the toilet directly outside the stall on $0020. $0100 is by the lockers, which I verified in a straight retail copy that the game should be giving the "not close enough" message on $0100.

I have no idea why the decompiler thought $0100 should return true in this situation, but I guess that doesn't really matter.

[Kawa]

I have no idea why the decompiler thought $0100 should return true in this situation, but I guess that doesn't really matter.

Any non-zero value is considered true. Having the actual true being 1 is just convention. So it's not so much that "$0100 returns true", but "if this expression yields a non-zero result, then do this."