lukeXIII

After some more testing I'm fairly confident that the extra waypoint that gets added is what's causing all the issues.

Attempting to fly a TOT or TTT with a non-sequential route is causing issues with the Command Speed where it instantly drops after selecting the next waypoint in the route and progressively increases until the next waypoint is reached. This happens until the final waypoint is selected. To show this I made two flight plans which are 100 nm from the initial aircraft position to the final waypoint. The single waypoint plan is used as a reference for what the CS/T should be. Initial time was 04:00:00 and TOT was set to 04:15:00. For reference the CS/T from the single waypoint flight plan was around 362 KCAS. Initial position to WP1: CS/T was around 360 KCAS and didn't change (consistent with the reference speed) WP1 -> WP2: CS/T instantly dropped to 310 KCAS on selecting WP2 and progressively increased to 370 KCAS as aircraft approached WP2 WP2 -> WP3: CS/T instantly dropped to 290 KCAS on selecting WP3 and progressively increased to 402 KCAS as aircraft approached WP3 WP3 -> WP4: CS/T stayed at 413 KCAS Some other observations whilst testing this: SEQ route not functioning NSEQ route includes waypoint before first waypoint in the ingress string e.g selecting an ingress string of W3-W4-W5 will also include W2 Selecting TTT does not show the time-to-target counting down on the UFC Timer does not count down on CS/T display NSEQ_test.trk NSEQ_test.miz

Only the air temperature issue was fixed.

Any updates on this?

From A1-AV8B-TAC-000 (pg 1-254): Currently only entries in the form of "DDD MM SS" are being accepted. The minimum required "DDD MM" will also not be accepted. All entries should be stored and displayed in the format "DDD MM.mmm" as per the DATA display and the TPOD display. The following are examples of valid entries for latitude as per the TACMAN: N3541 -> N35°41.000' N3541.2 -> N35°41.200' N3541.23 -> N35°41.230' N3541.234 -> N35°41.234' N354120 -> (N35°41'20'') -> N35°41.333' N354120.4 -> (N35°41'20.4') -> N35°41.340' waypoint_entries.trk

You should be able to enter waypoints with a minimum "DD MM" and up to either "DD MM.mmm" or "DD MM SS.s". With the current implementation however only "DD MM SS" can be input.

It's very similar to adding normal waypoints. Go into the DATA page on the EHSD and press ODU button 1 until it changes to TGPT. Then just enter the info like you would normally do for waypoints. Only issue is that you would need to convert the decimal minutes into seconds first (multiply last two digits by 0.6 to convert).

The offset sideslip indicator is accurate for the H6.0 hud. Can't directly post it but its on pg 22-13 of the 2011 natops manual.

It seemed to align fine for me using auto start, although I did notice that it won't switch the INS knob to IFA once finished. Uploading a trackfile would help narrow it down.

It's normal to get that at the start of INS alignment. Just wait until it finishes.

Waypoint circle is way too big (should be about the same size as sideslip indicator). Waypoints are also disappearing in HUD after gear is put down (not sure if this is accurate). The "C" is also missing from the sideslip indicator when nosewheel is centred.

Waypoint 0 currently cannot be selected. As far as I can tell this should be the initial aircraft position. Currently when route mode is not enabled, pressing waypoint increment cycles through all waypoints, then markpoints, then targetpoints e.g W1->W2->W3->M0->M1->M2->T0->T1->T2->W1->W2->....... However with the H4.0 update it should only cycle through the currently selected waypoint type e.g W0->W1->W2->W0->..... or M0->M1->M2->M0->...... or T0->T1->T2->T0->........ Quick access is then used to change between waypoint types. Source: 2008 A1-AV8B-NFM-000 (pg 23-41, 23-42) waypoint_selection.trk

-The waypoint increment/decrement pushbuttons on the VREST pages do not work, likewise quick access cannot be initiated using these buttons. -The outside air temperature should stop being automatically updated with weight off wheels, however it is currently always being updated. -The field elevation does not change when waypoint is changed. (EDIT: exact phrasing is "field elevation (FELV).... is normally system generated". Might need an SME on this one.) Source: 2011 A1-AV8B-NFM-000 (pg 2-86 to 2-88) vrest_pages.trk

Using the NFM-400 charts; the 406 has a maximum corrected hover weight of around 19,500 lbs, compared to the 408 that has a maximum corrected hover weight of around 21,000 lbs. In game the thrust matches closely to that of the 408 curve (except for certain wet conditions). In regards to the maximum thrust being incorrect, the full quote for this value is: "The F402--RR--408 series engine, with water injection, develops a nominal (static test bed) thrust of 23,400 pounds in optimum ICAO conditions or 22,200 pounds without water injection." It's likely this value was the best possible thrust obtained using a perfect engine and in perfect laboratory conditions. As the charts in the NFM-400 were obtained from data directly from flight tests these are much more indicative of the actual thrust that can be produced in normal operations. Perhaps an argument could be made for simulating a non-zero datum engine compared to the current zero datum engine. As there are already separate "safety margins" for VL and VTO based on the calculated hover weight (95% and 97% respectively) I highly doubt that there is another safety margin factored into the charts. Do you have a source for charts being 95% of the actual thrust?

Many HUD elements are the wrong size and/or in the wrong location. I can't link the H6.0 HUD for comparison as I can only find that in the NATOPS manual. A specific example of the HUD being incorrect is with the VSTOL mode where the area surrounding the witches hat is too clustered.

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

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.

Targetpoints created through any means other than ATHS cannot be entered into JDAMs JDAM_targetpoints.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.

Bumping with another example

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