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.
-
@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.
-
Wanted to add that if some items are hidden at times, a key would be very helpful for app developers to know what is available since it could be difficult to get this information without launching into the sim and flying the jet into various states just to screenshot the menus and decipher it into a system such as I have done here for AVCS4 BMS
-
Starting out (very recently) I found the filters very helpful not only in helping me know what to do but also in visually seeing which menu I was on. I found I got used to the different visual variations between menus due to the filtering display.
Once I started using voice control however that no longer was an issue, but my vote is to keep them. I do think it would be really cool to allow mistakes though if it was corrected by the ATC as @robojones mentioned - I’d change my mind in an instant.
-
@semlerpdx Yeah absolutely. Although currently what happens when you pick a number option that corresponds with a grayed out option currently?
Direct callbacks (or similar direct API) for every single radio options would be amazing. Then voice-interaction software could skip the whole middle man segment.
-
As a MP user with Voice attack, i don’t see the screen options, so greyed out or not appearing makes no difference. Once the calling structure, i.e. command numbering and sequence does not change, since most voice profiles depend on this, then I’m happy.