• Announcements

    • Ashal

      SITE MOVED - IN READ ONLY MODE   12/08/2015

      Please use http://www.loverslab.com moving forward. Site has been restored to a previous version, and this one placed into a read-only mode. This is available for a limited time so users may reference/copy content that has been lost in the transition. This will no longer be accessible by December 22nd, 2015.
Halstrom

Fallout New Vegas GECK / Scripting Help 101

2,597 posts in this topic

Well I found a way to do it, by looking at someone else's script, though I'm not entirely sure what this little block is doing. It'd be nice if someone could explain, this is the first time I really couldn't figure it out by making the script myself, or by basing it on someone else's thing and then making my own, this is pretty much someone else's script. 


 





If (iKey != IsKeyPressed iThermalHotKey)
Let iKey := (iKey == 0)
If (iKey == 1)
If (bUpdate == 0)
Let bUpdate := 1
ElseIf (bUpdate == 1)
Let bUpdate := 0
EndIf
EndIf
Endif  


0

Share this post


Link to post

Its just poorly written from a readability stand point, its actually quite simple:



int iThermalHotKey ; directX scancode
boolean ThermalKeyPressed, DoUpdate

If (ThermalHotKeyPressed != IsKeyPressed iThermalHotKey) ; If the stored value of thermalhotkeypressed is different to whether its currently pressed
        Let ThermalHotKeyPressed := (ThermalHotKeyPressed == False) ; Reverse value, False-> True, True->False
        If (ThermalHotKeyPressed == True) ;* if now true
            If (DoUpdate == False) ; now reverse the value, for this variable too.
                Let DoUpdate := True
            ElseIf (DoUpdate == True)
                Let DoUpdate := False
            EndIf
        EndIf
    Endif 

Probably written by someone either trying to be deliberately obscure or with poorly designed code (maybe hacked onto at end).


0

Share this post


Link to post

Obscure or not, it worked and it was way simpler than what other mods were attempting to do, and these were not the sort of mods I'd have expected to have such complex codes. Well some of them probably require it, but I thought most were overly complex just to press a button twice. 


0

Share this post


Link to post

SCANCODES


 


Since I started playing NV (but same happens in Skyrim), I noticed there are differencies on the keys. At start I thought it was because of the differencies of a US keyboard with a IT keyboard, but then I looked for pictures and I saw it's not in this way. We both use QWERTY and the differencies are more on the symbols, like you have {} while I don't have them etc.


 


So the problem essentially was that the ingame keys weren't those described in the menus. For example, if it says "Press Q to take all", I must press A instead.


As player, I didn't have big issues, I thought it was a bug on the things written in menus, so I automatically was presisng A when it was asking for Q etc.


 


But now, on a script, I just realized that maybe it's something else, maybe it involves scancodes. That's somewhat disconcerting. If I press Q, it returns the scancode of A and viceversa. Still, you could say "it's the keyboard", but hey, my Q is in the same position of yours, how can I know that...


I thought these things were pretty much standard for languages, that the differencies were more linked to QWERTY / AZERTY etc. but it's not in this way so I would love to understand better.


I looked for some hypotetic IT scancode table to compare with a US scancode table (if it's silly, also think I know nothing about this subject) but I didn't find anything, I always find a single standard scancode table, in hex, I convert it in dec and I find the same NVSE scancode table, and it tells me that Q is 16 while for me is 30.


 


So... please, can someone who knows about it explain me this?


 


EDIT: I mapped what scancode gives me back


My keyboard                  Scancode result


qwertyuiop                     azertzuiop


asdfghjkl                         qasfghjkl


zxcvbnm                         wxcvbn,


 


the most weird is the first line, it has "z" twice, one over q and one over y


if it wasn't for that double letter, I would have said it is an azerty keyboard. But still, why console writes letters ok? why in game commands are not ok? why scancode gives me results similar to azerty? I can't get this all... -_-


0

Share this post


Link to post

Which game language are you playing ? I play with the English language of the game and my Azerty keyboard generates Qwerty scancodes :)


0

Share this post


Link to post

I play with italian keyboard which is qwerty. it is different by US but only for symbols. EDIT: I play with italian NV version.


you confused me more, you have azerty and it gives qwerty? but on console you still write with azerty? oh god...


 


