lukeXIII

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

The TV HUD symbol is still not roll stabilised.

Still seeing this issue.

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

It's normal, FLIR FOV is 13.4° x 20°

It's been in game for a while now. MENU -> BIT -> FBST It's just missing the ODU options for specific corrections.

That image isn't reflective of what is happening in game, image below is how it is currently working. According to the diagram you should be able to go from a TPOD designation all the way to snowplow but its getting stuck in MAP/SLV. No idea if it's the current implementation that's wrong or the diagram.

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 was changed within the last year. Chuck's guide is probably the best: https://www.mudspike.com/chucks-guides-dcs-av-8b-harrier-ii/

If starting from the ground you will need to disengage the parking break which is just in front of the throttle. You will also need to get the wheel chocks removed.

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.

The OverTemp function still works correctly. It does not activate until the temperature exceeds 820 C, which you would not normally see unless you turn the JPTL switch off or there is a JPTL failure. The engine count still doesn't change though.

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

The engine DDI display is missing the H6.0 updates which adds a decimal to the engine RPMs and also adds the H20 weight. It also looks like there shouldn't be a "C" on the JPT under Fan RPM Source: 2011 A1-AV8B-NFM-000, 2.5.3 Engine DDI Display

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.

JPT in example below dropped by 62 C (around 3x greater than it should be).

Here's an IRL video that shows how it should work, and the importance of having the bug be wind corrected especially in IFR conditions: