Leg2ion

Hi @Floyd1212 - many thanks for the response - as that would be so much easier, but for some reason it will only calibrate/setup if I unplug/replug it back in with a USB lead to carry the touch commands. I can then select screen 1 as main and screen 3 as a touch, but if I reboot the PC screen 3 loses its abilities to maintain the touch capabilities and they show up on the main screen.

Hi All, Reaching out for advice and assistance - please. I have a 4 monitor set up, 1 x 15.6 touchscreen (recently purchased - bit by mistake - don't ask!) - so attempting to use with Helios, 2 x 27 curved main screens, and one 11.6 monitor for MFD exports. The 2 x 27 are idented 1 and 2, the touchscreen 3 and the 11.6 as 4. However, the rub is that in order for the touchscreen to work properly and detect touches on its screen - it needs to be selected as the main screen - so the monitors are set up in order 3, 1, 2, 4, to account for DCS being pedantic about taking x/y as 0/0 from the main screen. I set the main viewport up so that the display HUD central point was about 2 thirds across screen 1 by adding a value to the x (1080) - so in effect the viewport starts 2/3 across screen 3 (leftmost), and extending across screen 1 and 2, The above alignment was OK, but I cannot find anyway to blank the background of the touchscreen in this configuration so that the only display is the helios overlay. If I do a background fill the viewports do not display data, and if I do not I get the 3d world running behind (and visible) in the viewports. Hopefully the above makes sense - but am at a bit of a loss. The only workaround I can come up with is by moving the touchscreen above the 1st main screen so both x values are the same, then dropping the main viewport y value down to align with the main screens. Ideally I want them all in a line to assist in mouse pointer transition between screens. Any guidance and assistance well received.

Personally agree with you. I dip in and out - A10 being my main vehicle of choice - but certainly after the last few updates I do believe the flight model is more manageable/stable. I think I have a fairly good understanding of rotary wing, having maintained them for around 40 years, and have a modest amount of stick time on various helo types. When the module came out it felt like I was trying to balance a marble on a needle - slightest lapse in concentration and things went badly wrong - fast. Now I am quite content to let the aircraft do its own thing and settle into stability. Gone are the days of yawing down the runway, putting in some left/right boot and ending up in a fiery mess...

After some assistance/guidance - setting up a triple monitor display. I have 2 x27" (1920x1080) and 1 x 15.6" (1920x1080) monitors. The width of the 15" is (give or take) the same as the height of the 27" screens, so was thinking of rotating the 15" screen and placing it in the middle to give an uncluttered HUD view, to look like this: However, I either get this (grey area the DCs view) - height set at 1080: Or this - height set at 1920 - which cuts off the options top left and bottom of the right hand menu: I have tried playing with the 3 camera lua, but for the life of me cannot fathom how to set up three independent views - is it actually achievable? Would something like Helios or DisplayMagician help?

??

For what reason/use? Currently got 2xTMs for A10 mounted on a face plate on a 10.4"screen, and considering separate MPDs for the AH?

?

Thanks.

Link?

Go helo - you can just stop!

Screenshot for Nostalgia purpose sometime in 2025!

But then why should it? In that it should get additional 'features' - such as??? It is a simulation, some (me) see it as a game, TBH I only want Arc210 in the hope the pre-sets will be fixed. The sim model is based on a variant and corresponding systems (I believe) as true to life as they can be subject to information release up to a certain modification/Blok level, so once at that level - endgame. Same really as the current AH module - D model. We'el - there is now an E model - so when is that going to be rolled out in a 'DCS Modification Programme' - maybe/probably never - it is currently a simulation of an aircraft at that development (D) standard - although still enhanced from the original D model specs (TEDAC coupled with MTADS vs the older ORT as an example). Could also argue for the Brits out there why hasn't the UK DAS suite been modelled, likewise Israeli, etc etc etc... I guess ultimately as 'simmers' 'we' will never be happy (to a more or lesser degree), similar to real life pilots, and will always want the best kit, against what the simulation actually represents in terms of modelling at a particular date stamp?

From the manual: LRFD Trigger. Activates the laser rangefinder. • First detent. LRFD determines target range. • Second detent. LRFD determines target range and designates target for laser guidance.

Get Apache Learn Apache. From real life Gazelle 'sensitive', Huey 'forgiving'. If you want to 'play' with another Helo go Blackshark - contrarotating Main Rotors so no real issues over pedals, but you do learn the basics of hovering, low flight, transitioning into and out of the hover, left and right sideslip manoeuvres etc. Still learning the AH - and definitely small steps needed. Do something, so you do it well, then it becomes 2nd nature, then move on, but keep the repetition up. Worst case is you divert your focus onto one platform to learn another - then it becomes muddied, and you are constantly comparing the differences.

Yes I do! Think it's only been planned for around a couple of years so hopefully by the time it reaches the masses there will have been a full trial installation, flight and functional trials, a proof installation then productionised so all works as advertised...

Hopefully the presets will work - properly!

Hopefully that will include the A10 and we will get a finished module (hint - ARC210!).

I think... When the MR rotates, if there was no anti torque (tail) the airframe would rotate the opposite direction - so the main rotor rotates anticlockwise when viewed from the above, and the airframe would rotate clockwise. To counter this affect the tail rotor pushes the tail to the right in an anticlockwise rotation, so when you put some left pedal in - in normal flight - it pushes the tail to the right. When you increase collective pitch (as you initially pull into the hover as an example) you also have to introduce some left pedal to counteract against the increased torque - so if when trying to roll you are applying full left pedal then in effect you are introducing maximum anti torque thrust which is trying to push the tail to the right - or in this instance upwards, to maintain an upright attitude - so despite having full left stick over by going full left pedal you now have a rotor at the back end trying to maintain you upright. By going right pedal you are unloading the anti-torque effect, so would allow the aircraft to continue on its manoeuvre without trying to fight against a left-hand roll. In addition, I believe the tail fuselage is constructed in a profile that allows the AH to maintain straight (ish) flight if there is a tail rotor failure above around 50-60 kts - but not sure if this feature is modelled. If you look at the tail - it is basically a wing designed to provide lift to the right, so as you go near 90 it is acting in profile as a normal wing - so again would be attempting to maintain level flight and resist any attempt to further roll over. I think...?

BUCS is an emergency back up system, and isn't used normally unless there are issues or seizures in the control system, so wouldn't be used to transfer control... BUCS = Back Up Control System. So - both pilots/CPGS stations are linked mechanically - in the same way any (most) dual seat helicopter is designed (either side by side or tandem seating arrangement) - so mechanical rods between one station to the other. Move one stick fwd - be it front or aft - the other one should replicate the action. BUCS is a pseudo emergency 'fly by wire' system - in that the controls are locked into the overall system by cams and springs. The idea being if there is a seizure or failure in the system (bearing failure, pilot shot and leaning against the stick etc) there is an ability to knock the stick out of its mechanical connection by overcoming a certain amount of force - which breaks the stick out of its cams, and from there on in it relies on input into an linear transformer which relays any detected movement electrically to the controlling servos.

In what way? Ah - just read the updates. Out of curiosity is it possible to display both Pilots and CPG displays onto 2 individual screens, then with corresponding MPD displays onto separate mini screens? Thinking the dual Pilot/CPG MPD displays is the 'easy' bit, but is there anyway to display the CPG view onto a second screen whilst simultaneously displaying the pilots view on the main controllable screen? Failing that will put the tedac onto the second large monitor. Basically got 2 x 27" plus 2 x 11" with 4 x cougars so trying to figure out how best to utilise the space/screens!

@Bunny Clark - many thanks for your very simplistic easy to understand guidance - very much appreciated! At the risk of getting lambasted by Osram (haha ) in case there are other similar posts, just fired up DCS after a few weeks (months) away, my normal .lua file setting is set for A10c with the MFD exports being to my secondary 11" display with cougar surrounds. I did run a single 27" screen with the 11" display, but have now upgraded to 2 x 27" plus the 11" for the MFD. Kept the same .lua in place - only changed purely to take into account the additional screen now placed in between the 1st 27" screen and the 3rd 11" screen by adding to the values where required. From what I can recall - there were issues with the MPD displays - in that one would overwrite the other. With that said, went into an AH64 mission today - pilots position - and MPDs working as advertised - then swapped forward - also working and displays swapping dependent on what is selected at each position. Cannot recall seeing any indication in the update files that this was now fixed - but either way - happy days. Is everyone else getting this?

TBH I will be happy with anything that fixes the pre-sets and makes them work - properly!

As per ASAPs - if you are slow with a crosswind the HUD will drift. Try setting up a couple of training missions - onto the same runway etc, with different crosswinds, and you should see the difference.

If that did actually happen are you that bothered about what indications you get??? Look at the wings - big lump of metal and ordnance missing - no real indications needed? Regardless of what the systems say - you can fairly guarantee you cannot drop a missile off the missing launcher? As far as I know (using simple terms) there is a EMRU bolted to the wing, then 'plugged in' to allow stores jettison etc, then a launcher hangs off the EMRU, with each store being 'plugged in', so when the system is polled it details a missile load at each station. So, if the whole load sheared it may depend on how it fails, but I guess it should show the launcher in a fail state, tho ultimately how would the pilot react??? What you need to remember is the vibration and trauma to the aircraft after being hit to create such a failure, along with the human interaction and subsequent reaction would probably dictate a set of responses in line with getting their backsides back home in one piece?

Note: The ARC-210 radio is now in work. Oh Happy Days!