Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[windows client] ESCAPE key #10

Open
Bacsu opened this issue Nov 8, 2016 · 9 comments
Open

[windows client] ESCAPE key #10

Bacsu opened this issue Nov 8, 2016 · 9 comments

Comments

@Bacsu
Copy link

Bacsu commented Nov 8, 2016

Escape key shouldn't open the gamemenu if chat is open or a predroped building (ghostbuilding) exists as commander.

@tschumann
Copy link

ESC is what is generally bound to the "cancelselect" command. The cl_enginefuncs_s struct in client.dll code has a function GetFirstCmdFunctionHandle which, according to http://www.mail-archive.com/[email protected]/msg08380.html, returns a linked list of registered commands (see http://www.quakeforge.net/doxygen/group__cmd.html for what xcommand_t most likely is). It would seem likely that "cancelselect" is in this linked list of registered commands. To stop ESC from doing anything when certain conditions are met you could update the function member of cmd_function_t to only call the old value if certain conditions are met e.g.

xcommand_t fnCancelselect;

void newCancelselect(void)
{
    if(!ChatIsOpen() && !PlacingBuilding)
    {
        fnCancelselect();
    }
}

...

fnCancelselect = cmdCancelselect->function;
cmdCancelSelect->function = newCancelselect;

@Bacsu
Copy link
Author

Bacsu commented Nov 22, 2016

Its not working for the GameMenu (mainmenu).
The code itself works. But it looks like the command "cancelselect" itself isn't used to trigger the GameMenu. void newCancelselect(void) get only callled if the command cancelselect is typed at the console. It will block the console bound key if cancelselect is replaced with toggleconsole.

typedef void(*xcommand_t) (void);

typedef struct cmd_function_s
{
struct cmd_function_s *next;
const char *name;
xcommand_t function;
const char *description;
qboolean pure;

}cmd_function_t;
cmd_function_t* (*pfnGetCmdList)(void);

xcommand_t fnCancelselect;

void newCancelselect(void)
{
ConsolePrint("step2 \n");
//fnCancelselect();
}

//Used it here to be sure the consolepanel is already there and everything will be printed inside.
void TeamFortressViewport::Initialize( void )
{

int i = 0;
for (cmd_function_t *cmd = (cmd_function_t *)gEngfuncs.GetFirstCmdFunctionHandle(); cmd; cmd = cmd->next)
{
	i++;
	char message[512];
	sprintf(message, "%d function: [%s]  \n", i, cmd->name);
	//CenterPrint(message);
	ConsolePrint(message);
	if (!strcmp(cmd->name, "cancelselect"))
	{
		fnCancelselect = cmd->function;
		cmd->function = newCancelselect;
		ConsolePrint("step1 \n");

	}
}

@tschumann
Copy link

Nice - I was kind of expecting it to not be that easy to hook ESC.

@Bacsu
Copy link
Author

Bacsu commented Nov 30, 2016

Maybe there's a misunderstanding. The ESC key doesn't work. Equal which command is bound to it. The updated member function works if you type "cancelselect" at console. Thats what i mean with "The code itself works." My bad i havn't written it more detailed.

@tschumann
Copy link

Oh I see.
I think in Source engine games commands sent from VGUI are prefixed with "engine" so a VGUI menu button that executed the "screenshot" command would send "engine screenshot" to the engine (I think) - possibly GoldSource does something similar?
Or possibly ESC has some special hard-coded rules in the engine - I don't know.
@SamVanheer (https://github.com/SamVanheer) knows quite a lot about the internals of GoldSource - possibly he knows a way around this?

@SamVanheer
Copy link

SamVanheer commented Dec 3, 2016

Based on what i'm seeing in the engine, the engine explicitly handles the escape key and never lets the client deal with it. You are notified of it in HUD_Key_Event, but you can't choose to handle it yourself.

See keydefs.h, K_ESCAPE.

@Bacsu
Copy link
Author

Bacsu commented Dec 3, 2016

maybe a interface i.e. baseui001 or gameui007 would be able to handle it?

@SamVanheer
Copy link

I checked that, the input system passes the key event into baseui001 first, which then forwards it to gameui007. It doesn't even pass the event into the client dll when opening the menu, it only seems to happen when you close it.

@SamVanheer
Copy link

In case you didn't notice, i replied to your thread: http://twhl.info/forums.php?thread=19163&page=last

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants