Difference between revisions of "Talk:GetCrosshairRef"
Jump to navigation
Jump to search
imported>Haama (Findings and other stuff) |
imported>Haama (→Suggestions for other tests: More exacts for input detection) |
||
| Line 23: | Line 23: | ||
#When will it return NULL - the frame the player presses NULL, the next frame, etc.? | #When will it return NULL - the frame the player presses NULL, the next frame, etc.? | ||
#*From informal tests I'd say the next frame. It's hard to say when the key is pressed exactly, but when using '''if [[IsControlPressed]] 5''', the function will still return the correct reference. However, if you use '''if [[IsKeyPressed2]] ActivateKey''' the function will return NULL. '''IsKeyPressed2''' seems to trigger a frame after '''IsControlPressed''', meaning there's at least one frame after the player preses Activate and when the function returns NULL. | #*From informal tests I'd say the next frame. It's hard to say when the key is pressed exactly, but when using '''if [[IsControlPressed]] 5''', the function will still return the correct reference. However, if you use '''if [[IsKeyPressed2]] ActivateKey''' the function will return NULL. '''IsKeyPressed2''' seems to trigger a frame after '''IsControlPressed''', meaning there's at least one frame after the player preses Activate and when the function returns NULL. | ||
#*From discussions with Scruggsy, the input functions use two different systems: Windows-API and Direct-X. The functions that use Windows-API detect the key a frame before the Direct-X functions, but more importantly they detect the key press before '''GetCrosshairRef''' returns 0. These functions include [[IsKeyPressed]] and, for keyboard keys, the "third generation" input functions like [[IsKeyPressed3]] and [[OnControlDown]]. | |||
#Is there an .ini setting to control this? | #Is there an .ini setting to control this? | ||
#*Essentially, nullifying the crosshair reference seems... pointless. I wonder if there's a way to turn it off. | #*Essentially, nullifying the crosshair reference seems... pointless. I wonder if there's a way to turn it off. | ||
:--[[User:Haama|Haama]] 16:29, 10 July 2008 (EDT) | :--[[User:Haama|Haama]] 16:29, 10 July 2008 (EDT) | ||
Revision as of 13:59, 10 December 2008
Returns NULL when player presses activate
This function "falsely" returns NULL for a frame when the player activates an object. Which frame seems to depend on whether you're also using IsKeyPressed, any of the other OBSE Input functions, and whether the player uses the Mouse or Keyboard key. A few more tests, and I'll have exacts here later.--Haama 17:08, 22 June 2008 (EDT)
- I've posted some findings on the main page - you can test it yourself with the GetCrosshairRef debug file here.
- Test Setup
- No other mods - the debug file and an Autoload file
- Beginning character using Kobu's Skip Intro mod (savegame included with Autoload, removed KSI dependency manually/re-saving)
- Oblivion patch v1.2.0416, SI, OBSE v15, Pluggy v73, TSFC v0.5.3
- Manually pressed Activate
- Used both a keyboard key (Left-arrow) and a mouse key (Right MB)
- Tried various objects around the Imperial Sewer Exit and Anvil
- No other mods - the debug file and an Autoload file
- Test Setup
- Tested Objects
- Statics and flora - 1 frame of NULL
- Doors - 2 to 5 frames of NULL
- Tested Objects
- --Haama 16:29, 10 July 2008 (EDT)
Suggestions for other tests
- Will object types return NULL?
- Will they return NULL when usingTapKey and/or TapControl?
- From informal tests, I'd say yes.
- When will it return NULL - the frame the player presses NULL, the next frame, etc.?
- From informal tests I'd say the next frame. It's hard to say when the key is pressed exactly, but when using if IsControlPressed 5, the function will still return the correct reference. However, if you use if IsKeyPressed2 ActivateKey the function will return NULL. IsKeyPressed2 seems to trigger a frame after IsControlPressed, meaning there's at least one frame after the player preses Activate and when the function returns NULL.
- From discussions with Scruggsy, the input functions use two different systems: Windows-API and Direct-X. The functions that use Windows-API detect the key a frame before the Direct-X functions, but more importantly they detect the key press before GetCrosshairRef returns 0. These functions include IsKeyPressed and, for keyboard keys, the "third generation" input functions like IsKeyPressed3 and OnControlDown.
- Is there an .ini setting to control this?
- Essentially, nullifying the crosshair reference seems... pointless. I wonder if there's a way to turn it off.
- --Haama 16:29, 10 July 2008 (EDT)