Good call Jonathangersam.
Another approach could be a cycling loop system (with a wait or next frame event to prevent an infinite loop warning)
I've got a system set up like this for a shooter system. i have a monitor fsm (yes, i like monitor fsms.
) monitoring the button i want to map to the firing mechanism.
then another fsm has a state (idle) that has a get fsm bool that'll fetch the boolean value of the button pressed (set to every frame since it will sometimes sit in this state.)
once there, if it registers the boolean as being changed (by using a bool test set to always on) then it goes to the "shoot" state (where i tell it what to shoot, how fast, the usual bullet/projectile systems.) once that's done, it'll cycle back (i use a single state with a wait for .01 seconds real time since the next frame event action can produce variable times dependant on the computer running the game) and once it loops back to the idle state, the button still being pressed will still result in it being triggered so it'll loop through the shoot system.
this is more for a "bullet" kind of mechanism though so it might be different if you're looking for a "beam" kind of mechanism. if you wanted a "beam" system, i'd probably set it up with a collider and an "on/off" sort of setup in that to toggle when it's on and off and what to do from there.... or maybe a raycasting system... though since raycasts can become expensive for the CPU i do try and limit how often raycasts are performed to free up CPU power... but, maybe a raycast would be more ideal for a beam weapon... dunno... you know the phrase, there's more than one way to skin a cat? (i know, it's barbaric... but it gets the point across.)