ATC MENU FILTERING
-
@viper-0 said in ATC MENU FILTERING:
@mav-jp We advocate for realism. As we would say among our wing, if you make a bad communication, check, correct and speak. Without filtering, please.
I agree: voice communication.
It would increase realism
-
In any cases I suggest not to removes “lines” or “menu pages” depending on flight phases.
If we do so, it will break any Voice Activation software.See what I mean?
-
I’m not sure I understand what the suggestion is:
- Remove unavailable options from the menu?
- Leave all options and sorting as is but don’t “grey out” the options even if the call is unavailiable?
If its 1, then I would vote against since it will make voice comms software useless. If its 2, then sounds good! Although this will increase the amount of questions “why does this not work?” among players.
-
Apparently this new forum structure doesn’t provide a ‘polling’ option.
I think the arguments FOR continue filtering outweigh the arguments against filtering.
-
@kiwi said in ATC MENU FILTERING:
I don’t think “realism” is the right lense to look at the filtering feature. There is no keyboard comms menu irl, period. Whoever is going for realism, will be using voice recognition or human AWACS/tower. Whether the menu is filtered or not does neither increase nor decrease BMS realism. In the end, typing Q-1 instead of asking AWACS for a picture will never be realistic nor immersive. It is simply a UI
workaround for not having voice recognition or human AWACS/tower.Therefore, I think you should just leave the filtering in as it help new players. Imho even removing it is time that could be spent more meaningfully elsewhere. What some members suggested, i.e. making filtering on/off a setting sounds like overkill and a waste of resources.
It MAY make sense to enable all commands, but display the filtered entries in a different color to simply indicate that these aren’t useful in this particular moment. That, of course, adds the complexity you would need to add to cover “wrong” radio calls. While that may be a thing irl, I believe it is not a much needed feature.
^^ This!^^
I agree that the filters should remain. Personally, I use @SemlerPDX’s superb AVCS voice recognition system for immersion. I almost can’t live without it! The menus are just a backup/confirmation that my voice commands executed properly. Changing the menus would, in this case, just be wasted effort - the juice isn’t worth the squeeze. And I fear it would break more things than it fixes.
@Mav-jp, let’s work on improving the overall voice comms in the game for best immersion. I’m ready to help with that!
Regards,
Tomcattwo
(VoiceClone) -
@tomcattwo You’re not speaking about the same thing here…
@Mav-jp is mentioning about the Comms menu being greyed out when you’re not on the right page for the right ATC freq…
-
@sobad said in ATC MENU FILTERING:
Apparently this new forum structure doesn’t provide a ‘polling’ option.
I think the arguments FOR continue filtering outweigh the arguments against filtering.
It has polling option and the poll is on the first post of this thread
-
refresh the page if you don’t see the poll…
-
@mav-jp
@dee-jay said in ATC MENU FILTERING:In any cases I suggest not to removes “lines” or “menu pages” depending on flight phases.
If we do so, it will break any Voice Activation software.Related to this – consider opening a socket or named-pipe for thirdparty apps to invoke callbacks…? just a stream of newline-delimited strings, would probably suffice.
Maybe even RegisterWindowMessage/WM_USER messages would be easier. (And then, do a pass to ensure all the necessary callbacks exist … iirc the newer ATC and carrier-ops comms aren’t implementend as callbacks today?)
Then you won’t be locked in to the current menu layout … and supporting eg. SendInput(“t,t,t,t,4”) as an unbreakable interface contract.
-
@maxwaldorf said in ATC MENU FILTERING:
refresh the page if you don’t see the poll…
EDIT: Refreshing worked
(turning off my adblocker reloaded the page, the reload was the real ‘fix’) -
I like that I can’t remove/ install the safety pins on the once in the air - would this be changed?
-
@dee-jay said in ATC MENU FILTERING:
Besides, IRL, you do not mistaking “Request departure clearance” with “Inbound for radar vector” … if so, it is time to see an neuronal specialist.
I can assure you they don’t want to be involved.
-
Why don`t make it optional?
-
@maxwaldorf - You hit the nail on the head. No “polling” display was showing on my desktop computer, but when I refreshed the page, it suddenly appeared. Thanks. Voted.
Zeus, I don’t have any ad-blocking on my system, and the poll display still did not display.
-
@sobad
Ah, turning off my adblocker reloaded the page. It was the reload that fixed it. Thanks! -
@dee-jay said in ATC MENU FILTERING:
In any cases I suggest not to removes “lines” or “menu pages” depending on flight phases.
If we do so, it will break any Voice Activation software.See what I mean?
that’s actually my biggest concern too
-
@hilok said in ATC MENU FILTERING:
@dee-jay said in ATC MENU FILTERING:
In any cases I suggest not to removes “lines” or “menu pages” depending on flight phases.
If we do so, it will break any Voice Activation software.See what I mean?
that’s actually my biggest concern too
What concern?
Keep filter = status quo
Remove filter = display all ones non grayed outDon’t overthink
-
Voice-assist programs surely count pages but don’t actually read the screen. The pages could be decluttered so as to remove the page options without skipping any pages. A page without any options would still be in the rotary but instead be blank/minimum size. If options 1, 5, and 7 were the only available then the page could be only 3 items tall. If lists and boxes can be variable height and contents it might be worthwhile for decluttering purposes.
As for having all options available at all times, it’s interesting from a realism point of view. Certainly you can say anything at any time. It would be necessary for the AI to respond in a reasonable way to “wrong” messages which were previously impossible. DCS for example simply doesn’t respond at all if you are 1mm outside of the pre-takeoff area and that’s extremely frustrating and confusing. I would certainly hope that if all-message-any-time is implemented that at least a simple reply message is used to indicate some kind of feedback.
I don’t particularly mind either way if one can gain “magical information” about the ATC system based on whether option is white/gray. ATC is necessarily simplified because the controller is not a thinking human. This could have other consequences though tactically like A-M-T which is gray/white depending on if player sensor is over valid target or not. I don’t know if any of that gray/white magic information could be considered cheating but certainly removing that information puts a bigger burden on the player to know the system inside and out.
Ah I can think that checking for wingman reply and seeing all gray is a cheating way to know he is shot down. That’s kinda lame and it would be nice not to know that info magically.
-
@frederf said in ATC MENU FILTERING:
ATC is necessarily simplified because the controller is not a thinking human
I’m offended!
-
@airtex2019 said in ATC MENU FILTERING:
@mav-jp
@dee-jay said in ATC MENU FILTERING:In any cases I suggest not to removes “lines” or “menu pages” depending on flight phases.
If we do so, it will break any Voice Activation software.Related to this – consider opening a socket or named-pipe for thirdparty apps to invoke callbacks…? just a stream of newline-delimited strings, would probably suffice.
Maybe even RegisterWindowMessage/WM_USER messages would be easier. (And then, do a pass to ensure all the necessary callbacks exist … iirc the newer ATC and carrier-ops comms aren’t implementend as callbacks today?)
Then you won’t be locked in to the current menu layout … and supporting eg. SendInput(“t,t,t,t,4”) as an unbreakable interface contract.
Not that it wouldn’t be nice, and if done, I’d use it in place of “t,t,t,4” or w/e - but if time was better spent elsewhere, my vote would be to leave it as is and not bother.
Most important to someone like me who makes systems to interact with these lists is to have a predictable list even if it was altered on-the-fly by current environmental states such as radio channels or location (ground/air). I’d want any errors such as commands that could not be issued to end with the Radio Menus GUI gone from the screen as if a correct number/action had been pressed (even if not on that current list).
What I mean is if page 4 of a radio menu list looked like…
1. Do This 3. Do That 7. You up?
…then, it helps prevent issues if pressing 4 will make the menu go away even when 4 is not a valid action or even listed, just like pressing 1, 3, or 7.
If menu item 2 was not available, so long as menu item 3 did not become 2 (as a keypress), then it is no matter to folks already using keypress macros for their apps.
Also, would never want that Page 4 to move an action (for example) “7. You Up?” to some other page for consolidation (like Page 3) based on some environmental state like radio channel or ground/air location, etc., unless it was predictable and dependable.
AFAIK, these are in no danger of going away, tho - would love callbacks for each comms action if they did - but those are the types of things I’d want to expect when making interactive systems like AVCS4 BMS, or maybe even custom hardware controllers, to keep it simple and predictable.