Possible Darkplaces Glitch?

[Junrall]

Not sure if this belongs in the Engine Programming area or here...

Has anyone run into problems using "saved1" - "saved4" cvars in Darkplaces?

Whenever I plug a 1 into "saved1" I'm not able to bring up Quake's main menu by pressing the Esc key. If I plug a 0 into "saved1" or restart the map then the Esc key works.
And here is the strange thing... if I plug a 1 into a non-cvar like "junrall"... the same thing happens!

I've tried this in fitzquake085 and DirectQ and did not have the same problem as above.

[Teiman]

Confirmed here.

It seems if you put a 1 on saved1, then the game menu don't open pressing ESC.

Putting down the console once seems to clear that wrong state, so the menu can be invoqued again by pressing ESC.

[jim]

Sometimes I get that behaviour without changing that cvar to 1. Firing a weapon also fixes it, so menu is accessible again.

[LordHavoc]

I don't even understand how such a bug is possible, so I'm ignoring this.

[Baker]

I don't even understand how such a bug is possible, so I'm ignoring this.

Re-confirmed. It's truer than true! I just loaded DarkPlaces January 21 2010 version.

After doing single player --> new game ... I type "saved1 1" in console and ESC no longer pulls up menu.

If I type "saved1 0" in console, ESC pulls up menu again.

Now, if I type "saved1 1" in the console if I move a little I can pull up the menu again by pressing escape. It also occurs if I do "saved2 1" or "name 1" or "cl_bob 1". (problem if a cvar evaluates to "true"?)

This problem doesn't happen with "saved1 1.1" or "saved1 2".

Strange ... anyway this doesn't have anything to do with "saved1" ... it appears setting any cvar to 1 will cause this issue.

(I blame the Chinese! It's the infamous "denial of menu" attack they have been planning for a long, long time ...)


Update:

If you do "tell 1" or "wait 1" the menu won't come up either.

So is isn't cvar related at all but command argument related.

This somehow has to be the source of the problem ...

menu.c

Code: Select all

void M_ToggleMenu_f (void)
{
   m_entersound = true;

   if ((key_dest != key_menu && key_dest != key_menu_grabbed) || m_state != m_main)
   {
      if(Cmd_Argc() == 2 && !strcmp(Cmd_Argv(1), "1"))
         return;
      M_Menu_Main_f ();
   }

Maybe somehow the command arguments aren't getting cleared? If I type "baker 1" in the console, the menu won't come up.

[mh]

Confirmed here too with the same block of code that Baker has identified. The return condition is being triggered somehow. I haven't gone digging into the values of Cmd_Argc or Cmd_Argv yet, but will post an update when I do.

Update:

Added these before the return and set a breakpoint:

Code: Select all

char *blah1 = Cmd_Argv (0);
char *blah2 = Cmd_Argv (1);

I can confirm that blah1 has a value of "saved1" and blah2 has a value of "1".

Update 2:

cmd_args is empty here (i.e. cmd_args[0] == 0).

Update 3:

Added the same checks to a standard WinQuake build and reproduced the test. We have "toggleconsole" in blah1 and NULL in blah2.

[LordHavoc]

Very curious, but at least that makes some sense.

Clearly M_ToggleMenu_f is being called not as a command but directly, and the Cmd_Arg data is stale at this point.

It seems that div0 added this feature, but never updated the rest of the menu code to understand the difference in invocations from console or direct call.

[Sajt]

*clenches fist*
div0!!

[LordHavoc]

This may have been fixed, confirmation would be appreciated.

Sajt implemented a fix, then div0 fixed that fix, so it may be broken again