-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(acps): Rest of knobs/buttons on ACPs/RMPs, Ovhd panel and shared cockpit #7866
base: master
Are you sure you want to change the base?
feat(acps): Rest of knobs/buttons on ACPs/RMPs, Ovhd panel and shared cockpit #7866
Conversation
Quality Assurance Tester Report Discord : Alex R#6663 Testing Process: ####### BOTH SIDES #######
####### CAPTAIN SIDE: The controlling ACPs are either ACP1 or 3 (depending on AudioSwitching knob position) ####### ** PLEASE KEEP IN MIND ACP3 SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON NORM.**
** PLEASE KEEP IN MIND CAPTAIN'S ACP SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON CAPTAIN.**
####### F/O SIDE: The controlling ACPs are either ACP2 or 3 (depending on AudioSwitching knob position) ####### ** PLEASE KEEP IN MIND ACP3 SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON NORM.**
** PLEASE KEEP IN MIND FO'S ACP SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON FO.**
Negatives: Testing Results: Conclusions: |
Fix merge conflicts ^^ |
Wilco once at home this weekend |
QA Report Discord: alepouna Testing Process: ####### BOTH SIDES #######
####### CAPTAIN SIDE: The controlling ACPs are either ACP1 or 3 (depending on AudioSwitching knob position) ####### ** PLEASE KEEP IN MIND ACP3 SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON NORM.**
** PLEASE KEEP IN MIND CAPTAIN'S ACP SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON CAPTAIN.**
####### F/O SIDE: The controlling ACPs are either ACP2 or 3 (depending on AudioSwitching knob position) ####### ** PLEASE KEEP IN MIND ACP3 SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON NORM.**
** PLEASE KEEP IN MIND FO'S ACP SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON FO.**
Notes: Negatives:
Testing Results: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will leave some comments when I get a chance, but there are a few things wrong here and I wanted to register that straight away so it doesn't get merged first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've had a quick scan over.
Thanks a lot! I'll fix all this very soon. |
...bywire-aircraft-a320-neo/SimObjects/AirPlanes/FlyByWire_A320_NEO/model/A320_NEO_INTERIOR.xml
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I gave this a quick skim. It's been a long time and much has changed in the main project!
The captain/fo side vs AMU/RMP is implemented a little differently in the A380. It's just whichever half of the cockpit you are sitting in at the time. We should unify whatever we decide to do so the two planes work the same from the user perspective.
The A380 already has the RMPs and AMUs implemented as discrete systems with bus communication between them in typescript with failures for each component, and I was intending to bring this to the A320 digital RAIM later (3d modelling is in progress for that as well).
I've added a couple of issues that need addressed, and a couple of notes below.
} | ||
}); | ||
|
||
/** | ||
* MLS IMPLEMENTED IN THE XML BEHAVIOURS | ||
* BUT DISABLED HERE SINCE THERE IS NOT ENOUGH REFERENCES |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: We will never implement MLS as it's obsolete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True! Was commented out but I suppose the rebase wasn't that successful. It's fixed.
Also, I'm keeping MLS tag since the it's written MLS everywhere in the code but it should be GLS in the future. Will it be implemented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The GLS button is already there alongside MLS in the cockpit. GLS will be implemented in time with a new MMR implementation. I will be a bit busy for the next couple of months though. It will need external nav database support first as MSFS does not have any GLS data. Navigraph also does not provide the GLS FAS data... it's only in the latest ARINC424 standards.
|
||
const [APPR] = useSimVar('L:A32NX_FCU_APPR_MODE_ACTIVE', 'bool'); | ||
const [AP] = useSimVar('L:A32NX_AUTOPILOT_ACTIVE', 'bool'); | ||
const [RA1] = useSimVar('L:A32NX_RA_1_RADIO_ALTITUDE', 'number'); | ||
const [RA2] = useSimVar('L:A32NX_RA_2_RADIO_ALTITUDE', 'number'); | ||
const [, setCourse] = useSimVar( | ||
props.receiver === TransceiverType.VOR ? `K:VOR${index}_SET` : 'L:A32NX_FM_LS_COURSE', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RMP should never write FM vars (or any other system's vars).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then I have to refactor it now the Rust code exists
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the time being, it has to be done this way (or in Rust) since the FMGC is not complete
fn read(&mut self, reader: &mut SimulatorReader) { | ||
self.ident_new = reader.read(&self.ident_id); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: this morse beeping would be a lot easier to do in typescript with SoundServer to play packets of sounds (https://microsoft.github.io/msfs-avionics-mirror/docs/sounds/soundserver). The underlying sound API is more comprehensive on the JS side. Ultimately it needs to be controlled/part of the NAV receivers (in C++) rather than the audio system, so it can be in sync with the simulated NAV radios and ident decoding. We can bring this in now and refactor/rewrite later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright sounds good. Always down to create a better code :)
Are the NAV receivers implemented in C++ already? If not, once my PRs are merged, I could work on it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’ve been working in the background a bit for a few months. Most of the time spent on research so far, especially for the MMR as it includes ILS, GLS, FLS, SLS, GPS, VOR and marker beacon all in the one unit 🤯. It also requires nav database work alongside.
Alright so what should I do? Delete this PR? 😅 |
Noooo, this is good! The 2 things to address are the NAV4 being MMR2 (ILS), and the LS course var. |
Alright! We'll discuss about it! I agree it's possible to make it more realistic. Now I am in Greece enjoying 40 degrees C, Gyros (pita sandwich) and sea food until next Sunday |
Anyway, in the mean time it would be a good idea to final test it and merge because it became VERY unmaintainable. I spend too much time rebasing. I'll create a new PR based on the updated master to address the changes |
To further clarify. While I talked about digital RAIM, we will also keep the old ACPs + RMPs as an option in the A32NX, so everything you've done for them is still 💯 . I assumed that without stating it outright before! |
@@ -92,6 +92,7 @@ | |||
1. [EFCS] Fix ground spoiler retraction after increasing TLA slightly above 0 - @lukecologne (luke) | |||
1. [FWC] Improved LDG LT memo to take into account light position - @BravoMike99 (bruno_pt99) | |||
1. [PRESS] Add pressurization system failures - @mjuhe (Miquel Juhe) | |||
1. [COMMS] Enabled all components of communications panels - @Julian [Z+2 fr en esp]#8476 (Julian Sebline) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please rebase/merge and move to 0.13.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wilco.
Been away for ages but planning to resume operations once I move to my new apartment with proper desk etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it's going to be hell. Might create a new branch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copy that, just create a draft PR and mark as ready for review when you are done.
Summary of Changes
This PR makes all buttons on ACP and RMPs work and AudioSwitching knob too.
Plus, it adds an option in the EFB making the player able to choose on which side he/she is playing. This is mainly for shared cockpit purposes. By default, the option is set to "BOTH" which means each action on one ACP is performed onto the two other ones.
You have to understand the concept:
Most of the logic been rewritten to Rust. This will be useful when failures come but more importantly, the code is meant to be usable by the 380.
Screenshots (if necessary)
References
Additional context
Discord username (if different from GitHub): julian_fbw
Testing instructions
COMM.txt
####### CAPTAIN SIDE: The controlling ACPs are either ACP1 or 3 (depending on AudioSwitching knob position) #######
To better spot the changes during the tests...
** PLEASE KEEP IN MIND ACP3 SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON NORM.**
** PLEASE KEEP IN MIND CAPTAIN'S ACP SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON CAPTAIN.**
There's a bug in the SDK or at least unwanted behaviour
There's a bug in the SDK or at unwanted behaviour
There's a bug in the SDK or at least unwanted behaviour
There's a bug in the SDK or at unwanted behaviour
####### F/O SIDE: The controlling ACPs are either ACP2 or 3 (depending on AudioSwitching knob position) #######
** PLEASE KEEP IN MIND ACP3 SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON NORM.**
** PLEASE KEEP IN MIND FO'S ACP SHOULD HAVE NO EFFECT IF AUDIO SWITCHING KNOB ON FO.**
####### ELECTRICITY CHECK #######
####### MORSE CHECK #######
For this you will have to open the behaviors window and local variables tab.
How to download the PR for QA
Every new commit to this PR will cause a new A32NX artifact to be created, built, and uploaded.