This is not a bug that you stumble into every day, but it's pretty stupid nonetheless. Doing /wait -1 will set the cmd_wait variable to -1 and then continuously decrements it until it reaches 0, which needless to say won't be for some time.
About-to-be-attached patch fixes the bug in two different ways at once, just in case.
Created attachment 2017[details]
error messages when /wait is used inappropriately
Making cmd_wait unsigned will just mean that
cmd_wait = atoi( Cmd_Argv( 1 ) )
where Cmd_Argv(1) is "-1" will set it to 4294967295, as far as I can tell. You will still need to identify and handle the negative case, which in my opinion should be treated as any other invalid input. As I see it, there are three choices in that regard:
1. ignore, don't wait (same as current for /wait foo)
2. ignore, wait for the default 1 frame (pretend the argument wasn't given)
3. print an error message
Attachment #1889[details] does 2. which is somewhat inconsistent with other invalid input (but it's trivial to make it do 1. instead)
The attachment I'm just adding now does 3. and also prints an error when other invalid input is supplied.
Created attachment 1889 [details] don't allow negative wait values, don't go crazy if they do come up somehow