Blackeye

I guess I would guess that might depend on the deflection of the AP channel before trimming.

Are you sure you don't have the yaw AP channel active? I haven't seen trim affect the pedal but if you have the yaw channel active it'll move you pedals if necessary to keep the current heading.

Probably should use the FFB option then as this will send the trim click to the AP but not modify the stick input in any way (so no need to re-center it) - if it does I'd consider it a bug as a FFB joystick would "recenter" on the current position. However I think that's independent of the process I was describing here as I have a spring centered joystick. Also I don't consider this to be "wrong" or an implementation problem as this is the expected way to work in the Ka-50 - just wanting to make sure that this is indeed the way the Hind works and it is flown like the Ka-50 IRL when it comes to trimming. If it is I'm wondering if the Mi-8 should behave this way as well given it's similarity to the Hind, but then again that might be one of the differences.

Not sure if I understand you correctly here but I am moving the stick back to center - I usually use center trim mode anyways (tried default mode in this case as well with the same result), so it's definitely not the issue of stick input adding to the trim. It seems to work the same way as it does in the Ka-50, where some percentage of your stick input is needed to negate the AP trying to hold the current attitude and this part then gets added once you trim - effectively over-correcting your input. That's why you usually hold the trim down while making stick changes in the Ka-50.

It doesn't seem to be needed in the Hip - perhaps the crew is adjusting things on fly? It also seems less pronounced in the Hind compared to the Ka-50.

I noticed that Trim/AP in the Hind seem to work more similar to those on the Ka-50 than on the Mi-8 in that if you make a correction with the stick and then quickly press and release the trimmer the Hind will over-correct just like the Ka-50 ( which is why I usually press -> correct -> release there). Picture example: Trimmed for right turn (1) and the moved the stick to achieve level attitude (2). Pressing the trimmer will reset the AP channels to 0 (3) and after release the helicopter will bank further to the left (4) with the stick centered I was, perhaps wrongly, under the impression that AP/Trim would be more akin to the system in the Mi-8 - so is this the expected behavior? If so then I assume the Hind is flown more like the Ka-50 in that regard, i.e. hold the trim during maneuvering? Any insights are appreciated. Edit: Apparently it has been acknowledged as bug by Devs on the Russian forum - see Solution.

The version we have now (9M114) has a weaker warhead and less range <5km - later we should get the 9M120 Ataka with a warhead very similar to the one in the Vikhrs and with a slightly longer range (<6km) than the 9M114 but still less than the Vikhr. There is no "lock" - Pete or the other player in MP has to manually keep the sight centered on the target, which means that you have to keep the target in sight and aim for a fairly stable flight. Similar to a full manual shot in the Ka-50 but without ground stabilization aid.

For me disabling the sync controls option fixed that - or immediately moving the control a bit on mission start.

Of course not - yet a lot of the other AI in DCS certainly has superhuman feats. Whether it is a physics defying flight model or ground forces with perfect SA. I think spotting/calling is planned. And I agree that making (tactical) decisions all by himself would be great and actually push into "AI" territory. However those things are quite easy to make up for as pilot, so being inferior in that regard is not a big issue and expected to some degree. The "menial" tasks OTOH like spotting and shooting is something that humans struggle with and where the AI is cheating to some degree, which can easily lead to a situation where a human pilot with a cheating AI is superior to a team of two humans.

Couldn't find the statement but I feel a percentage dice roll isn't really the same as proper limitations, e g. a fixed 5% (or whatever number) chance to miss a shot regardless of how violent you maneuver is very different from a human having to compensate for that. I don't know how detailed or well ED can/will implement those limits but I hope it's going to factor this stuff in rather than go for the all-seeing all-knowing all-capable AI with a (simple) failure chance on top. Edit: Found something Sounds promising.

I'm more concerned about Petrovich becoming super human. i.e. being able to - instantly detect and classify all units in an area regardless of LoS, smoke or lighting conditions - never miss a shot even while maneuvering (withing limits) - always fire at the perfect range to hit - do other stuff not shown in video where "AI" can easily cheat (e.g. calling out SAMs or spotting units). I really don't want him to perform better than a somewhat competent human player.

Well there's this guy - two dozen HE/Frag rockets in close proximity have just annihilated his squad, fortunately the ringing in his ears suppressed their screams and unless he's the luckiest guy in the universe I'm certain that he has some metal sticking in uncomfortable places now - some of the dirt, dust and smoke probably got into his eyes as well and even if not the visibility is 2 feet maximum anyway. Yet despite all that physical and mental anguish he still manages to hip fire his rifle on full auto with the dispersion of a laser beam almost perfectly leading the attacking helicopter while its 12.7mm MG rounds are pelting the ground around him. If that is "average" I really don't want go up against their elite. IOW: Some form of suppression and SA limits for infantry and other ground units would be very much appreciated.

Those existed all over the world back then though - even some civilian aircraft had them, e.g. Hawker Siddeley Trident:

Well CAS is basically IAS with some error correction. IAS or CAS are derived from the pressure difference between the static air pressure and the dynamic one of the attacking air - basically the Pitot tube has two openings one facing forward and one in non-moving air and displays that difference as IAS/CAS. That difference depends on the density of the air, so the higher up you are the bigger the difference between true air speed (TAS) and indicated speed will be. That's how it is in real life and knowing CAS/IAS is quite useful because it represents the "aerodynamic situation" of the aircraft. The speed of sound otoh does not change with density (but a little with temperature) so that number is a pretty good indicator of your true speed and is important because it defines the speed region your plane is in (sub-,trans-,supersonic).

I'm more concerned with targeting and range. Older variants of the 9K114 max out at 5km, there is no laser range finder and the zoom on the Raduga is 3x/10x compared to the 7x/23x of the Shkval. So you probably have to get within 4km of the threat which depending on the target may make things a lot more dangerous/suicidal.

Haven't found any. So far I've tried MSAA x2 and x4 as well as SSAAx2 with lowered Steam supersampling to no avail. Some cloud presets are worse than others depending on your altitude and that of the layer.

As stated SSAA is off and it looks okay in ultra but that comes at a performance hit even with MSAA and SSAA off - I think if I turned any of those up to 2x or 4x I'd end up with a slide show - perhaps if I lower Steam VR's oversampling it could work, however until now Steam's oversampling gave visually better results at higher frame rate, but I'll look into it. In any case I think it shouldn't require ultra settings and/or MSAAx4 or SSAAx2 to not show those artifacts.

Have you tried setting cloud quality to ultra? This makes it look okay for me but anything lower than that and those anomalies flickering around distant clouds become very distracting. Of course on ultra I have performance problems... Definitely not solved for me.

What settings do you guys run? If I run anything less than ultra I get flickering artifacts as I move my head - SSAA is off. In the second image you can see little jaggies on the edge of the cloud - those move, shrink and grow as I move my head making distant cloud flicker like crazy. The more you lower the settings from ultra the bigger and closer those get. It doesn't look like much in the screenshot but I find it very irritating in VR and am not sure I prefer that over the jitter. Ultra looks fine, but hurts performance. Any ideas which settings (steam?) I could try do get this under control?

That seems really weird to me - perhaps it's worth its own bug report as this is not about "VRS seems too sensitive" but rather its relation to forward speed is off.

First of all, thank you for the performance update making the Harrier more realistic. When discussing this in the forum some discrepancy between the module and documentation popped up: Currently the maximum obtainable fan RPM speeds in game are 116.8% wet and 113.5% dry. The dry maximum speed value and symbology (full hexagon) is what you would expect looking at the NATOPS manual. The wet speed on the other hand should go up 120% but it stops at 116.8% and the hexagon symbology stays at about half complete. I believe the problem is caused by what is referred to as "corrected fan speed" which is limited to 116.8% (NATOPS) According to this table the 116.8% corrected speed correspond to 120% wet indicated RPM. Edit: Put in the table from the DCS Harrier Pocket Guide as the other does not comply with the forum rules - unfortunately it is lacking the "corrected RPM column" which lists 116.8 % as maximum for the last row but still shows that the maximum indicated RPM wet should be 120%. (I think DCS docs should be ok in the forum, if not please remove as well) It seems the module has the 116.8% limit in place but either applies it to the uncorrected RPM or does not correctly compute the two RPM values. Case in point for the latter: The engine DDI displays both values and they seem to be within 1% of each other when according to the above table you would expect a corrected speed of 116.8% for the maximum dry thrust (113.5 indicated 114% in the DDI) - instead it reads 113% (see picture below) This limitation might lead to less wet power than it should have and in any case incorrect readout/symbology. All of this is based off of reading documentation (NATOPS & pocket guide) and in game observations, so any other insights or more information on the corrected RPM calculations are very welcome. Thank you. EDIT: Removed image from NATOPS, please do not post them here, thank you - Bignewy

I haven't been able to find the relation between indicated and corrected fan speed but it seems that you should be able to get to 120% indicated. If Razbam uses the 116.8% corrected rpm limit everywhere then it makes sense that you can't advance beyond that. Though that would be a bug IMHO - at least when it comes to the displayed values, if not their entire RPM calculation since the values displayed in the DDI don't match the table.

NATOPS says: The maximum indicated rpm for the F402--RR--408 engine is limited to 120.0 percent due to structural limits and to 116.8 percent corrected rpm due to maximum flow limits. RPM corrected to a standard day is referred to as corrected or non--dimensional rpm. The corrected rpm is automatically limited by DECS So it seems 120% is the hard structural limit but DECS limits things futher - not sure if there are certain conditions that would increase that limit. Edit: Or perhaps it's a display issue (in DCS?) as the table for the hexagon indicator has a column for corrected RPM which shows 116.8% for the 120% wet rpm: The engine DDI is supposed to display rpm and corrected rpm but they don't really match with that table (in DCS).

Just tested it: I could perform a vertical takeoff at 20000 wet but not dry which seems to be correct as the vertical takeoff weight at ISA is 20400 wet and 19100 dry (21000/19400 corrected hover weight). So your observation of barely taking off at 20300 wet in 320 feet seems pretty close. Edit: Data is from the NATOPS performance charts - not sure if I'm allowed to post the sheet here.

He did operate the left lever though, so I think it's a problem with the RH label.