feat(A380X/mfd): ATCCOM request page sub header

[EA888-3B]

Summary of Changes

Added ATCCOM REQUEST page menu sub headers(Its a header? bc its alwayse there). Using logic from FMS header. Also added a left pointing triangle. Please let me know if you guys like this format and logic. Styling and positioning has not been done yet.
If you guys like it. I will continue with this format and create every page under ATCCOM Request. (there is a lot)

Screenshots (if necessary)

References

From A350 MFD manual. PM me for pictures

Additional context

Have not tested yet. Im trying to figure out how to open the whole MFD in ACEv3. Any help would be appreciated. Pardon if there is any mistakes or error, Im new to msfs here and still learning.

Olympus593

Testing instructions

How to download the PR for QA

Every new commit to this PR will cause new A32NX and A380X artifacts to be created, built, and uploaded.

1. Make sure you are signed in to GitHub
2. Click on the Checks tab on the PR
3. On the left side, find and click on the PR Build tab
4. Click on either flybywire-aircraft-a320-neo, flybywire-aircraft-a380-842 (4K) or flybywire-aircraft-a380-842 (8K) download link at the bottom of the page

[heclak]

Hi! As mentioned on Discord, a few of us are working on the ATCCOM pages and some coordination probably needs to take place so we're not pushing duplicate files. eg. the dropdown menu format you're using for the request header is going to be a duplicate of the person working on the report and modify page, etc. It would be a problem when trying to merge all the PRs.

Maybe this should be a standardised UI object as a standalone PR first, or maybe an extension of the DropDownMenu? We can look into finalising the styling and functional requirements of this across the A380 MFD so individuals don't need to edit this function later on which might break someone else's PR. This should include styling too.

Should also be using the A380 manual instead of the A350? From the A380 docs, there is an ADD TEXT feature that isn't in your header. The header is also dynamic based on the ATC Center function. A623, Fans A, Fans B.

I'm not sure if having a new page for every single request would be the most correct way to do it. Looking at the existing ATCCOM code, which the original request was to look at porting, I don't think separate pages is the correct function of the request page. The request uses frames that can be stacked up to 5 frames per request. I believe our last discussion with the dev working on it is progress is coming along so additional coordination needs to happen as more people are starting to work on the ATCCOM section. I don't yet know the final solution to this, I've only been drafting the departure request page for the initial build of the ATCCOM system. But definitely something to discuss before proceeding.

[EA888-3B]

Hi! As mentioned on Discord, a few of us are working on the ATCCOM pages and some coordination probably needs to take place so we're not pushing duplicate files. eg. the dropdown menu format you're using for the request header is going to be a duplicate of the person working on the report and modify page, etc. It would be a problem when trying to merge all the PRs.

Maybe this should be a standardised UI object as a standalone PR first, or maybe an extension of the DropDownMenu? We can look into finalising the styling and functional requirements of this across the A380 MFD so individuals don't need to edit this function later on which might break someone else's PR. This should include styling too.

Should also be using the A380 manual instead of the A350? From the A380 docs, there is an ADD TEXT feature that isn't in your header. The header is also dynamic based on the ATC Center function. A623, Fans A, Fans B.

I'm not sure if having a new page for every single request would be the most manageable. Looking at the existing ATCCOM code, which the original request was to look at porting, my initial thoughts was to look at mimicking a similar technique based on how the ATSU logic works later on (which is why the request page was delayed). I believe our last discussion with the dev working on it is progress is coming along so additional coordination needs to happen as more people are starting to work on the ATCCOM section. I don't yet know the final solution to this, I've only been drafting the departure request page for the initial build of the ATCCOM system. But definitely something to discuss?

Yeah I didn't noticed the other ATCCOM folder until yesterday. I agree with making a single page for every option would not be efficient, but put it all together might be challenging as well. There's lot of different pages with different type of inputs😅😅. However there's also OTHER REPORTS from REPORT&MODIFY tab. Maybe some of them will share same components or values? But yeah right now definitely wait for the dev updates and go from there,as well as more discussions👍

[heclak]

I agree with making a single page for every option would not be efficient, but put it all together might be challenging as well. There's lot of different pages with different type of inputs😅😅

The single page system (if i understand correctly) is how the IRL A380 request page works. It's a Lego block system where you craft a frankenstein form of your choice with the various fields. It does need to be a singular form as there are conditionals where you can't put conflicting frames together within the same request. Eg. the climb frame cannot coexist with the descend frame. I think it's better to let the ATSU prototype be finished with the logic working before tackling the full request page. Or there might be a lot of rewriting of the code later on.