Hardpoints profile

[Incurable-Rash]

Can someone Please help me figure out what I did wrong. The hardpoints deploy to the one called out but will not keep track, and gets confused by the missing or unassigned hardpoints possible.
I tried to make a command that deploys the hardpoints and keeps track which hardpoint is deployed.
I was wondering if the command recognize what is assigned to that hardpoint.

[RedMonster]

Hey, maybe a bit of context would be helpful, which game are you playing?

You should be able to save the individual variables as a boolean data type (true/false) with a variable name similar to "hardpoint1," "hardpoint2", "hardpoint3" and so on. You can run a conditional comparison for each to determine if its deployed (true) or retracted (false or not set). Include the "not set" as part of your conditional checks to make sure you have a fallback action defined.

I've coded the CEDAR profile below for Star Citizen and it handles several state-aware variables, there's also a demo video posted here -> https://youtu.be/6EXHIH53rCY

[Incurable-Rash]

Sorry I keep leaving out which game I am making this for. Elite Dangerous is the Game I am refering to.

[Incurable-Rash]

Thank you for your response,
I was beginning to wonder if it was visible.

I also appreciate the tutorial on voice attack, even though you lost me when you got to the variables. Most of the instructions I have read are given out with the instructor vast Knowledge of the subject and what is common knowledge to them is not to a beginner.

Because I am a novice at this and it is super hard to follow the experienced folks instruction, I will do my best to see if I can make it apply to what I am trying to do.
The one thing I have found it that having separate keybinding commands that other commands refer to, makes it easy to adapt my bindings to their profiles.

Thanks again
Rash

[RedMonster]

No problem! I've got a few years of web development behind me, so I'm a bit beyond the basic programming skills.

To my knowledge, the hard points in Elite can't be deployed separately - It's all or nothing. What you may be looking at is the different fire groups available. In that case, you could really simplify your script and have just a single true/false variable to tell whether the hard points were in a deployed state or not. (Also think about disabling the "fire to deploy hard points" option in Elite to keep the variables from getting confused).

Best of luck!

[GreyArea]

I'm messing around with VA and ELite too, also finding keeping track of the state of systems very challenging when the two programs aren't offically "talking" to each other.

Thought I'd share a bit of code I found useful;

Set Text [Hardpoints-status] to '{EXP:IIF('{TXT:Hardpoints-status}'='in','out','in')}'

This is the "set text value" command using the IIF expression; it does in one line what your "hardpoints" routine is taking about ten to do; toggles it; ie sets it to "out" if they're "in" or "in" if they're "out". I use text values for status (because they work better with "Say" commands - "Hardpoints in" is easier to understand than "Hardpoints 1") but I assume you could do something similar with a numerical.

Line is so short you could even add it to the keypress so you guarantee it works every time it's called.

We need to keep trying stuff...Elite Dangerous is a title where VoiceAttack really adds enjoyment! If some REAL programmer could actually figure a way of passing the ACTUAL state variables between the Elite Client and Voice Attack...wow....that would really be something.

In the meantime I have a suffix set of commands under the "Toggle" prefix, all using the above line...for example

Galaxy Map State
Set Text [GMap] to '{EXP:IIF('{TXT:GMap}'='open','closed','open')}'
Say, 'Galaxy Map state set to {TXT:GMap}'

So "Toggle Galaxy Map State" will change the value in Voice Attack if it got confused somehow...

I also have some "Default to" group comands such as;

[Hangar;dock;docked]
Jump [ready;]

Which have some grouped system state commands so I can reset everything if I'm in a position where my ship is in a "known state"; ie docked means scoop is in, lights are off, gear is down, points retracted...

[GreyArea]

Edit; stealing one of your genius ideas...separating the keybindings out into individual commands so you can run them separately is a brilliant idea - also means you can edit them much more easily if you change things in ED than if they were just buried in the commands somewhere.

Top idea!

[Pfeil]

Set Text [Hardpoints-status] to '{EXP:IIF('{TXT:Hardpoints-status}'='in','out','in')}'

