imacken

The manual extract seems quite clear to me. It should reset the weapon profile. I’ll raise a bug report tomorrow, as I don’t think it’s doing what it should.

Yep, it's a real shame. One thing that makes me laugh though, is that I just looked at @baltic_dragon's web site, and my comments from years ago on the forum when the TMs were relevant is still posted on there! It was true at the time.

Yes, that was the one! Thanks for that. However, it doesn't explain some of what we are discussing here now. I'm doing more investigation so I (we) can understand the relationships between stick throw, elevator movement and in cockpit stick view.

OK, so after checking all my modules - about 15 - it is only the Hornet, Viper and F-5E that are affected by this issue. In all cases, setting Y saturation to 60% fixed it for me, giving full deflection which in turn gives me more control as I can now use the full stick throw for actual elevator movement in those 3 modules. (I'll post on the bug section on this later.)

How does the RSET button work on the Hornet Air-to-Air radar? As I understand it - as per the manual P 345 - if I've changed the settings, e.g. # of bars, azimuth angle, etc., for a particular weapon then pressing the RSET will bring them back to default for that weapon. I can't get it to work.

Oh definitely improved, as I have the full throw available now for adjustments rather than only about 50% before.

Firstly, making the adjustment to the saturation in order to get the elevators respond to the full stick throw makes quite a difference in terms of sensitivity, so I'm glad this issue was raised. However, we're getting no response here, so I think I'll post this as a bug and see if we can get a response from ED there.

Thanks Stuart, that didn't work too well for me, but you made me think about saturation values, and if I set Y Saturation to 70% then I get almost perfect match between the elevators and my stick. So, we can work around this, but my questions 1)-3) 5 posts above are still valid! There must be a legitimate design reason why this is happening as we shouldn't have to mess around with saturation values.

Maybe, but it's not the differences between us that's important, it's why it happens. See my questions above. I've just tried various other modules, and some are completely synced with the stick/elevator movement, and some are not.

I measured mine using JoyTester exactly at the point where the Hornet elevators no longer move with my stick, and it is exactly 50% in both forward and aft, but in the end, the numbers don't matter. The questions are 1) why do the player stick movements not match the actual elevators, 2) why does the in-cockpit stick match the elevators' movement forward, but not aft, and 3) why are there discrepancies at all? Surely it could be synced to the full player stick movement. I've just checked the Viper, and there, I get 40% of my stick movement forward moving the elevator, and 60% aft. Yep, in-cockpit the stick moves perfectly with my stick. I'm guessing this has a perfectly rational explanation, and hopefully someone here will tell us!

I know there was a thread about this a long time ago, but I can't remember the answer. Pitch and differences between player stick, in-cockpit stick and elevator movement. Pitch Down - the in-cockpit stick only moves with about 50% player stick throw, i.e. the final 50% of player stick movement doesn't do anything. This is confirmed by looking at the external view where it can be seen that the elevators only move with about 50% stick forward. Pitch up - the in-cockpit stick follows the full 100% player stick backward movement. However, the elevators do not. They stop moving around 85% of stick throw, so again, it seems that some of the player stick movement does nothing. (Best to look in external view while sitting on the ramp.) If only 50-85% is being used, then why not calibrate that to the full 100% player stick movement? Is anyone able to explain this to me? EDITED: 5/10/2022

Give this a go. That is how I do mine.

@NineLinehave you had a chance to look at this yet?

OK, so can you post your axis screen from VPC software for one (or both) of pitch and roll (X and Y) like the one I attached?

Ah OK, thanks. It would be incredibly useful, as at the moment, the custom preset name for #1 may not be appropriate for both builds. Hard to see how one can have sensible names, unless, like I do, you just copy the presets from one SG/Config folder to the other.

Sounds good, but will the same custom names still refer to both the stable and OB file, or will they be referenced separately?

Skate, did you see my comments on my previous post about the custom naming of presets and the suggestion to hold them in a separate folder for copying across to SG?

Controls like radar elevation are not suitable for the encoders. They are better for dials with specific settings. Or, making them into virtual axes can work better. As you say, hats are much more effective for things like antenna elevation.

You have to install @Binary's version from earlier in this thread.

Thank you, that is how I understood it. However, just today, I realised that the dropdown 'Select Preset' selection in the app doesn't relate to any specific preset. By that I mean that if I select 'PRESET 1' from the drop down, that is not pointing to a specific preset at all, it is in fact pointing to the Options.lua.Preset01 for the build chosen, which is very confusing. Examples of how this puzzled me today. Firstly, I was slightly irritated by the fact that on each start of the app, my first preset was always selected. That is called 'VR'. Now, I tend to mostly use a monitor these days, so I usually select my 2nd preset which is called '2D'. So that the app would always start with my '2D' preset, I renamed the Preset01 file to Preset02 in the OB Saved Games folder and vice versa and swapped their names in 'Custom Preset Names' to '2D' and 'VR'. Now, as I 99% use the OB build, that was never a problem. However, today I ran the Stable build with the 2D selected from the dropdown and DCS went into VR! I realised this was because I had not changed the preset files in the Stable build Saved Games which I previously didn't realise I had to do. I had, by coincidence, always had them in sync as I copy over most of the OB Saved Games folders to Stable anyway. So, in essence, the custom names are irrelevant unless I sync the preset files in Stable and OB as they link to 2 files and not 1 file, with potentially very different content and purpose. Would it be possible to have the presets sitting in a separate folder with the names in 'Custom Preset Names' referring to one specific file, then the selection of the preset in the dropdown could be made relevant to the build that was being run.

Ok, so I am confused about the presets that I thought I understood. They are located as files such as Options.lua.Preset01, is that correct? And, I've always assumed that the utility copies the selected preset into Options.lua before running DCS. If that is correct, then it would seem that the utility takes the presets from the appropriate Saved Games folder, i.e. C:\Users\xxx\Saved Games\DCS.openbeta\Config and C:\Users\xxx\Saved Games\DCS\Config, depending on what version of DCS is selected from the 'Select Build' dropdown. Again, if that is correct, then my question is how do we specify presets for both OB and Stable? Are the preset names applicable to the xxx.lua.Preset0x files in each variant folder? At the moment, I copy them across from one Config folder to the other, but that doesn't make real sense to me. How do we specify that a preset is for Stable or OB? I think I'm not fully understanding how this works in the Utility.

Where are you experiencing a dead zone? Pitch and roll axes, I guess? In the VPC software? DCS?

Looks like it's certain characters in the L/L text, e.g. the degree symbol, that cause the backspace to go crazy.

Well, the Alpha brake lever always worked nicely for me for brakes on the Spitfire, and now, the Prime lever works even more nicely for me!

Nice! Personally, I can't see the need for the space bar to take up a whole row of screen space so I'll probably change that, but well done. What's the function of the symbol in bottom right?