jaam I thought about the first line I mapped, the fact I have two "z" (one over q and one over y). Could it be that one of the two NVSE functions I use makes a mistake and puts a z instead of a y?


this is what I'm doing:



    Let iCharIndex := GetKeyPress 0

    if iCharIndex == -1
    else
        Let sCurrString := GetKeyName iCharIndex
        Print sCurrString
    endif

0

Share this post


Link to post

You can set the localization of the keyboard in windows, I do not believe the actual keyboard matters. If that is not what FNV uses you can probably change it in the config, or at least .ini file. Perhaps something is mismatched.


 


You might also consider finding a screw driver or something and popping every key off your keyboard, then put them all back in a random order and set your keyboard layout to US. For a few weeks your brain may hurt, but after that you will be perfect at touch typing... I haven't had the courage to do this yet :P.


0

Share this post


Link to post

Odessa, I think you misunderstood the issue. The keyboard writes fine in console, while doesn't write fine in game. I think this is how the game interprets the scancodes, but it's actually sets to work with the right keyboard. So it's not even a windows setting


 


I write Q, it is a Q because on console I see Q, but scancode returns 30 which is A (it emulates like an AZERTY, but not really, because it makes AZERTZ)


Also, read how Jaam has the opposite, he has AZERTY and scancode returns as it has QWERTY...


0

Share this post


Link to post

The scancode table is standard, there aren't different versions for different countries. A scancode represents the physical position of the key on the keyboard, not the ASCII character printed on the key. So what you're experiencing is normal. An AZERTY keyboard 'A' has the same scancode as a QWERTY keyboard 'Q' -- they are in the same physical location.

If you use IsKeyPressed, IsKeyDisabled, or any other NVSE function that takes a scancode as a parameter, then it's the position that matters; 16 always means "Key at the position of 'Q' on a QWERTY keyboard". The functions that RETURN a scancode are thus, always correct.

What's incorrect is saying press 'A' because 'A' may be in a different position on different keyboards, as yours is.

So what you want to know is what the correct key for code 0x10 (16) is, for any given user. Unfortunately, there's nothing in (FOSE anyway) that does this. The "right" thing to do is add some scancode-to-ascii (and the reverse) functions to NVSE.

0

Share this post


Link to post

Well barring NVSE support, you could always ask the user for their keyboard layout (qwerty/azerty/dvorak -- this may be in the ini?) and then use UDFs of your own design to translate. Sounds like a pain in the ass though. ;)

0

Share this post


Link to post

I can understand that, it is cool. Now still there are those two details that are not explained: why there are two Z, one over the Q and one over the Y, and why Jaam with an AZERTY keyboard has a QWERTY answer from the scancode.


0

Share this post


Link to post

I have no real idea why you'd be seeing two Z's. Are you sure that is what's happening? The scancodes are identical? I don't know how you came up with your list of what you pressed vs. what you expected. On an AZERTY keyboard those keys should produce exactly the same scancodes as pressing QWERTY on a QWERTY keyboard.

As for Jaam, different keyboards or regional settings maybe, or different drivers. It's the keyboard that generates the actual scancode. Windows can be configured to interpret this and modify it, based on regional settings. Your keyboard layout doesn't matter; the key in that position ('Q' on QWERTY and QWERTZ, 'A' on AZERTY, "'" on DVORAK) does not matter. Pressing that key will always generate scancode 16 from the keyboard. The character that then appears on the screen depends on the windows locale and keyboard settings, the game region settings, etc.

Also, USB keyboards can generate different (USB HID) specific scancodes. So if one of you is using USB and the other one PS/2, the scancodes may be different for the same key.

0

Share this post


Link to post

I attached above the script I'm using:



    Let iCharIndex := GetKeyPress 0

    if iCharIndex == -1
    else
        Let sCurrString := GetKeyName iCharIndex
        Print sCurrString
    endif

When I press the keys, it prints me on console the scancode. When I press Y it prints Z


 


EDIT:


I actually used a workaround:



        if iCharIndex == 21
            Let sCurrString := "Y"

But I tracked it down, it seems that GetKeyName translates wrong when Index is 21


 


And this is the difference from the two keyboards, the "translation" I did from my IT keyboard and the resulting ingame scancode. At least for what concerns letters which is what I care.





