flyco

Yes, volume is set for all of them. But thanks for trying.

After updating to 1.2.8 from 1.2.6, I am unable to get SRS working. I log on to our server, where I can see that my name is allocated to an aircraft, and there is an entry on the Ckient Log (I monitor the server on a separate laptop). However, unlike everyone else, I am shown as a neutral entry (white dot), and my name does not appear against my logged on symbol on the SRS Client list. I have tried starting SRS and connecting, both before and after starting DCS. The radio overlay appears, the volume and frequencies can be changed, and the transmit lights appear when I use the relevant PTT. However I neither hear, nor am heard, by the other players. I was running with a triple monitor, using Helios on the second monitor and Kneepad on my third (Lilliput) monitor. However I have disabled Helios temporarily, and am using an export.lua, with just the single SRS line in it. Any suggestions?

You should try and read it on a 4K monitor. I wish I could, and the labels, and the chat boxes etc.

Thanks for the information. A great shame, this is a thoroughly enjoyable mission.

When flying Op Bactria in our server as multiplayer, there are no transmissions from Chalice. However, downloading this mission and running it on my PC as a singleton mission, it works fine. Any one any suggestions as to what might be the cause, and the cure?

I am trying to build a mission, in which a JTAC passes a second (and third, etc) target, once the first is destroyed. At present, he (or she) advises that there is a second tasking, and asks me to advise when ready for 9-line. However, the presented menus do not show the 'Ready to Copy 9-Line' option. Thus, I have to check out and then re-call JTAC, whereupon he again asks me to advise ready for 9-line, which is now available on the menu. Not a mission killer but certainly a PIA! Can anyone tell me if this is normal, and, if not, how I can fix it.

I have experienced similar problems when the MP connection was not stable. You can also see fellow flight members suddenly jumping 10ft into the air. As suggested, try this in SP and just fly close to the tanker for a while to see if it is jittery. That said, I have found that the boom operator does seem to have taken to swishing it about a bit violently just recently, so it could be a genuine bug.

Scottth6, I suspect this is a very different problem. It is normal when starting a new aircraft for all of the input devices to have 'common' settings, such as Trim U, Trim D, Fire Guns, etc. For each new aircraft you need to delete these 'default' allocations that you don't want, enter your own key/button input, and then, when complete, press OK to save these. It is easy to forget to press OK and select Cancel instead, whereupon all your inputs are lost and you must start again.

My dxdiag.txt is attached. Like Von Thrud, I have disabled all my critical toggle switches. When the problem occurs all these re-appear switched off, and I therefore lose various essential services operated by them: CDU, EGI, Battery, Generators, CICU, IFFCC etc. Thank you for taking the time to look into this. DxDiag.txt

I suspect this is linked to the re-initialising of other USB devices, such as bespoke switches, which first manifested itself after the same update as spawned the TrackIR unplugged/plugged outbreak.

Disappointing to see that the problem is not resolved. I have resigned myself to mouse clicking on the virtual switches, and reserving my hard- wired ones for those that don't go 'wild', such as my frequency encoders etc. But I still find myself automatically switching others when preoccupied in flight, such as the Weapons panel. It is clear from looking through the forum that others are having similar problems so at least it isn't my set-up. I remain convinced that it is a recently introduced bug in the DCS coding - it is not confined to any one aircraft. It is equally disappointing not to see any response from DCS; even a simple 'Acknowledged and will investigate' would suffice. I am not asking for an apology or a timescale for the fix - I recognise that they are working hard on other priorities.

There are areas where there are complete forests floating above ground. One day I will be brave enough to fly below them.

Yes, I have the same problem. It seems to follow no logic - sometimes a new screen appears, sometimes a row of screens appears and sometimes nothing happens. Very frustrating.

This discussion has now been taken up in the 1.5.4 Release section.

I suspected a loose or intermittent USB connection and have remade them all several times. I cannot rule this out as a cause - it is certainly a logical suggestion following the incorporation of the hot plug facility Is it possible for users to disable the hot-plug facility? If not, could the ability to disable it be considered - the USB connection is not the most stable of devices.

Check your DCS.log file. I suspect it may arise from repeated USB device re-initialisation.

