MBot

I decided to try the Harrier again after a long while and am generally pleased regarding many improvements with unguided weapon employment. I made some observations which I have questions about though: For bomb salvos (QTY>MULTI), CCIP seems to target the first bomb and not the center of the stick. This seems unusual to me as otherwise bracketing the target seems to be the standard with western aircraft. Is this correct behaviour? When having four LAU-3 rockets pods (ripple mode selected in ME) and selecting QTY 1 and MUTLI 1, each pickle press will fire one individual full pod. With QTY 2 and MULTI 1, each pickle will fire half of each of the 4 pods simultaneously. Why is this so? When having a target point designated on a hill and attacking it with BCIP or GCIP, bombs land on target. So far so good (bomb triangle can be correctly calculated). But when having radar alt enabled and approaching the hilltop flat and low enough for RCIP to take precedence in the final seconds before the drop, bombs still land on target, despite RCIP is supposed to generate incorrect altitude above target at this point. While the correct precedence of CCIP>RCIP>GCIP>BCIP is indicated as text on the HUD and RCIP should be active at this point, it seems that the altitude above target for the bomb triangle is actually calculated from the known target elevation instead. Flying at low altitude in level flight above rolling terrain with no target point designated, there is no discernible difference in piper behaviour when switching between GCIP, BCIP and RCIP. It seems these modes are practically the same. I am not sure if this is correct, it depends on whether GCIP and BCIP derive altitude above ground from a terrain elevation database or not (to which I have not seen any reference in the game documentation). I am happy to report though that attacking non-designated targets on a hilltop with RCIP and GCIP/BCIP (in case they can produce alt above ground below aircraft from a database) correctly results in missing bombs. I am also happy to see that ARBS designations in a valley results in missed bombs when attacking a target with CCIP on a hill. Though it seems that is not related to an actual simulation of ARBS with slant range calculations, but just that ARBS will put a target point designation on the map with the terrain elevation known from a database.

AGM-84D Harpoon fired by AI crash into ocean in front of their target ship. Harpoon.trk

Any news on the deck sliding issue? This is still causing Tomcats to slide forward and crash into aircraft on the catapult before INS alignment is complete.

By text-editing the mission file (no moding of the core game required) you can already load and use them.

I am having my Reverb since a couple of days but am experiencing very noticeable chromatic abberation outside the sweetspot. In the Tomcat it looks roughly like that (poor MS Paint visualization): Is this normal?

Ok, I figured it out. Point Track only engages in black-hot but not in white-hot (or was it the other way around?). An established Point Track is retained when switching back and forth between the two modes though. I don't know if that is supposed to be like that.

All my tests were in clear (default) weather. I have tried Point Track against a Krivak, Neustrashimy and the Kuznetsov. Nether of which worked. Perhaps these are too large for the tracking gate? I think Area Track is simply bugged (or implemented based on a workaround). Why should Area Track work on the water 100m next to s ship, but not work on the water 500m next to a ship. Slewing the pod to QST is not a good option when attacking a moving ship, unless you happen to designate a point with the perfect amount of lead before dropping the bomb. Chances are you will require to adjust the aimpoint seconds before impact, which is when a sudden switch to RATES will slew your aim off target at a speed of 500-ish knots.

There seem to be a couple of issues with using LANTIRN over water: LANTIRN is not able to point track a ship. Area track only works over water if the sensor is pointed very close to an active ship. Once the ship is destroyed, area track ceases to work. It seems this is somehow tied to active game objects to work over water. This makes it very difficult to select a target point with sufficient lead to attack a moving ship. When laser designating a moving ship by hand, LANTIRN has a very nasty habit to reverting from area track to RATES when the seeker is pointing down and changing orientation. This results in the seeker rapidly moving off target, making it impossible to re-acquire the target in time with a bomb in the terminal phase. About half of my attempts of attacking a moving ship with LGB resulted in such misses.

It should be possible to drop it through cloud cover and acquiring the target via datalink once the weapon breaks through the overcast.

