User:Maven/sandbox: Difference between revisions
(more mucking about) |
(more) |
||
Line 6: | Line 6: | ||
==Adding a VGUI screen to a map== | ==Adding a VGUI screen to a map== | ||
Create a [[vgui_screen]] | # Create a [[vgui_screen]]. This is a point entity. | ||
# Set its '''Panel Name''' to the name of the screen that should be shown. (This is not the filename of the screen.) The available screens are listed in <code>vgui_screens.txt</code> (which can be [[GFCScape|extracted]] from '''???''' at <code>''steamdir''\SourceMods\''moddir''\scripts</code>). An example that comes with HL2 is <code>vgui_test_screen</code>. | |||
# Set '''Panel Width in World''' and '''Panel Height in World''' to match the size of the brush. 64 wide by 32 tall would be a reasonable starting size. | |||
# Compile the map and test. | |||
==Creating a VGUI screen== | ==Creating a VGUI screen== | ||
'''TODO:''' Can .res files be zipped into a BSP? If so, much of this section needs adjusted. | '''TODO:''' Can .res files be zipped into a BSP? If so, much of this section needs adjusted for HL2-singleplayer mappers. | ||
VGUI screen files have a ''.res'' extension and should be placed in <code>''steamdir''\SourceMods\''yourmod''\scripts\screens\</code>. | VGUI screen files have a ''.res'' extension and should be placed in <code>''steamdir''\SourceMods\''yourmod''\scripts\screens\</code>. | ||
Line 23: | Line 21: | ||
# The materials used in the ''.res'' file can be found in <code>source materials.gfc</code>. Extract the material files mentioned in the ''.res'' file to <code>''steamdir''\SourceMods\''moddir''\materials\vgui\screens</code>. | # The materials used in the ''.res'' file can be found in <code>source materials.gfc</code>. Extract the material files mentioned in the ''.res'' file to <code>''steamdir''\SourceMods\''moddir''\materials\vgui\screens</code>. | ||
# <code> | # Add the screen to <code>''steamdir''\SourceMods\''moddir''\scripts\vgui_screens.txt</code>. Here is an example which describes screen <code>vgui_test_screen</code> at <code>scripts/screens/vgui_test_screen.res</code> and <code>teleport_countdown_screen</code>. Adjust it for your screen. | ||
"VGUI_Screens" | "VGUI_Screens" | ||
Line 36: | Line 34: | ||
"resfile" "scripts/screens/vgui_test_screen.res" | "resfile" "scripts/screens/vgui_test_screen.res" | ||
} | } | ||
} | } | ||
Revision as of 13:59, 23 September 2005
This is my personal sandbox area.
Adding a VGUI screen to a map
- Create a vgui_screen. This is a point entity.
- Set its Panel Name to the name of the screen that should be shown. (This is not the filename of the screen.) The available screens are listed in
vgui_screens.txt
(which can be extracted from ??? atsteamdir\SourceMods\moddir\scripts
). An example that comes with HL2 isvgui_test_screen
. - Set Panel Width in World and Panel Height in World to match the size of the brush. 64 wide by 32 tall would be a reasonable starting size.
- Compile the map and test.
Creating a VGUI screen
TODO: Can .res files be zipped into a BSP? If so, much of this section needs adjusted for HL2-singleplayer mappers.
VGUI screen files have a .res extension and should be placed in steamdir\SourceMods\yourmod\scripts\screens\
.
vgui_test_screen.res
is a good starting point for creating a VGUI screen file; it can be extracted fromsource engine.gcf
at pathhl2/scripts/screens/
using GCFScape.
- The materials used in the .res file can be found in
source materials.gfc
. Extract the material files mentioned in the .res file tosteamdir\SourceMods\moddir\materials\vgui\screens
.
- Add the screen to
steamdir\SourceMods\moddir\scripts\vgui_screens.txt
. Here is an example which describes screenvgui_test_screen
atscripts/screens/vgui_test_screen.res
andteleport_countdown_screen
. Adjust it for your screen.
"VGUI_Screens" { "vgui_test_screen" { // This is our example screen "type" "vgui_screen_panel" "pixelswide" 480 "pixelshigh" 240 // This must be the file you created in step 1 "resfile" "scripts/screens/vgui_test_screen.res" } }
VGUI code modifications
There is a problem with VGUI screens receiving input.
TODO: what are the effects? Is it a crash bug?
CInput::ExtraMouseSample
calls g_pClientMode->CreateMove()
without initializing the button flags, thus the VGui screen is updated with bad button input. Since IN_VALIDVGUIINPUT
is only set from within CInput::CreateMove
, the VGui screens only update when the button flags are valid.
There are two known fixes. They both involve code changes and therefore are only applicable to mods.
Fix 1
In in_buttons.h, where the other flags are defined add:
#define IN_VALIDVGUIINPUT (1 << 23) //bitflag for vgui fix
next, in in_main.cpp inside method CInput::CreateMove( ... )
add:
cmd->buttons |= IN_VALIDVGUIINPUT;
right above:
g_pClientMode->CreateMove( input_sample_frametime, cmd );
next, in c_baseplayer.cpp inside method C_BasePlayer::CreateMove( ... )
add:
if(pCmd->buttons & IN_VALIDVGUIINPUT)
right above:
DetermineVguiInputMode( pCmd );
(So it only calls DetermineVguiInputMode
if the buttons include our flag)
and finally, inside method C_BasePlayer::DetermineVguiInputMode( ... )
change both instances of:
pCmd->buttons &= ~(IN_ATTACK | IN_ATTACK2);
to read:
pCmd->buttons &= ~(IN_ATTACK | IN_ATTACK2 | IN_VALIDVGUIINPUT);
Fix 2
An alternative fix would be to add a new boolean variable to CUserCmd
such as bButtonFlagsValid
that can be set depending on the validity of the button flags. This would allow the structure to internally store this information for its whole lifetime while freeing up that extra button bit.