Open patmack14 opened 1 month ago
Special thanks to @BlueberryKing for helping to knock some rust off(I've been on a dev hiatus) and throwing me a bone for showing me where the FOB is initially injected!
Additional things to do:
- Refactor getGrossWeight a little as it duplicates this FQI logic.
- Check that all the consumers of getFoB can handle it being undefined, as it always returned a number before. Some definitely can not, so some changes will be needed. Perhaps a new getFqiFob function could be created, wrapping the simvar read, and the fuel pred page could call it instead.
- Check that the AOC actually wants this value, or does it always want the FQI FoB? (Note that the AOC shouldn't actually directly access the FMS, as it lives in a different computer in the real aircraft, but fixing that is out of scope for this PR.)
Fix the PR title inline with https://www.conventionalcommits.org/en/v1.0.0/. Suggest
fix(fms): use entered fob rather than fqi before start
or something like that. Whatever you put here will become the commit title when this PR is squash-merged later.In general you always need to be very mindful of type safety when working on the legacy JS code, as unlike typescript there is no automatic type checking.
Have a few questions here:
//If do a null check rather than just else, it should basically retain the same functionality as original and still be undefined/NaN thus not messing with AOC and/or other unintended consequences?
else if(this.blockFuel){
return this .blockFuel;
}
Feel free to message on Discord to bounce ideas/thoughts if above does not work.
Part of the job here is understanding the aircraft systems and how things should actually work before we touch the code, as then we can understand how the code should look. That part is unfortunately much more difficult than the code. You happen to have picked an area where the gross weight calculation code is relatively simple, but the systems changes required are definitely not trivial, and spread around quite a wide area of the FMS. All of the consumers of GW/FOB should handle those values not being undefined because they really are not available prior to engine start with no ZFW/FOB entered. Some of the things getGW does look very dubious, especially setting a local var, so there's opportunity for a good clean up there too.
@tracernz
I've been thinking about how to handle this-
Would finding the AOC customers of getFob and put the same if (!engineRunning) ->return
type scheme work for everyone?
I agree handling it that way would cut back on unecesssary function calls/bouncing between classes.
8639
Fixes #[issue_no]
Summary of Changes
Added 2 lines: 1.A check to see if an engine is running->Pull from sensed fuel tank levels.
Screenshots (if necessary)
References
@BlueberryKing and @BravoMike99. As previously stated I no longer have access to the pilot Discord channel, unable to use previous verification method.
Additional context
Discord username (if different from GitHub):
Testing instructions
Prior to engine start, the Destination EFOB should be pulling from entered block fuel, after start the figure should switch over to using sensed fuel level in the tanks.
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.