Talk:VGUI Screen Creation: Difference between revisions
(Fix) |
(Fix) |
||
| Line 3: | Line 3: | ||
== Fix == | == Fix == | ||
The input fix for the VGUI panel is poorly explained and doesn't address the real issue. I actually had to look at the revision history to see why the fix was needed at all before I could explore it further. The real problem is that <code>CInput::ExtraMouseSample</code> uses a dummy CUserCmd structure that only updates the mouse elements, but leaves the keyboard elements uninitialized at 0. So when <code>g_pClientMode->CreateMove()</code> is called near the end of the function it calls <code>C_BasePlayer::DetermineVguiInputMode()</code> with the bad input. This further explains why this function would be called 4 or 5 times, since it's the engine requesting extra mouse samples. So another possible fix that addresses the issue and doesn't waste a button bitflag may be adding a new parameter to <code>ClientModeShared::ClientMove()</code> and <code>C_BasePlayer::ClientMove()</code> (including the latter's inheritence hierarchy) such as <code>bool bValidKeys</code> where we pass '''true''' if called from <code>CInput::CreateMove()</code> and '''false''' when called from anywhere else. Even make that last parameter default to '''false''' and you won't need to change much but the one function call. Just my suggestion, the original author(s) can do what they will :) | The input fix for the VGUI panel is poorly explained and doesn't address the real issue. I actually had to look at the revision history to see why the fix was needed at all before I could explore it further. The real problem is that <code>CInput::ExtraMouseSample</code> uses a dummy CUserCmd structure that only updates the mouse elements, but leaves the keyboard elements uninitialized at 0. So when <code>g_pClientMode->CreateMove()</code> is called near the end of the function it calls <code>C_BasePlayer::DetermineVguiInputMode()</code> with the bad input. This further explains why this function would be called 4 or 5 times, since it's the engine requesting extra mouse samples. So another possible fix that ''directly'' addresses the issue and doesn't waste a button bitflag may be adding a new parameter to <code>ClientModeShared::ClientMove()</code> and <code>C_BasePlayer::ClientMove()</code> (including the latter's inheritence hierarchy) such as <code>bool bValidKeys</code> where we pass '''true''' if called from <code>CInput::CreateMove()</code> and '''false''' when called from anywhere else. Even make that last parameter default to '''false''' and you won't need to change much but the one function call. Just my suggestion, the original author(s) can do what they will :) | ||
Revision as of 22:53, 25 July 2005
Moved to "Creating a VGUI Screen" because the Entity description for the vgui_screen entity needs to have this page. --King2500 15:45, 14 Jul 2005 (PDT)
Fix
The input fix for the VGUI panel is poorly explained and doesn't address the real issue. I actually had to look at the revision history to see why the fix was needed at all before I could explore it further. The real problem is that CInput::ExtraMouseSample uses a dummy CUserCmd structure that only updates the mouse elements, but leaves the keyboard elements uninitialized at 0. So when g_pClientMode->CreateMove() is called near the end of the function it calls C_BasePlayer::DetermineVguiInputMode() with the bad input. This further explains why this function would be called 4 or 5 times, since it's the engine requesting extra mouse samples. So another possible fix that directly addresses the issue and doesn't waste a button bitflag may be adding a new parameter to ClientModeShared::ClientMove() and C_BasePlayer::ClientMove() (including the latter's inheritence hierarchy) such as bool bValidKeys where we pass true if called from CInput::CreateMove() and false when called from anywhere else. Even make that last parameter default to false and you won't need to change much but the one function call. Just my suggestion, the original author(s) can do what they will :)