Input Devices Re-Initialisation I find that both the release and the beta version of 1.5.4 repeatedly re-initialise my USB input devices during some sorties, reallocating a new deviceId on each occasion. This is clearly evident in the dcs.log (attached) from time 01287.498 onwards - strangely it often does this 5 times in quick succession! I have also seen at least 2 other dcs.log files submitted by other users which show the same re-initialisation. Since I use several hard-wired switches with USB input device, many of these are reset when the device is re-initialised, which can cause aircraft systems to be switched off, without any user input. This was not the caser in 1.5.3, nor in 2.0.2. indeed 2.0.2 does not seem to allocate a deviceId during initialisation of such input devices. Can anyone suggest why this is, and suggest a way to stop it. At present my hard-wired cockpit is virtually unusable. dcs.log.txt

I have had problems in 1.5.4 with hard-wired switches, connected to USB input devices, switching off during sorties. Examination of the dcs.log file shows that in addition to the initialisation of input devices at start up (keyboard, joystick, button boxes, etc), the system also carries out a further re-initialisation during normal operations. During such events the devices are re-allocated new deviceIds, in my case , for example, the keyboard was allocated a total of 16 different device Ids: 1 ,17, 30, 43, 56 ....186, 199. It would appear that DCS 2 does not allocate deviceIDs and so seems to be immune from this problem, and I suspect that versions before 1.5.4 were similar. Hence this problem has only just come to light. I attach the log file in which this happened five times on three separate occasions, the first about 8 minutes after starting the program, the second about 63 minutes in (when I lost all electrical power and other vital equipment), and the last during shut-down. This makes the use of hard-wired switches very problematical. dcs .log.txt

Please forgive me but I am pleased to hear of your problem. It confirms that a near identical problem I have been having for a couple of weeks is a DCS problem, rather than specific to my set-up. My initial thought was that it was a fault in my USB connections that were experiencing temporary power outs. Now I believe that the problem appears to be caused by the USB inputs re--initialising during flight. Yesterday, mine did it 5 times in quick succession within a second - twice! The result is that once re-initialised, any switches that have been selected ON revert to OFF - thus I lost battery, inverters, fuel pumps, and anything else that was controlled by one of my input boxes. The good news is that at least I was able to test out the simulation accuracy of a full airborne power-up - it worked quite well! For the present I will try to revert to mouse clicking to control the problematic inputs, but I will be pleased if DCS acknowledge this and look for a solution.

I found that un-checking the 'Use VR' box in the Specials page stops this warning appearing

I use a variety of input controllers (TMWarthog, BU386X, Brydling input etc), all hardwired to switches, which have operated in DCS 1.xx and 2.xx for several years. In 1.5.4 OpenBeta after a period of from 5 to 45 minutes of normal operation, many of the two position switches go simultaneously to OFF in the game (and on the screen) (obviously the hard switches are unchanged). On the latest incident I lost Battery, AC Gen, CDU, EGI, Fuel Pumps, TGP, CICU, JTRS, but not SAS, IFFCC, three-position AHDU switches, and Inverter. After a further 2-5 minutes the game crashed, making a full inventory of what switched off and what didn't impossible. The various switches come from different input controllers so it is not a specific controller glitch. I have included relevant files from my Saved Games Folder, converted to .txt files. I am also experiencing the Track IR problems already reported by various users. dcs.log.txt DCS.openbeta-20160629-101947.crash.txt debrief.log.txt

This is probably a very silly question. But, where is the engine start switch in the Huey. I have read through the start sequence in the Manual, and have located the Stop switch, and I think I understand how to set the throttle. But I cannot see any Start switch. As a consequence I am forced to use auto-start.

I have experienced the same problem in the Huey and in the F-15 profiles. It would appear in my case that after re-setting the monitors and saving the new version of the profile, around half of it, including the Binding section, and some of the Interface section are not saved. If you compare the size of the original hpf file and the size of the file saved after re-setting, you will find that it is greatly reduced in size. In the case of the F-15, I reconstructed a working version from the saved hpf and the original bak file, referring when in doubt to my working A-10 and P51 hpfs. I am about to start this for the Huey, but it is a slow, laborious and frustrating process. Can anyone who experiences this problem, please confirm my findings about the file saved after re-setting monitors being much smaller that the original. More importantly can anyone suggest what is causing this?

You can adjust the centre detent of the throttle friction slide, by adjusting the axis in the control setting. Make the control a Slider and adjust the Curvature - it takes a bit of trial and error and varies the zoom rate above and below the neutral point, but I have not found this a great problem.

I would guess that the map reading is taken from the geometry of the aircraft model. For example if you were to jack-up the front end of the aircraft, the angle would increase. Different values on the ground would result from different ordnance and fuel loads. The in-cockpit gauge is going to read airflow around the aircraft, and would presumably be inhibited from any meaningful indication until the aircraft is moving. I have noticed that during start checks etc it moves around all over the scale.