DCS last Update: Big problem !!!

NineLine, so we should stick with the new system and just rebind ?

Could it not be made so the common binds are set throughoutall modules

Got the same problem here too. Just noticed when I was trying to landing on the Stennis and the button that I use for activate the arresting hook was not working :lol:

At least was just my HOTAS Throttle and my T-50/Warthog Stick, my MFD's setups are ok.

I think that is one of the goals, but again, getting the standardize across all modules causes growing pains like this.

When this happens (and I hope it will eventually, rebinding the same commonly used axis, buttons, etc. accross all modules is a pain) I have a feeling another clean config "wipe" like this will be needed once again.

...I apologize, as someone that is redoing his bindings every other day and for multiple versions, I know how much work it is.

Yes, those are the recommendations from the devs.

right...phew, I can re map, but I save as for example new throttle test..........lua, do all that and then try and load the profile, its not saving anywhere? config/mod/save game no where? any ideas guys

The issues this is trying to clear up is inconsistencies in controls, you know how you can search for one function in one module, but its completely different in another? Things like this. after that the can expand on improvements to how bindings are done, better interface, etc. BUT you guys take the hit, and I am sorry for that, but it's in the name of progress. We saw similar issues during the development of the A-10C, growing pains.

That's great, but don't you think it would be a good idea for ED to include this MASSIVE change of direction in the build logs so people can at least try to prepare instead of getting a head shot? I read the logs before I decide to update. Nothing of this was mentioned.

I was right in the middle of painting aircraft and needed the controls to view the aircraft externally in game. No notification what so ever until we find out the hard way. Not cool, at all. Now instead of painting, I've got to rebind ALL modules because I own them all. Involuntarily re-tasked into fixing this mess.

Besides that, someone took a shortcut. There's no way it's not possible to read a .lua file and compare to the new one with the new changes and migrate the user's custom settings or at least ask them to rebind the ones that have changed if they want to. You code should read, user's setting is X for control input named Y, User setting X is now migrated to new control name Z. I don't see how that is not doable. Instead, the entire task is dumped in the end-user's lap to resolve. A rule of thumb in the dev world is NEVER cause a work stoppage with a deployment. In this case, the work is your end-user using your product. And I'd say the work has stopped, no doubt.

Although I appreciate the intend of providing presets for certain input devices - why are those forced on the customers? Why not make it optional, e.g. by putting them on the website and say: 'we are providing presets for these devices, if you wish to use them please download for the appropriate devices and import the profiles into DCS the following way...'

Why ruin the experience for people who do not wish to use presets as they have assigned the bindings as they saw fit for themselves? Why force them to rebind, possibly again in the future as changes may be made?

The only profile I would be interested in is the Warthog profile for the A-10C as it translates pretty much one-to-one. All other preset profiles can stay very well off my PC as I will do that myself. Preferably *once*.

I might have nuked my install, but a friend told me in Discord to delete all the new profiles ( in the FA18's ../mods/aircrafts/fa18/input..) and just leave the default one in place. Did that and my old bindings were back so we could go flying tonight.

So I better repair the install ( to get the deleted files back ) and redo my bindings "properly" to save trouble down the road ?

If it helps fixing this bindings reset coming again and again I am all for it cause that is a real PITA, I mean REAL P I T A

At my job we have to give months of headsup and a clear migration path, plus environments for DEV, STAGING (manually test everything), UAT (battery of testers raise defects), PRE-PROD (test final integration) and PROD. Oh and did I mention all changes must pass through a CAB panel made up of 5 experts that will question you on the changes and approve them?

ED just releases a break-fix that completely messes up a big part of user work and just shrugs the shoulders... lol

A migration path, even if imperfect would be better than this, something like: "hey guys we are revamping the keybinds. We imported your keybinds to the best of our ability, but please do re-check your binds"

Wow. Your team is doing a lot while maintaining a two week release cycle. And on a beta branch too.... Kudos!

ED gets a pass from me on this one. Yes, there should have been a blurb in the release notes, but we are on a two week schedule with a beta branch. I don't know how it used to be, but since I bought into DCS (Hornet release), communication and customer relations has been excellent. Nine has been around various forums with sympathy and an explanation. That is hardly "shrugs the shoulders".

If this change improves the product, I'm all for it.

At my job we have to give months of headsup and a clear migration path, plus environments for DEV, STAGING (manually test everything), UAT (battery of testers raise defects), PRE-PROD (test final integration) and PROD. Oh and did I mention all changes must pass through a CAB panel made up of 5 experts that will question you on the changes and approve them?

 

ED just releases a break-fix that completely messes up a big part of user work and just shrugs the shoulders... lol

No-one's shrugged their shoulders and walked on.

You've been told that behind the scenes work is on-going, and out front Nineline has been actively trying to help users & provide both explanations and support.

One thing though - These changes made it through a change advisory board, DEV, staging, UAT (closed testing).

There's a testers group that used the changed files and either had few problems (I had no issues), or understood that in moving to a point that allowed easier implementation of future developments there would be some re-configuration necessary.

...and then in your path to release... - See this bit: "PRE-PROD (test final integration)" ?

That's you, right now.

In using the Beta, you are accepting that you are not prod, you are a tester who will experience bugs and unforeseen outcomes.

Some people have found that the changes brought a lot of issues.

& that's why there's an open beta, so the inconvenience can as much as possible be experienced by people that have already said they are prepared to accept the inconvenience of an unstable build.

Personally, I accept the coms about the possibility of issues could have been better, but I see one of the biggest unforeseen outcomes that occurred here being an underestimation of how many people expect the open-beta testing to actually be a stable release.

This is why I don't beta :D

Which means you've thought about the possibility of exactly this happening, and realised you'd rather have a stable build and wait for the features to come to 'PROD".

Good insight :)

I basically migrated my saved games configs into the DCS directory. This fixed the overlapping/competing config issue and everything now seems to be working fine. Is there any downside to this approach?

I suspect that I don't actually understand the function of the new files and that my changes will be overridden the next time DCS is updated. Are custom configs still saved to the saved games folder? (as a diff of a diff now?)

How to backup bindings in future.

In future when this is all sorted out does it mean if user wishes to backup input/bindings that are user's custom bindings then that will be the folder on right side of pic attached...for example: S:\DCS World OpenBeta\Mods\aircraft\FA-18C\Input\FA-18C\joystick? So regular backup say of the 'aircraft' folder for all modules on a regular basis would be effective as backup.

Or will I still do backups of my custom bindings by backup of the folder on left side of pic attached...for example: C:\Users\Gary\Saved Games\DCS.openbeta\Config\Input\FA-18C_hornet\joystick? This is what I have done in past.

Am I correct in my understanding that any customs input/bindings are always in the Saved games folder not the program folder, and this will remain the same with this new bindings situation and DCS into the future? Bit confused as files called 'diff.lua' exist at both folder locations...help!

Thanking you...Gary

I understand this is painful. And even in the beta branch, some heads up/warning would have been nice since it's a sweeping change.

Having said that, I'm all for it. Current control setup is quite annoying and broken. Having to setup flaps, gear, master arm across all modules is a pain. So if we can get a better way of configuring HOTAS, I'll suck it up and drive on.

But I'd be a liar if I didn't think about going back to TARGET :)

... Having to setup flaps, gear, master arm across all modules is a pain. So if we can get a better way of configuring HOTAS, I'll suck it up and drive on.

Where on the Warthog would you have "master arm" or "gear" for all modules? I wouldn't know; not even for the A-10C.

But I'd be a liar if I didn't think about going back to TARGET :)

Same here.