lukeXIII

Those calculations look right. To add on to this there should also be separate calculations for take off and landing. At the moment one calculation is done for both, and both VTO and VL are boxed at the same time on the VREST page (should only be one boxed at a time). The individual calculations would then be: VTO page: Max F+W = (0.97 * Max Hover Weight) - (Gross Weight - Fuel - Water) VL page: Max F+W = (0.95 * Max Hover Weight) - (Gross Weight - Fuel - Water) @myHelljumper

The JPT with water flowing is lower than it should be at the relevant rpm. This means that the JPT with water is usually always lower than the Limit which results in an overperforming engine. An example using the JPT in hover chart from NFM-400 compared to ingame: Conditions: 35 C, 29.92 inMg When using no water, an RPM of 113.5% should result in a JPT of 788 C. Ingame the JPT is approximately 788 C so this is correct. When using water, an RPM of 113.5% should result in a JPT of 766 C. Ingame however the JPT is approximately 727 C so this is incorrect. The JPT when wet should be approximately 22 C lower than dry, however ingame the wet JPT is about 50 C lower than it should be. This means that the engine can incorrectly reach higher RPMs when wet before hitting the JPT limiter.

Tested after latest openbeta update, issue still exists. Only tested with dry conditions as there seems to be something wrong with the wet JPT. JPT_limiter.trk

Pretty much working correctly now. Only thing left I've seen is that NWS/Undesignate isn't unboxing DESG.

Short lift dry/wet JPT limits are 780 and 800 degrees respectively, which can only be sustained for 15 seconds. In the above example (dry conditions) the temperature is 808 degrees, so the limit has been exceeded by 28 degrees. "Max JPT" seen in the ENG page is just a record of what temperature the engine has reached, it is not a limit.

With JPTL on, the engine fuel system should reduce rpms as the short wet/dry limits are met (NFM-000 11.9.2 JPT Limiter). However this is currently not working, rpm is not being limited (outside of normal rpm limits) and the JPT can exceed limits.

It seems like its been coded so that the RPM and JPT values always disappear after dry conditions are met (e.g 107% rpm) which is fine when water is not being used. However when wet conditions are being used this is causing no display to occur between the dry and wet limits.

Each leg of the JPT hexagon should represent 10 degrees from 715-780 for dry and 735-800 for wet. However it is currently using 1 degree segments instead (like the RPM hexagon) so you basically only ever see the hexagon maxed.

To summarise some info from the NFM-000 (23.9.40 Quick Access, 23.19 HUD Steering): Any system designation that is created or moved is always stored into T0, for example if a waypoint is designated or whether a target is designated through the HUD. As the EHSD/HUD is always navigating towards the currently selected steer-to-point (STP), the STP will need to be changed to T0 so that the HUD steers towards the system designation. This can be done by holding waypoint increment which initialises quick access mode and selects T0 on the EHSD if a system designation exists. An important distinction to make is that holding waypoint increment does not create T0 but simply changes the EHSD STP. With a system designation existing and T0 selected on the EHSD, DESG should be boxed with "STP" and the waypoint circle should be replaced with a designation diamond. Moving the system designation should automatically update T0 and DESG should still display "STP". The issues with the current implementation is that the system designation and T0 are being treated as separate and can exist in separate locations (they should always be in the same place). T0 is incorrectly only being updated if the TDC is pressed or if waypoint increment hold is used. This means that DESG can be displayed as TGT even if T0 is the STP, and the waypoint circle and diamond is displayed at the same time (see attached image). In short: -The system designation should always be stored into T0 and updated if moved -If a designation exists and T0 has been selected on the EHSD then: -DESG should always be boxed as "STP" -the waypoint circle should be replaced with the designation diamond

From the NFM-000 The heading bug is currently not wind corrected and is just simply pointing in the direction the waypoint is at. It should instead be showing the heading you need to fly such that the course intercepts the waypoint.

Those charts are basically already showing engine thrust (hover thrust is equivalent to the hover weight in lbf). For a 0 datum engine in standard conditions, max hover thrust wet is around 21,000 lbf at 116.8% rpm and dry is around 20,000 lbf at 113.5%.