Thinking about this again, perhaps there was a difference between the two sessions. When I required so much power in the pattern, I was flying a clean yet but have removed the Phoenix pallets while still on the carrier. In the pre-patch session when I had sufficient power in the pattern, I flew a clean yet with possibly the Phoenix racks still attached (I don't quite remember). Perhaps the "ghost wheight" is applied only when using the rearming menu on the carrier?

Launching clean and returning with 5000 lb of fuel, I just had 150 knots on speed with DLC engaged. It seems this patch was a step backwards. Just yesterday I was playing my regular training mission (clean launch, burning off fuel to max trap and then doing patterns until low on fuel) and was rejoicing on how much power I had once again in the pattern. In fact I had to readjust my throttle muscle-memory from the last weeks from giving too much power. Flying exactly the same training today after patching, I am again having troubles with maintaining altitude in level turns in the pattern (inadvertently retracting speed brakes and DLC multiple times).

Out of personal interest I run a couple of quick tests to check stores drag. I thought I would share the results. Nothing scientific, just to get a general idea how the stores relate to each other. Top speed measured at 300 ft AGL with altitude hold AP. Persian Gulf map, 20°C, QNH 29.92. Loadout is given as Sidewinder-Sparrow-Phoenix First number is top speed in knots, second number is top speed after all weapons are released (only launchers/rails) Clean 880 Pure loadouts: 2-0-0 841 875 2-0-0 775 796 (shoulder) 4-0-0 752 796 0-2-0 849 875 0-2-0 775 793 (shoulder) 0-4-0 817 875 0-0-2 809 876 0-0-2 882 947 (shoulder) 0-0-4 760 876 Mixed loadouts: 2-2-0 811 876 2-4-0 786 876 4-4-0 718 796 2-2-2 715 792 2-0-6 739 947 Observations: -Shoulder Sidewinders/Sparrows are extremely draggy. -For shoulder Sidewinders, the weapons are actually less draggy then the regular Sidewinders, but the launch rail is extra draggy. -For shoulder Sparrows, the weapons are actually less draggy then tunnel Sparrows, but the launcher is extra draggy. -Phoenix on shoulder is faster than clean and gets even faster with only the shoulder launchers (bug). -The rear weapons in the tunnel (Sparrows or Phoenix) are draggier than the forward weapons. -The forward stations in the tunnel are very efficient. -There is no difference between Winchester on tunnel Sparrows and tunnel Phoenix (Phoenix racks have no effect).

The parking brake still cannot be set. The switch looks and sounds as as if it engages but there is no braking. It only works initially from a cold start.

The electric trim switches on the left side panel are permanent switches (a left click switches them one state to the left, a right switch one state to the right). I am having big troubles using the rudder trim, because the clickable area moves with the moving switch. In practice this means that when I want to trim slight left rudder, I click left to move the switch left, adjust the mouse left the follow the switch and then click right to move the switch to the center position again. By the time I have completed this I have usually severely over-trimmed. I then repeat the proceed to trim right again, again over-trimming. Then left again etc. Since I have to move the mouse between using left and right mouse button, I am never fast enough for the precise amount of trim I require. To improve usability with the mouse I suggest to make the switches momentarily: The switch moves left/right as long as I hold down left/right mouse button and moves to center again when I release.

That is an excellemt summary TOViper and also how I expect it to work. In DCS that is currently not the case.

Thanks for the explanation, I don't know the flight manual and can only go by HB's own documentation. In any case, in DCS the flaps will not start to close until nose gear compression which is still wrong then.

I don't understand why you emphasise engage versus closing. On touchdown the engine is spooled up. If the flaps are open, the trust goes out of the back end. If the flaps are closed, the thrust is deflected forward. Right now the flaps dont close on main gear touchdown as described in the manual but only after nose wheel touchdown.

According to the manual, the thrust reverse should engage on main wheel touchdown: In game this is not the case, the thrust reverser only engages on nose gear compression.

Which is not feasible if you are running a "turn carrier into wind" script that dynamically adjusts carrier speed for a SOP wind speed over deck.

Introduced with the Open Beta from today, default tasks are applied every time a mission is loaded, even when the mission was previously saved with these tasks deleted. This breaks a lot of missions as this overrides the tasks that were set up by the mission designed. For example I just saw a bunch of B-52 revert to the default CAS behaviour and go on attacking all kinds of ground targets and other aircraft strafe everything in sight.

Ok, now I have to ask. I just flew a mission. Stored heading alignment on the carrier, launch, climb and cruise with a max G of 2.5. After 45 minutes of flight I had an INS drift of 20 NM. Is this normal? For full disclosure, the carrier was making a turn into the wind before the INS alignment started, which I know would make a stored heading alignment invalid. But I am not sure if this is modeled, since the INS seemed to align normally initially.

I have a floor mounted T-50 with a long extension and fly with 0 curve. My previous experience (before last week's patch) was that after trimming to on-speed in the downwind, basically no more stick input in pitch was required for wings-level flight. For the base turn some back stick was required to stay on-speed AOA, but once rolling out in the groove I would basically let go of the stick (except to control roll) and fly the ball with throttle. Once trimmed, the aircraft was very stable in staying on-speed even with power changes. This seems no longer possible.

I completely agree. The big FM patch about a month ago made an already very likable aircraft a dream to fly around the boat. Stable in AOA and very responsive to throttle changes with lots of power in reserve. But since the latest patch the handling in the pattern and in the groove is just awful.

Good report. I haven't done any testing but in the last few days I was also suprised how quickly and massively the INS degraded. I assume this was introduced with the latest patch.

This has nothing to do with network. The screenshots above are from singleplayer.