doveman

I recall there were some plans to enable us to put mods in Saved Games\DCS rather than the actual game install folder. This obviously has the advantage of not needing to uninstall/reinstall them when updating, which even though I use JSGME is still a bit of a pain. So can we use Saved Games\DCS for mods yet? I'd still use JSGME there to make it easy to toggle mods on/off but essentially it would be putting the folders and files from the mod in this folder, so there might be Saved Games\DCS\Script\export.lua or Saved Games\DCS\mods\aircrafts\KA-50\Cockpit\Resources\IndicationTextures\font_Ka-50_SHKVAL.tga and so on.

True but that's no different from when mapping F to the collective axis as toby23 has done is it? If the brake/F is being held whenever the collective axis moves, whether using the joystick profiler or an in-game option, then each tiny movement of the collective pulls the brake, so I imagine that it would be easy enough to stablise the altitude with small adjustments to the collective, whilst it's also pulling the brake repeatedly each time it's moved to set the altitude trim. I guess ED could code a "hold brake for x seconds after last collective movement" if that's necessary instead though, which might not be possible with joystick profiling software.

I think rather than mapping F to the collective axis, we should have an option in-game to "automatically pull collective brake lever when moving collective" for those of use who don't have an actual brake handle to pull and don't think pressing a button instead is a natural or worthwhile substitute. Whilst some people can do this with their joystick profiling software, others can't so it would make life a lot simpler to just have it as an option in-game.

Is anyone able to provide an AutoHotKey script (or something else) that will do this "press F when moving the collective", so that I can use it with my Thrustmaster Hotas X? Definitely think this should be an option in-game, to automatically press F when moving the collective, for those of use (i.e. most people) who don't have an actual brake handle. I guess some people enjoy pressing a button to simulate pulling the brake handle but it seems so different that I'd certainly prefer it to be automatic, as it would be for a real pilot as he has no choice but to pull the lever to move the collective and it's right there under his fingers on the collective as he's holding it.

Wouldn't a better option be to keep the rudder trim but to have an option for DCS to treat the current pedal input as 0 when the trim is clicked? So for example, if the left pedal is depressed to send +50 to DCS and then the trim is clicked, the current position is then treated as 0/Centre (even though the actual input from the pedal is +50, or maybe 16000 in DirectX Input values) and so there would be no need to physically centre the pedals to prevent DCS seeing and adding an additional +50. Then pressing the right pedal to return them to the physical centre would then be seen by DCS as -50 and then clicking the trim again whilst the pedals are centred (or close enough, as it's probably impossible to get them exactly centred with the spring removed) would align the physical 0 with DCS' 0 input position. This would obviously only work for people who've removed the spring/tightened the torsion screw on their pedals to make them stay where they're left and not return to centre but that seems to be what a lot of people are doing anyway.

I don't see any reason why changing the interface to be more user-friendly and intuitive should stop your saved profile working, so there's no need to be annoyed ;)

What it has is the main screen where you'll see a list as you describe, something like: Pitch Forward - Thrustmaster Hotas X Axis -X;Xbox360 Controller and so on. There is a limitation here as there's not enough room to show all the controls assigned to a function if there's several (I have suggested they make the controls setup screen use the whole screen rather than just the bottom-left corner but they don't seem interested). However, double-clicking on Pitch Forward will open a window which shows the command (i.e. Pitch Forward) at the top and underneath, each button/axis/key assigned to that command, like: Pitch Forward ------------- Thrustmaster Hotas X Axis -X Xbox360 Controller Axis -X Up Mouse Up W and these can be deleted, added to by pressing the key/button or moving the axis (for the Mouse buttons/axis these are listed on the right, from where they can be dragged into the assigned commands list, as obviously it's not possible to add them by moving/clicking the mouse, as it's being used as a mouse in this screen).

Yeah but my Thrustmaster Hotas X doesn't have any such software, nor does the Xbox360 Controller. I can and do use Xpadder to assign keys to buttons but that's no good for assigning axes and some people might not want to spend $10 buying Xpadder, so DCSW does need to allow assigning multiple keys to each function. You probably haven't seen the ArmA controls setup but you'd see it's not at all complicated and very easy to use, whilst still providing the power to assign controls as required.

It makes sense to be able to assign multiple keys to one function (for instance, I use an Xbox360 controller to control the Shkval but also have those controls mapped to my HOTAS) but as I mentioned, the method used in ArmA, where it shows a single box listing all keys/buttons/axis assigned to the command, is much more sensible.