The engine thrust is much less than 23800 lbf at 105% rpm. Also, thrust does not increase linearly with rpm. The data for the hover charts is directly from flight tests, so yes you do need that rpm to lift off at that weight. It looks like you are using the chart incorrectly. Using the charts with standard conditions (15°C and 29.92 inHg) you do not have to make any corrections to hover weight or fan speed. Basically all the lines you follow are horizontal and vertical. The lowest fan speed on the chart for the 408 engine is 98%, which indicates that you are using the wrong chart (the 406 engine chart).

The SDAT page is not required if you create manual target points.

That is not correct behaviour for the harrier we have. If you read what I had quoted, TOO functionality has been expanded to store the system designation if it exists. Target points do not have to be "accepted" through the SDAT page. That page is for transferring external data into the system e.g transferring a target point from the mission card into the system's target point.

From the NFM: And from the point blank patch notes: All designations are stored into T0 when created. If AUTO mode is working for point blank (without entering "designation mode") because T0 has been created, then AUTO mode should work FOR EVERY OTHER DESIGNATION. The manual also states that DESG becomes boxed as TGT if anything other than the steerpoint is designated.

Targetpoints created through any means other than ATHS cannot be entered into JDAMs JDAM_targetpoints.trk

With POS colonised, North coordinates cannot be entered. Successive presses of POS does not allow East coordinates to be entered. targetpoint.trk

From A1-AV8BB-NFM-000: At the moment if a designation exists, using TOO creates a markpoint/targetpoint at the aircraft position instead of the system designation. On a related note, targetpoints that are created using this method are currently unable to be activated in the JDAM target list. TOO.trk

Check the NFM-000: 23.14.4 MAP Position Update (Night Attack and Radar only) The TAC-000 that is available is very outdated (it does not include h4.0 and newer upgrades) so it won't include information on DTED integration.

The legend at the top left of MPCDs should display MAP when the TDC has been assigned to the digital map. This can be done in two ways: entering the DATA page or by performing a MAP designate update. In game the TDC behaves wonky in the DATA mode and the MAP designate update is completely missing (the push button legend for UPDT is missing on the EHSD which should show when the INS is set to NAV). Also in game the legend at the top left of MPCDs incorrectly changes to MAP when SSS left is pressed, and the legend does not change to MAP when entering the DATA page. MAP designate could also refer to the Gen4 TPOD where it displays "MAP/SLV" if slaved to a waypoint.

The harrier has Digital Terrain Elevation Data (DTED) so it is possible to know the elevation using LOS angles. For INS TDC behaviour, all the literature indicates it should be behaving how it is currently implemented in the F/A-18.

These are still being treated as completely different things when they are one and the same i.e you cannot have one without the other and vice versa We've gone from: to several INS modes that now work "without setting the EHSD in DESG mode" which completely contradicts the reason for implementing these changes in the first place.

Bumping with another example

Bumping again to show this is incorrect behaviour. A simple test I've found to show conflicting information is by performing the CCIP to AUTO conversion: -With CCIP reflected impact pipper, holding the pickle button designates a point on the ground and automatically switches to auto mode. (Correct) -Prematurely releasing the pickle button switches back to CCIP mode whilst leaving the designation point. (Correct) -With the existing designation point, manually switching to AUTO mode does not give attack symbology. (Incorrect) Automatically switching to AUTO mode and manually switching to AUTO mode should give the same result which shows this whole "prepping the INS for Auto deliveries" is bogus. And just to reiterate from above posts: as long as a designation point exists, AUTO deliveries should be possible. Outside of initial INS alignment and having a designation point, not a single other aircraft requires "prepping the INS for Auto deliveries", even aircraft developed by the same manufacturer (e.g the F/A-18). ccip_to_auto.trk

Before open beta update 2.5.6.60966, taxi speed under idle thrust could be controlled by adjusting nozzle angle between 45 and 60 degrees as per the NATOPS manual. For example a nozzle angle of around 45 degrees used to give a stable taxi speed of 15 knots. Post update it is impossible to control taxi speed with nozzles less than 60 degrees. To compare above, setting the nozzles to 45 degrees will now accelerate up to and past 50 knots. It seems this fix has greatly reduced or completely removed ground friction. taxi_nozzles_45.trk