'fire' is only 1 less then a blink of an eye.
Its used as a "trigger", its gets reset beck to zero on 2 conditions. And one of those 2 conditions is always true.
When there is no target selected, and that is inmediatly after the space is pressed.
or
When the bullet, fired by the trigger 'fire" is uhh fired, and thats kinda inmediatly after you pressed spacebar too.
So, in the debugger, when the .cap is running, 99,99999 % of the time that u look at it, fire is set to zero.
The trigger to 1 is just to fast for the debugger.
Ofcourse, do not forget that this is a style element.
I always let the button be pressed uncunditional, i just let pressing the button flow into changing a variable. Later on in the sheet i test the condtion if that variable is conform to the rules of the game.
Most poeple (those i seen .caps from) make the press of the button conditinal. In this case that would be, test if there is a target, before accepting the key input. And later in the cap they are forced to use a "trigger every" or do some (in my eyes) weird condition to dissalow the bullets coming at a rate like 200 a second.
I think this lags the user input in big caps. To solve the lag, i see a lot of fire buttons set on "on press the key" and on "holding the key down". And sometimes i see key inputs get burried deep inside a sheet.
For me this dont feel well.
I think its important that, moment the player pressed fire, tha thing effective fires.
Althougt, in paced games you ofcourse need the bullets to keep coming at holding the key pressed.
Oh forget this, lol .. i guess i sound confusing again.