Announcement

Collapse
No announcement yet.

System toggle awareness? (hardpoints, lights, landing gear, etc.)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • System toggle awareness? (hardpoints, lights, landing gear, etc.)

    Sorry if this has been asked before but will there ever be any "systems awareness" for toggles built in to the profiles.

    Wayyyyy back when I built a primitive profile that set a "status" for when things like the landing gear was down, and if it was, and I said "lower landing gear" it wouldn't raise it, but would respond with "already lowered" or something to that effect.

    Is there a way to integrate this into the HCSVP's?

    EDIT: On further inspection, I see that Booleans are being set for these things, but seemingly not used to verify the state of the toggle within the command itself. I rigged a very crude "if false then toggle and set true" | "if true then do nothing" type of (probably profile-breaking) conditions, but is there a way to get this kind of check built properly into the profile?

    EDIT 2: Okay, I've been playing around with this and I need someone to tell me why this wouldn't work and my logic is flawed and terrible because I am a poopoo coder (we'll use Hardpoints as an example):
    ---
    Boolean
    Code:
     "Hardpoints Deployed"
    ---
    Variable Set Commands (VAR)
    (These are just for convenience of using the "execute command" vs. having to set variables each time, they can also be used to manually reset the boolean for things like SRV deployment, etc.)
    ((VAR - Hardpoints Deployed - True))
    Code:
    Set Boolean [Hardpoints Deployed] to True
    ((VAR - Hardpoints Deployed - False))
    Code:
    Set Boolean [Hardpoints Deployed] to False
    ---
    Key commands
    ((Hardpoints))
    Code:
    Begin Text Compare : [edDeployHardpointToggle] Has Been Set
        Press variable key(s) [edDeployHardpointToggle] and hold for 0.1 seconds and release
    Else
        Press U key and hold for 0.03 seconds and release
    End Condition
    Begin Boolean Compare : [Hardpoints Deployed] Equals False
        Execute command, '((VAR - Hardpoints Deployed - True))' (and wait until it completes)
    Else
        Execute command, '((VAR - Hardpoints Deployed - False))' (and wait until it completes)
    End Condition - Exit when condition met
    ---
    Variable Action Commands (VARCMD)
    (These are to be used for the "intent" of the parent command)
    ((VARCMD - Deploy Hardpoints))
    Code:
    Begin Boolean Compare : [Hardpoints Deployed] Equals False
        Execute command, '((Hardpoints))' (and wait until it completes)
    End Condition
    ((VARCMD - Retract Hardpoints))
    Code:
    Begin Boolean Compare : [Hardpoints Deployed] Equals True
        Execute command, '((Hardpoints))' (and wait until it completes)
    End Condition
    ---
    Spoken Commands
    (Here's a few examples of how the spoken commands do the checks)
    Deploy Hardpoints
    Code:
    Begin Text Compare : [Game state] Does Not Equal 'normal space'
        Execute command, '((command ignored))' (by name) (and wait until it completes)
    End Condition - Exit when condition met
    Begin Boolean Compare : [Hardpoints Deployed] Equals False // Check for variable
        Execute command, '((VARCMD - Deploy Hardpoints))' // Another redundant check that won't accidentally retract if deployed (makes more sense in other commands)
        Execute command, '((RS - Hardpoints Deploy))' (by name) (and wait until it completes)
    Else
        Play sound, '{VA_SOUNDS}\hcspack-KATE\Weapons\Weapons free.wav' // This just provides verbal feedback the command was accepted
    End Condition - Exit when condition met
    So this is the standard deploy command, it is impossible to retract hardpoints by accident with this command. The only reason for the extra boolean check in this specific command is to modify the audio output if the hardpoints are already deployed.

    The underlying method makes more sense with the "red alert" command for example:

    ((Red_Alert))
    Code:
    Begin Text Compare : [Combat_alert] Equals 'Red alert'
        Begin Boolean Compare : [Skip] Equals False
            Pause 4 seconds
        End Condition
        Set Text [Combat_alert] to 'Not Set'
        Execute command, '((VARCMD - Deploy Hardpoints))' // this will ensure the hardpoints won't retract if already out
        Execute command, '((RS - Hardpoints Deploy))' (by name) (and wait until it completes) // the audio will still happen regardless, inconsequential
        Pause 2 seconds
        Execute command, 'attack protocol alpha' (by name) (and wait until it completes)
        Set Boolean [Skip] to [Not Set]
    End Condition
    So instead of doing a boolean check in every command that intends to deploy hardpoints, it will just use the variable command with the boolean check built in.

    [deploy;] [hardpoints;weapons;] Attack protocol Alpha
    Code:
    Begin Text Compare : [Game state] Does Not Equal 'normal space'
        Execute command, '((command ignored))' (by name) (and wait until it completes)
    End Condition - Exit when condition met
    Execute command, '((RS - Attack Protocol Alpha))' (by name)
    Pause 0.3 seconds
    Set Text [Pips to set] to 'weapons shields'
    Execute command, 'power to weapons and shields' (by name) (and wait until it completes)
    Pause 1 second
    Begin Text Compare : [{LASTSPOKENCMD}] Starts With 'Deploy'
        Execute command, '((VARCMD - Deploy Hardpoints))' (and wait until it completes)
        Execute command, '((RS - Hardpoints Deploy))' (by name) (and wait until it completes)
    End Condition
    Again, by replacing every direct call to the key command with the VARCMD with the correct intention (deploy, retract) it prevents it from doing the unintended thing without having to manually check variables in every single command, and while not breaking the key command itself.

    Okay, so, first off, tell me why this is dumb and will break everything, and if not... is this something that can be integrated into the profiles in future releases??
    Last edited by SavingPrincess; 01-01-2018, 01:14 PM.

  • #2
    Without info from the game it will constantly break which is why we don't do it
    The Singularity profile - One profile to rule them all and at HCS we bound them

    You see, TheThingIs, eventually you'll be allright.

    Comment


    • SavingPrincess
      SavingPrincess commented
      Editing a comment
      Originally posted by TheThingIs View Post
      Without info from the game it will constantly break which is why we don't do it
      The only way I've been able to BREAK it is by doing the keybind manually, which can be avoided by binding the keybind as a pass through THROUGH Voice Attack itself, which opens a whole other ball of wax!

      Instead I opted to just create OVERRIDE; commands that do the thing I want and set the variables correctly regardless of their current state.

    • Gangrel
      Gangrel commented
      Editing a comment
      It can also be broken by using the control scheme default method of toggling them (ie Joystick button/gamepad button) and not a keyboard press.

    • SavingPrincess
      SavingPrincess commented
      Editing a comment
      You can get around that (not practical, but possible) by binding the joystick commands through voice attack so that they also set the variables. This is also a nice way to get the voice responses to button presses.
Working...
X