fix(fms): use entered fob rather than fqi before start

[patmack14]

#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.
2. Engine !Running -> Pull from entered block fuel
3. Also added some class and method comments noting where top level parameters originate from...spent many hours on a wild goose chase on this PR! Recommend inserting into docs somewhere down the line.

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.

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 or flybywire-aircraft-a380-842 download link at the bottom of the page

[patmack14]

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!

[tracernz]

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.

[patmack14]

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:

1. There are getGrossWeight() and getGW() ..are these used for different reasons? seem to have somewhat repeated functionality.I can certainly condense both of these or combine them ( if that makes sense).
2. Regarding the type:
   Rather than going down a type checking rabbit hole I was thinking of doing something like

//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.

[tracernz]

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.

[patmack14]

@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.

[BlueberryKing]

Careful, what happens if you've not entered a block fuel yet?

[patmack14]

Hmm Yes Thanks for catching

Can the way the current aircraft release handles this scenario be used as a "control" or do the IRL pilots need to be consulted for what the behavior is in this situation?

[BlueberryKing]

Hmm Yes Thanks for catching

Can the way the current aircraft release handles this scenario be used as a "control" or do the IRL pilots need to be consulted for what the behavior is in this situation?

I'd have to check the places this function is called from, but replicating the current behavior would be a good starting point.

[patmack14]

OK Sounds good.

[2hwk]

@BlueberryKing to approve as well

[patmack14]

@BlueberryKing
Wanted to check in with you on this to see if you have had a chance to review this and see if it needs a few more tweaks or able to move to test?
Thanks!

[BlueberryKing]

I suggest we move this if block to the block further down where currentFob is used.

[patmack14]

@BlueberryKing
Thinking you mean like this? (Removing line 106->108 and adding to Line 130)

            currentFob = formatWeight(NXUnits.kgToUser(mcdu.getFOB()));
            if (currentFob) {
                fob = `{small}${currentFob}{end}[color]green`;
            }
        }`

[BlueberryKing]

You can remove these lines (106-108) now, right?

[BlueberryKing]

I don't think checking for this.blockFuel works here. With an engine running, the gross weight should be available (since fuel is available from FQI) even if no block fuel is entered.

What I suggest is fetching this.getFOB() and checking whether that's finite instead.

Also, I prefer Number.isFinite over isFinite since isFinite(null) is true which is rarely desired.

[patmack14]

//Does this work? I removed unnecessary else block for simplicity sake as well since fmGw already is at 0.

getGW() {
        let fmGW = 0;
        const currFob = this.getFOB();
        //Simplified to just checking fuelWeight as GetFOB handles what fuel level to use (block vs tank reading)
        if (Number.isFinite(this.zeroFuelWeight) && Number.isFinite(currFob)) {
            fmGW = (currFob + this.zeroFuelWeight);
        }
        SimVar.SetSimVarValue("L:A32NX_FM_GROSS_WEIGHT", "Number", fmGW);
        return fmGW;
    }

[pilotseyea350]

Quality Assurance Tester/Trainee Report

Discord Username : PilotEyesA350
Object of testing : #8664
Aircraft : A32NX
Tier of Testing : 1
Date : 20/09/2024

Testing Process:

1. Power Aircraft Up
2. Enter EDDF/EDDM in INIT A
3. Enter random DEP & ARR RWY & random SID/STAR
4. Delete any discontinuity
5. Refuel Aircraft through the FlyPad
6. Enter a higher FOB in INIT B than there actually is in the fuel tanks
7. Enter data in PERF
8. Verify EFOB at EDDM
9. Start any of the 2 engines
10. Check EFOB at EDDM has decreased compared to EFOB before engine start

Testing Results:
Passed

Negatives:
N/A

Conclusions:
Worked like a charm, thanks for your hard work !

Media:
N/A