Leg2ion

Which for the most part is unrealistic. There are limited controls in the CPG station for a reason - the pilot is the driver, and as such the 'captain' of the aircraft. In the same way that the pilot does not have complete flexibility and control over all the sensors and weapons to the same level of refinement and ease of use as the CPG, aircraft 'management' is similarly limited to the CPG. Jump in the back seat and start the aircraft properly? Could that not be an option - get everything up and running, bring all the systems on line, then swap into CPG and use George to get airborne etc?

Oddly had similar the other week - whereby my Warthog throttle slider was mapped to the power levers with a modifier on the main stick. I had been flying cold starts and accompanying shutdowns, then did a quick training mission with a hot start. Got airborne, but when I inadvertently selected the modifier the power levers instantly chopped as the slider was all the way to the rear with resulting loss of power and catastrophic impact with the countryside! That was with a Thrustmaster Warthog. I have recently changed my base to an Ava - and no longer have this issue (obviously had to try!).

Found the culprit. Its Helios. If I apply (Helios) patches - and the command line 'dofile(LockOn_Options.common_script_path.."ViewportHandling.lua")' is added to the MFCD init.lua along with a 'try_find_assigned_viewport' it causes the issue. Even if I use the standard viewport name the issue is created. I knocked out the patches being applied to the pilot position and the issue disappeared - yet was still present in the CPG position. One other side effect I noticed, is that prior to this the in game MFD displays were appearing washed out but the exported ones were not - and I was living with it. Once I removed the patches both displays (In Game and exported) appeared the same. Just conscious there have been a lot of historic posts on washed out displays...

I believe it is realistic - but depends on how much altitude your are gaining - though whether intentionally modelled is another thing. If you are doing a tail handling check (say after maintenance) - part of that is to move sideways - both left and right - up to a certain speed. From what I can recall when you recover from that condition - ie slow down/stop - the aircraft would have a tendency to rise - not a great deal mind - so not sure how much altitude you are gaining. If you think that the disc would be slightly angled to promote movement in a certain direction, then as you bleed off speed to slow, that relationship changes and the 'fan' starts to blow more downwards then down/side, so if in ground effect you get a bigger 'cushion' of air underneath you forcing you up unless you counter with the collective perfectly. In addition - depending on which way you turn you can unload the disc - so if you turn the same way as the disc is rotating you will possibly see a rise in altitude as there is momentarily more energy available with a increase in torque. The problem you have is that you are entering the sideslip at speed - something the aircraft nor the flying controls/set-up isn't designed to do - and in reality would probably result in severe vibration with possible loss of control. When you rig an aircraft - the blade angles are set to achieve forward flight as the default - so the blades that are considered advancing - ie moving forward in the airflow are nominally set at a lower angle to decrease lift being generated due to higher airflow speed over the blade, and similarly those retreating - ie moving away from the airflow are set at a higher angle to increase lift due to a lower airflow speed. This is to maintain a balanced disc. You are ignoring this relationship. By slamming the aircraft sideways, and assuming then you are then moving the cyclic in the opposite direction to slow as quickly as possible, will increase the blade angles presented to the airflow resulting in an increase of lift, to a point. If doing strafing runs and basically want to do a 180 why don't you pull into a high angle nose up to bleed off speed, then when coming close to stationary go with a large yaw input to swing you around on a dime. The increase in height then allows you to nose dive back down increasing speed pretty quickly towards the target?

That is because, for some strange reason, the ground crew do not like fitting pylon stores or feeding rounds into the sideloader with the aircraft in an armed state...

Ah - apologies - my bad wording! I have completed M2, but it won't roll onto M3 - so the issue with the campaign not picking up the completion appears to be back? Unfortunately flew a training mission without saving it - but will give it another go and spend more loiter time with Warlord - see if that triggers anything. If not will attach it.

Hi @Florence201. Can safely say I have not managed to recreate this at all now - so must've been something I was doing (or not doing!). A couple of further issues though. I cannot for the life of me get past M2, and the trigger for the message to go provide top cover to the broken down vehicles seems way off? M2 not finishing properly is a known about issue I believe after looking at other posts - is there anywhere in particular I need to flag it with ED? Triggers - I take out the hostiles at WP4 and WP5 with accompanying confirmation that the threats have been neutralised, then head off to follow the flight plan and scout ahead. I think I may be going too fast, or should be orbiting back between waypoints and Warlord to stay local, as I have had the request to provide top cover either at the same time as I was getting directions back to the FOB, or on the way back into the FOB, or as of today after I had landed and there was much talk of a well earned beer! One final question - but does Ugly 5-2 actually land after the mission, as he seemed intent on scaring the c**p out of the folks in the FOB buildings by repeatedly 'near missing' them? At one point he was over the LZ, I had a quick flick through available unit views, and he was off meandering around the copse opposite the FOB again.

For cyclic, and for yaw - even though my pedals have springs - but no issue keeping pedals steady as very weak springs fitted. I have set custom curves for yaw (when AH was first release due to twitchiness and in the process of experimenting after the recent patch - so may just set them back to default), but will have to check for cyclic.

Both for me please - maybe with a little bit of Hildesheim thrown in... +1 to Lynx.

Hi @farebro Wattisham was definitely not Soest, and as you say Soest (and Germany) very much missed! The move was 'interesting' - probably the best way of describing things.

Not sure what the 'F14 bug' is, not what 'this' is? Any more information?

So spent around an hour going hover/fwd flight/hover and it does help, but it still doesn't seem to be as smooth with the yaw movement being overamplified when moving from fwd flight into the hover. So zero stores in Sochi/Caucasus. Trying to maintain a <100 ft altitude whilst transitioning into a hover and maintaining heading from 90-100 kts fwd speed. I found that I dropped to between 23-30% torque in a 5-10o nose up attitude to drop forward speed and whilst maintaining my desired altitude. As I decelerated through around 40-30kts I started to increase collective to smoothly maintain Nr and height, whilst still reducing speed. Due to the collective increases I was then compensating with (left pedal) yaw to counteract increased torque. However - at around 65-75% torque and around 5-10 kts there seemed to be further larger yaw input required as the aircraft continued turning to the right despite my attempt to reduce the movement. Tried both with the trim button pushed throughout the manoeuvre, and trim button pushed as starting to decelerate, released when in a 'steady state' of deceleration, then pushed again once starting to increase collective and counteract with yaw inputs - so as not to exceed any trim breakout limits. No real difference - maybe a bit better with trim pushed throughout but that may just be personal preference/subjective. On top of this, once in a stable hover with both altitude and attitude hold on, if I blipped the trim release button fwd momentarily, whilst making no control inputs, a series of yaw/roll oscillations occurred that gradually dampened out at best, at worst causing me to transition forward to avoid 'chasing' the corrective inputs needed. In my mind (though could be wrong) by momentarily selecting trim release but without making any inputs there should be no movement of the controls to speak of - all I am doing is re-centering the trim to null against the current control positions to re-establish 'full authority' back to the trim system. Hope the above makes sense. Trk file attached. Hover Yaw.trk

Oddly, before this latest patch - I don't think I suffered none any of the issues (that I was aware of anyway) that have been fixed?

Thanks - I'll give it a try, but to be honest, pre latest patch I would normally trim as I slowed to get into a stable hover and then apply a final trim once in the hover with no major issues. What I am finding now is that when applying a small yaw input to keep on current heading the aircraft suddenly goes from small yaw corrections to large ones, almost as if a threshold is reached whereby the movement is amplified, which I cannot counter for.

I would say no - it isn't. It find it now gets to the point that the yaw 'oscillations' when pulling into the hover result in some massive overcompensation and height changes if not careful - in my case I tend now to 'go around' - transition back into forward flight away from my target and reattempt to manoeuvre back into a hover - not the ideal - whereas previously it just felt natural. I feel now I am back to fighting against the machine as things were a few years ago.

As per @Floyd1212 post above - the file you attached to your post? "C:\Users\username\Saved Games\DCS.openbeta\Config\MonitorSetup\CustomMonitor.lua" In the example above replace CustomMonitor.lua with whatever you have called your custom layout - so if you are using the file you attached - should be HeliosAH. This should be created by helios (or you can make your own custom), and will give basic viewport positions for each window - as long as you have your monitor config set up correctly. You need to ensure the name in the file is also selected in DCS options - otherwise it will ignore it and do something differently based on what you have selected.

Ah - makes more sense. think its been like that for a long while now, not just since the last update.

Ah apologies - my mistake - just an assumption based on previous posts. Just curious when you said about not having to replace 'the mod files'?

Not sure if it will help (it does on my system with a Nvidia card) but check your PC advanced power settings and make sure it is set to high performance (if you can on Windows 11) and not balanced or power saver.

Because its a PITA to keep tweaking curves every patch. I spent a fair bit of time setting them up a couple of years ago, and haven't had any need to tweak them. Maybe time to have a play...but then that would suggest there have been some changes made if there is a need to change profile curves to bring things back to 'normal' ....

You know you can deselect the individual patches in helios? I currently use both LEFT_MFCD and LEFT_MFCD_CPG (and pilot versions) - so I can split the views I have - with Plt/CPG swappable displayed on a touch screen (LEFT_MFCD/RIGHT_MFCD), and the CPG only on a pair of TM Cougar Displays so I can keep an eye on what he is doing with weapons.

Agree. First lift off - ended up on my side, in the hover there is definitely some additional 'yaw twitchiness' at play with a slow yaw rate then suddenly kicks in with an oversteer, and coming in to the hover now need to watch for sudden strong yaw changes that weren't there previously (I think).

Hi @Derbroomaster - Thanks for that - it helps. When you import the profile have you reset your monitors to replicate your config, and then if you reset the helios lua it should give you all the co-ordinates you need. Also noting in your lua you provided the width is set at 5760, yet you say the three monitors are 2560 - so max width should be 7680? From your monitor config - If I assume screen 1 is slap bang in the centre of screen 2 (which is 3 screens wide x 2560 = 7680, I believe your co-ordinates should look something like like this - which should be ball park. Viewports = Center = { x = 0; y = 0; width = 7680; height = 1080; viewDx = 0; viewDy = 0; aspect = 7680 / 1080; } LEFT_MFCD = { x = 3215; y = 1228; width = 500; height = 500; } RIGHT_MFCD = { x = 3965; y = 1228; width = 500; height = 500; } It might help if you align the lower screen with the left hand edge of the uppers, as will make figuring x co-ordinates easier.

Got a few other 'choice words'!!

Hi @MAXsenna - one final update. I have just swapped my original TM Warthog stick base for an Ava base. With the new base I do not get the same issues - so all key binds and modifiers the same - no issues - so whether there was some sort of conflict - or my new base is now not working as it should...?