This is the "set text value" command using the IIF expression; it does in one line what your "hardpoints" routine is taking about ten to do; toggles it; ie sets it to "out" if they're "in" or "in" if they're "out". I use text values for status (because they work better with "Say" commands - "Hardpoints in" is easier to understand than "Hardpoints 1") but I assume you could do something similar with a numerical.

Binary states are traditionally stored in Boolean-typed values, for the simple reason that this takes up the fewest resources, both in storing and processing.
On top of that, because there can only be two possible values, there is a built-in function to toggle between them.

I'd recommend using the "Set a True/False (Boolean) Value" action, while using "{EXP:IIF({BOOL:Hardpoints-status}=1,'out','in')}" when you need TTS output.

a way of passing the ACTUAL state variables between the Elite Client and Voice Attack

EDDI(Elite Dangerous Data Interface) can do this for some values. It's "restricted" because anything that isn't provided by the game's developer would be considered cheating, and could get you banned.

[GreyArea]

Good info, thanks Pfeil...

One thing I meant to ask...when does a "small integer" become just "integer"...are small integers just one-digit perhaps?

I also wanted to say that I know I've only just started looking at this properly...but this is one of the most genuinely helpful community forums I've ever seen...

[Pfeil]

when does a "small integer" become just "integer"

Only when the value you need to store is larger than 32767, or smaller than -32768.

To clarify, they are different datatypes, one does not become the other when the value limits are exceeded. You choose the correct type for the intended application.

[GreyArea]

OK...we're officially beyond my level of knowledge...meaning I don't know where you'd use a small integer vs a regular one...or why...

[Pfeil]

I don't know where you'd use a small integer vs a regular one...or why...

If you only need one liter of water, you'd generally put it in a bottle, rather than a jerrycan. It's easier to carry, because it's smaller, and drinking or pouring is easier because it's much less unwieldy.
Now imagine you need to transport various liquids, up to one liter each, that should not be mixed; If you put each liquid in a jerrycan, you're going to need much more physical space to store all of them, because logically, jerrycans take up more space than small bottles.
Now, if you have a liquid which has a volume larger than one liter, you'll need to use the jerrycan just so it'll fit, there's no real way around that, but you try to keep it to a minimum.

In this metaphor, the liquid is your data, the bottle is a small integer, and the jerrycan is the regular integer(there are no intermediate sizes, in the context of VoiceAttack at least). If you put data in an oversized container, storing it will take up more physical memory, and processing it will take up more CPU time.


To be fair, in real world usage you're unlikely to run into real issues when using integers in reasonably-sized profiles, but it's good practice to use the datatype that fits, but doesn't grossly exceed, your requirement.

Within VoiceAttack, the main difference is that the "Set a Small Integer (Condition) Value" does not have built-in math features other than incrementing and decrementing, whereas the "Set an Integer Value" action does, though this can easily be worked around using the "{EXP:}" token.

[GreyArea]

OK, that's clear...small integers take up less "space", so use them where appropriate.

Thanks!

[GreyArea]

The trouble with Elite is it does a lot of "state changes" that have no input; just take "landing gear" as an example...yes, I can press "G" to raise and lower it manually. I can asign "G" to a voice command and say "Raise Landing Gear" and toggle it "up" or "lower landing gear" and toggle it down...

But when you land with autopilot on, it lowers the gear with no input.

Similarly checking the mission details opens the Galaxy Map - but VA won't "see" a "galaxy map" command....there's a whole load of stuff like that which is why I've just added in "toggle (name of state)" as a multipart command which prompts VA to just flip the token when it gets confused. Can't think of any other way...

[mikelimtw]

There are two times where your vessel is in a known state in Elite. The first is when you are docked. In this case you can be sure that hardpoints, cargo scoop are retracted, lights are off and the landing gear is deployed. When you restart out in space then everything is retracted or off. Use that information to reset/correct your variable settings in your profile. Using EDDI is a great help in this regards since it contains the state tracking you need to know what environment your ship is operating in.