[mitsubishi]

Thanks to ObScUrE and illmatic (here http://forums.urbant...post__p__257370) I believe there's been discovered a bug with +vstr:

+vstr has a check on the case of release(of the key) to avoid firing the release when bringing down the console; but that check causes the feature to malfunction if you press another +vstr bind at the duration of the first.

original source part:

                case '+':
                        v = Cvar_VariableString( Cmd_Argv( 1 ) );
                        pushed = qtrue;
                        break;
                case '-':
                        // we check this because otherwise key release would fire even in the console...
                        if(pushed) { 
                                v = Cvar_VariableString( Cmd_Argv( 2 ) );
                                pushed = qfalse;
                       }
                        break;

Example of malfunction: [Below in a reply by Nexu]


A potential solution is to remove the 'pushed' check altogether or i suppose if one wants to keep the feature, a more dynamic approach may be required to save several such binds' "pushes".



EDIT: The workaround of removing the 'if pushed' check altogether appears to be working fine.

This post has been edited by mitsubishi: 26 February 2010 - 07:44 AM

[Delirium]

I dont think its bugged at all
pretty much 95% of my keys are +vstr's and ive never had a problem so I doubt its bugged

[mitsubishi]

Delirium, on 25 February 2010 - 06:55 PM, said:

I dont think its bugged at all
pretty much 95% of my keys are +vstr's and ive never had a problem so I doubt its bugged

I've confirmed it and I've workarounded it; I'm pretty sure it's there.

You probably use binds that wouldn't care about it. e.g. I didn't notice at all till those guys mentioned it.

[|it|Nexu]

Delirium, on 25 February 2010 - 06:55 PM, said:

I dont think its bugged at all
pretty much 95% of my keys are +vstr's and ive never had a problem so I doubt its bugged

No, the bug Fateswarm pointed out does exist.

[mitsubishi]

it might require certain types of +vstr scripts; not certain if it occurs in the simplest of them.

[|it|Nexu]

mitsubishi, on 26 February 2010 - 05:30 AM, said:

it might require certain types of +vstr scripts; not certain if it occurs in the simplest of them.

Happens when you call another script while another +vstr script is active. Here is an example how to reproduce this 'problem':

set cg_fov "110" // standard value for this test

set do_zoom_on          "ut_zoomin;    cg_fov 90;  set do_zoom vstr do_zoom_off"
set do_zoom_off   	"ut_zoomreset; cg_fov 110; set do_zoom vstr do_zoom_on"

set do_crouch_on        "+movedown; set do_crouch vstr do_crouch_off"
set do_crouch_off 	"-movedown; set do_crouch vstr do_crouch_on"

bind MOUSE2 "+vstr do_zoom_on do_zoom_off"
bind ALT "+vstr do_crouch_on do_crouch_off"

Test sequence:

• Press and hold mouse2 button
• Press ALT and release it
• Release mouse2 button

Result: FOV is still 90
Expected result: FOV should go back to 110

This post has been edited by Nexu: 26 February 2010 - 07:36 AM

[mitsubishi]

ty. i'll put this reply as a better example on the 1st post.

[GlaD-slackin]

now, what if you were using three of them at once, like laser script with crouch script with fov script? would it still work, im not positive but it looks like that would max at two?