Missing voice commands for doorway and other door

[madmaximus101]

I think i've found another missing voice command. Again it's an uncommon situation.

If you are looking through multiple doorways, you are given the option for doorway being option 1 then other door being option 2.

I've tested this feature and it seems to only give me options for 2 doors to be considered in the command menu even if a hallway or angle is enabling me to look through 3 doors or more. Will test this further to see if more than 2 doors becomes an option and update if i find anything.

I tried different voice commands to try and get them to use either door for breach and clear - didn't work. Ordering them to breach and clear or stack up (whatever commands are avaiable at said door) like normal would make them go to the first door.

[jwebmeister]

Yep, I'm aware of the issue, but I don't think it can be effectively solved from just Tacspeak.

Short version:

• It's a trade-off.
• If I add the option to interact with multiple doors, it'll undermine the accuracy of regular door interactions (raycasting through only one "door"), which occurs the vast majority of the time.

Longer version:

• Same as short version + ...
• Without opening the command menu first, you (the player) most likely wouldn't know that you're looking at two or more "doors" (can be empty spaces, wherever there's a move and clear option), and thus wouldn't know to tell Tacpeak which "door" to interact with.
• Even in cases when you (the player) are aware of there being two or more "doors", you have to align at the correct angle and position to raycast through both "doors", and have the option to look through just one "door" fairly easily by moving the mouse slightly.
• This is an issue far more effectively solved via changes to the in-game command menu / user interface = feedback for Void.

[madmaximus101]

So if this is implimented it will muckup standard commands for doors as it is, unless you figure out a way so it doesn't - im guessing that would be very tedious. Whelp, i'm more than happy for this thread to be deleted or closed if you'd like.

[jwebmeister]

I don't want to close this issue just yet.

There is a way to do it, I've already done something similar for "trapped" doors (though it is simpler), just need to apply the same methodology to "near" and "far" doors.

I'm fairly confident in my prediction there will be a significant enough drop in speech recognition accuracy that it won't be worth it, but it should be easy enough to implement that it's worth implementing and testing anyway, in-case my prediction is wrong.

[madmaximus101]

Is it possible to add voice lines that are only listened for if the doorway 1 & other door 2 options are available? if said commands aren't available in the command tree it will ignore those specific voice commands completely? I'd be willing to test what you come up with. I have no idea how or what to type to muck around with this myself unfortunately.

These 2 commands are at the top of the command menu. I can think of some example voice commands like "First door breach and clear" or "other door breach and clear" "door one breach and clear" "door two breach and clear" etc.

[jwebmeister]

In the short term, I’d like to test a copy of the current breach and clear + door commands just preceding “door” with either “near” or “far” (or “other”) which will basically presses 1 or 2 before the other commands. I’m assuming it’s the same keys after you select the near or far door, though if you have a screenshot of the commands list after selecting near or other door, that’d be very helpful.

In the future, bringing context from Ready or Not (and other apps) into Tacspeak is part of the (potential) work described in issue #14 . I think it would address any potential drop in speech recognition accuracy, among other benefits. However, it’s not easy to implement and to do properly requires application integration (i.e. void devs).

[madmaximus101]

i have discovered a bit more, depending on the "type" of door? either that or it's a mistype or intentional on the devs part of their interpretation of what kind of door/hallway? In the same map the same command menu "type' if u wanna call it that has them named in different ways. Notice this says Door whereas the previous pic i showed says Doorway??

Here i have pics showing the different names given to seperate doors. On the same map no less & in the same building. Groundfloor and Firstfloor. Aswell as pics of showing what the commands look like with the second door open & closed.

[jwebmeister]

i have discovered a bit more, depending on the "type" of door? either that or it's a mistype or intentional on the devs part of their interpretation of what kind of door/hallway? In the same map the same command menu "type' if u wanna call it that has them named in different ways. Notice this says Door whereas the previous pic i showed says Doorway??

Here i have pics showing the different names given to seperate doors. On the same map no less & in the same building. Groundfloor and Firstfloor. Aswell as pics of showing what the commands look like with the second door open & closed.

This is brilliant! Thank you very much! It's a lot clearer now. Well, you're brilliant, the issue is a pain in the neck for Tacspeak.

I'll need to think a bit deeper on a short-term solution (i.e. no changes in-game from Void), more than I was planning. Thinking out-loud:

• should "hallway" or "doorway" be keywords that are different from "door"?
• the only difference between "hallway" and "door" in terms of button presses is the "cover" option, is it worth a potential loss in speech recognition accuracy?
• is "hallway" and "door" the only types, or are there more?

Not sure when I'll get around to actioning this, it's up for anyone else that may be interested in implementing + testing it. I'm half hoping the problem will go away via other avenues, e.g. feedback to Void.

As I said, it's up for anyone else that may be interested in implementing + testing it, otherwise I'll leave the issue open but park it for now.

[madmaximus101]