if iCharIndex == 16 ; Q
Let iCharIndex := 30 ; A

elseif iCharIndex == 17 ; W
Let iCharIndex := 44 ; Z

elseif iCharIndex == 30 ; A
Let iCharIndex := 16 ; Q

elseif iCharIndex == 17 ; W
Let iCharIndex := 44 ; Z

elseif iCharIndex == 44 ; Z
Let iCharIndex := 17 ; W

elseif iCharIndex == 51 ; Comma
Let iCharIndex := 50 ; M


0

Share this post


Link to post

 

I play with italian keyboard which is qwerty. it is different by US but only for symbols. EDIT: I play with italian NV version.

you confused me more, you have azerty and it gives qwerty? but on console you still write with azerty? oh god...

 

jaam I thought about the first line I mapped, the fact I have two "z" (one over q and one over y). Could it be that one of the two NVSE functions I use makes a mistake and puts a z instead of a y?

this is what I'm doing:

    Let iCharIndex := GetKeyPress 0

    if iCharIndex == -1

    else

        Let sCurrString := GetKeyName iCharIndex

        Print sCurrString

    endif

No, console is still Qwerty, so I have to remap the keys in my head before typing. :)

 

 

0

Share this post


Link to post

Ok, I think I'm on the bottom of the thing then, nice :) Excluding the GetKeyName possible issue on scancode 21, I guess there's nothing else than what Pride already told :)


0

Share this post


Link to post

AJ, try this: http://www.softpedia.com/progDownload/KeyTweak-Download-10487.html

Just install it and run, then select "half teach mode" at the bottom. A new window will pop up, click "scan a single key" and press your 'Q' or 'Y' or whatever keys are popping up as Z's, make sure it's actually getting different scancodes. The program will also show any active remapping.

The first row for all keyboards should be:

Q  W  E  R  T  Y   (querty)A  Z  E  R  T  Y   (azerty)Q  W  E  R  T  Z   (qwertz)17 18 19 20 21 22  (scancode)
0

Share this post


Link to post

My scancode is correct, Pride, the first row answers these numbers since it's a QWERTY. It's only ingame that answers bad.


GetKeyPress (my Q) returns 30 which is A etc.


It returns all the scancodes like if I had an AZERTY.


 


The only exception is the Y, which returns Z like the W. This is because of GetKeyName acting strange.


 


GetKeyPress (My W) >>> 18