Sure, it needs a complete redesign/rewrite (maybe for that particular problem it could check the number of lines in the active control lua against the installed build's masterlist and if they differ, then do the more complicated line-by-line comparison to find which lines are missing and insert them), I just don't see it as that complex to design and code a controls setup system, in comparison to fixing some in-game issues anyway where you have to be constantly mindful that any change might negatively affect numerous other things. The Axis/Curves setup routines seems fine, better than anything I've seen in any other game/sim certainly, not that I've played them all and I imagine they can be re-used at least.

Oh, another thing that would be nice is if we could edit the controls whilst flying, pausing first of course, as we can in other games like ArmA. It's a major pain to have to exit the mission and let DCSW load again when we find a key is not set correctly or whatever. If the Controls setup was a separate app, this could be loaded when pausing and selecting Edit Controls (or users could have it loaded already before launching DCSW if they intend to edit the controls) and then after editing and saving back to the lua, the sim modules should be able to use the new controls. If the modules currently load the controls from the lua files into memory when they first launch and don't refer to the files after that, then it would require adding a routine to re-load the controls from the lua files after editing, which could be done automatically whenever resuming from pause, as I doubt it would take any noticeable time.

Thanks for the info Nate, although I don't really see that it could be as complicated as "ripping out" and "implementing a totally new system" suggests. A separate app that can be used to setup the controls without having to load DCSW might be preferable, just because it can be run in a window, allowing the user to refer to other documents/programs but even changing the controls setup in DCSW shouldn't be particularly difficult. Obviously it requires coding and time to do that and there's other issues/bugs that are higher priority but if individuals can code things like Falcon Keyfile Editor http://sourceforge.net/projects/keyfileeditor/ then I'd expect ED can manage to come up with something. I'm not holding up that program as ideal or something to emulate as even with it, setting up the controls for Falcon BMS makes my head spin and is worse than the current DCSW controls setup but still, for some tasks at least, much better than trying to setup the controls within BMS itself.

I wonder, if ED aren't willing to improve it, whether someone could code a separate app for control setup? The control .lua files are only plain text, so it probably wouldn't be that hard. There's a program that does that for Falcon BMS, which has an even worse in-game control setup which has prevented me even getting to play that yet.

OK, with the posted dll and prefs in bin/ only the Headtracker column shows up in Controls but it doesn't respond to Freetrack input, either there or in the aircraft. If I add a copy of the dll to bin/headtracker/ then it works. I had to disabled all mods first though, otherwise it was crashing and giving the "Error loading debriefing" error after ending a mission. Even then, on the second try somehow I managed to get the view stuck facing the rear of the seat (in the KA-50) and I couldn't change it, either with snapviews or the numpad to rotate the view, which did cause it to rotate but as soon as I released the key it returned to facing the rear. The only thing I could do is select the zoomed-in HUD view which stayed on that.

I agree, It does seem a big old mess. What would probably work better and still allow assigning multiple controls to one function is the method used in ArmA2/3, where selecting the function opens a window where the currently assigned keys/axis are listed and can be deleted/added to.

If anyone else is still getting the flashing white boxes with HDR on, as I was with CCC 13.4, PeterP seems to have come up with a fix for it, which works for me :) http://forums.eagle.ru/showpost.php?p=1865107&postcount=110 Thought I should draw attention to it as it's in the Warthog forum and might get overlooked for Black Shark pilots. I've just been flying without any HDR because of this bug but it'll be nice to be able to use it now if I want. I don't think this fixes the flashing black buildings bug, which is equally annoying but it's one less issue anyway.

Thanks Peter, this seems to have done the trick. Nice work :thumbup:

OK, I thought I had to click and hold something but I could well be mistaken, as I haven't been able to fly much lately. Nonetheless, I still think it would be beneficial if the scroll wheel could be locked to a rotary until the mouse is moved a certain distance, as it would eliminate problems with jitter/accidental nudges moving the pointer off the rotary, thus making the scroll no longer control it and also allow for placing the pointer over nearby switches and clicking them whilst still using the scroll for the rotary.

I've just had an idea for making rotary controls easier to use, which I think will add to this proposal. At the moment we have to hold rmb and drag the mouse (I think, I can never remember and I'm not at my PC to check), whereas I suggest click (lmb or rmb or even mmb) once on a rotary control and then rotate it with the scroll wheel, using the magnetic control principle referred to earlier, so that you have to move the mouse a certain distance from the rotary control to deactivate it and unlock the mouse from it. If this distance is set large enough it would be possible to move the mouse pointer and lmb or rmb click on adjacent switches whilst the wheel is still locked to and controlling the rotary, which may be useful for some tasks. I figure this idea will make life easier for those with the mouse mapped to their hotas or other controller as they can just press one button to activate the rotary and then use two other buttons for the scroll wheel, without having to hold the button mapped to rmb at the same time, as at present. People could also build starter cockpits, with a single hardware rotary mapped to the scrollwheel, with another hardware button mapped to lmb to select the rotary under the mouse pointer (hopefully controlled by headtracking, eliminating the need to use a mouse).

I also found it no longer works in headtracker and moved/copied to bin it shows the settings in controls but crashes on loading mission so I'll try the DLL posted above

Thanks Peter but I'm afraid I tested with 1.2.6 on my 6950 and just this mod and had white flashing dots/boxes all over the place with HDR Normal. I normally have HDR Disabled to prevent this problem and setting it back to disabled and they indeed didn't happen anymore. I also had the disappearing/black buildings a lot but I'm not sure if that's connected to HDR or not. I don't think I noticed after putting it back to Disabled but I might just have not flown that close to any buildings.

It's a good idea to use JSGME with any mods, including the headtracker.dll, so that if they get deleted by an update you can just put them back. You don't need to check if it has been removed by an update, just disable all mods first with a single click, then re-enable them after updating with another single click.

I've attached a Freetrack profile with zoom smoothing, so you can copy and paste the relevant sections from that into your own profile if you want. DCS.zip

I'm not sure what your advice translates to in actual curves but I was using something like 5 Deadzone and 25 Curve. I even played around with Saturation but it didn't seem like there was anything I could do to make the stick responsive enough, whereas in comparison the XBox360 sticks are ultra-sensitive and give much better control. Not that it's comfortable to fly with an Xbox360 controller, so I haven't been doing much flying :(

Interesting. I'll have to check that on the mission I was playing the other day (can't recall the name right now but I think it was the first in the default campaign) where I was getting 8fps when the enemy projectiles were being launched towards the friendly positions.