GetKeyName 18 >>> Z (because it's AZERTY in game)


But:


GetKeyPress (my Y) >>> 21


GetKeyName 21 >>> Z (which is simply wrong)


0

Share this post


Link to post

My scancode is correct, Pride, the first row answers these numbers since it's a QWERTY. It's only ingame that answers bad.

GetKeyPress (my Q) returns 30 which is A etc.

It returns all the scancodes like if I had an AZERTY.

I want to explain once more, that the type of keyboard you have does not matter. The location of the key physically on the keyboard is what matters. QWERTY and AZERTY both return '30' for the first letter. I don't think you fully grasp this yet. Every keyboard (QWERTY, AZERTY, QWERTZ, DVORAK, etc.) will return '30' for the first letter on the keyboard (the one next to 'TAB').

 

The only exception is the Y, which returns Z like the W. This is because of GetKeyName acting strange.

 

GetKeyPress (My W) >>> 18

GetKeyName 18 >>> Z (because it's AZERTY in game)

But:

GetKeyPress (my Y) >>> 21

GetKeyName 21 >>> Z (which is simply wrong)

So, you have a QWERTY keyboard, but you have windows (or some game INI setting) set to AZERTY? Why does it think your keyboard is AZERTY when it's QWERTY?

It sounds like it's mixed up two different keyboard types. AZERTY and QWERTZ. That would explain why both of those positions give you a Z.

0

Share this post


Link to post

Oh god no *laughs* I think there's a lot of misunderstandings here :)


I continue to not understand, and I don't get why.


 


Your key tweak software answers with 16 (NOT 30) when I press the first letter (Q).


If I check the NVSE scancode list, it says that at 16 there's Q.


In game, if I open console and I press Q, it writes Q.


In game, if I do GetKeyPress (Q) it answers 30.


 


Every IT game sets the keyboard automatically correct, I never touched it. I think they get general settings of windows (which is IT language - IT keyboard - QWERTY)


Still, in the game there could be some setting, in some ini, which forces it to AZERTY, sure. But then, why game console writes correctly? Isn't it IN GAME? ...


 


Last, I don't think it mixes the two keyboard, as I said the specific issue with Y comes from the NVSE function, but I've seen you didn't read it.


 


EDIT:


ok I give up, since what I found disconcerts me too much.


I remembered there's the possibility to change keys in the menu, so I did. All my keys are mapped BY NEW VEGAS as if I have a AZERTY, EXCEPT the Y which appears as a Z (SO I HAVE TWO Z, FOR NEW VEGAS, ONE OVER THE W AND ONE OVER THE Y) but it has a different code. In fact the Z over the W doesn't act like the Z over the Y


I think this is the first time I feel to say they did cr*p, they did a huge amount of cr*p. Even when I found about the misplaced IDs I didn't think that, I thought "oh hey, it can happen...". But this is way too much. Damn Beth/Obsidian/whatever.


0

Share this post


Link to post

Sorry, yes, I meant 16 (not 30). That's the right scancode for that key.

And... wow.. way to go Beth/Obs/etc. That's pretty messed up, but I assume that now you have it straightened out, and no longer double-Z?

0

Share this post


Link to post

I still have this issue. Prideslayer, you know what I think? this is a bad mistake they did.


 


Here's the absurd assumption I'm having right now:


The game uses scancodes to handle the controls, like if you press scancode 17 you are walking forward (then has a sub-table which attribs controls to scancodes etc. but it's not interesting). However, the game has an internal table which uses for text, and it is different from languages. So, they somewhat think to a message box like "Press <scancode 17> to walk" and then it's translated to "Press W to walk" for a UK and "Press Z to walk" for a French. I'm not referring to the actual tutorials / messages boxes, I'm more referring to something they did during the development, like using some placeholder that was then automatically replaced during the translation. Yeah, that could even have been a nice idea, if you think that one day you'll translate it in different languages: you load different keyboards, then when you translate the game the keys specified inside the tutorials are translated too based by the keyboard you are supposing to use. Anyway, somewhat I finished inside the francophones group, and this is the first issue. The second issue is they messed up with the AZERTY table, mixing the values with QWERTZ, so that there are two Z. But as I said, it's just text, because the scancode still returns correct, you only see the wrong letter on video (so GetKeyName function IS ok, but the result on video is wrong).


 


Is this assumption insane? sure, but how many insane things there are in NV?... If I had the Wild Wasteland perk, probably I would hear the jingle right now... wo-hooo-hooooo...


 


I'm not going to re-map my keyboard with a third party software since it still won't solve the Z issue.


 


I'm going to switch language via Steam tonight, in few days I will download the english version. If ithen I won't have this issue, then my absurd conspiracy theory is true: they don't like us -_-


0

Share this post


Link to post

I'm sure they are using scancodes basically as you say, because there's no other way to communicate with the hardware. The keyboard itself sends scancodes -- not 'letters' or 'characters'.

The code to convert a scancode to a character is terribly easy, and the same no matter the game region -- it's built in to windows. I find it hard to believe they coded their own version of that. GetKeyNameText() is a built in windows function. You give it the scancode and a buffer, and it puts the ascii value for that scancode (according to current windows keyboard setting) into the buffer.

There should literally not be any code in the game engine to 'handle' this.

1. You plug in your keyboard of choice, any format.

2. You tell windows the layout, if it can't learn it via USB query.

3. Key < -- > Scancode map is now complete.

So as you say, maybe they did something insane. I'd seriously wonder WHY... if I didn't know better.

No matter what language you speak, or what language windows is set to, if you plug in an AZERTY keyboard, that first character is still 'A'. It's 'A' no matter if you're speaking English, Italian, French, or Russian. Understand what I mean?

0

Share this post


Link to post

It's possible that two things are going on.. both GetKeyPress and GetKeyName are in NVSE and might be broken in different ways. I'm peeking at NVSE src for a minute. Neither one has anything to do with the game itself, so we don't have to blame beth/obsidian. ;)

0

Share this post


Link to post