Scaley

The reason you are getting no input or outputs to/from DCS is because Helios can't find the interface that the profile wants to use to talk to DCS. The profile ahs the layout and configuration of controls. However, in a sperate file (called the interface) is the definitions of what "push button x" actually means to DCS and how to translate between Helios and DCS. When you create a new profile you have to choose what interface to use. The error in your Control Centre shows that the profile can't find the interface files it's looking for. Assuming Sobe's profile uses Bunny's interface file you need to install dcs.AH-64D.hif.json from Bunny Clark's post on page 2 of this thread as described in that post.

Yep, working for me too but astonishingly weak so probably easy to think it's not working.

I did this in the Huey but all the principles are the same as well as the practice methods:

Have a look at this thread and the associated monitor setup luas

This is common across all the DCS helicopters and has been known for some time (6+ months). I'm not sure if it's tracked as "reported" anywhere on the forums but I beleive it is.

You can observe this effect (to a greater or lesser degree) with all the recent flyable aircraft from ED. They are very complex models, and the LOD ranges are very generous, meaning that they render at very high detail levels a long way away. It suck FPS. If you park 20 player-flyable hornets on the ramp and compare your FPS to 20 of the old AI only model you'll see the difference there. I'd imagine the Apache will be worse.

Has anyone tested to see if the doppler helps? It appears to be off in hot-start aircraft.

If you would like photos of the Virpil Alpha and Collective with Alpha grip (which seems like it's quite a popular Apache choice) I can send you some.

The ReShade website is here: https://reshade.me/ One of the standard tools in it is called "UI Layer Mask" which allows you to mask off certain areas of the graphical output to be affected (or not) by reshade. In that way you can have a brightness boot effect applied to just one monitor and not the other.

The difference in brightness between exported and in-cockpit screen has affected the Hornet for as long as the module has been out. The generally suggested work-around is to used ReShade to boost the brightness of the exported renders.

If you look in: \DCS World\Mods\aircraft\AH-64D\Cockpit\Scripts\Radio\ you 'll find a lua file for each radio with a table of 10 presets for each. I can't work out how to alter the text for the names so I've edited: B:\DCS World\Mods\aircraft\AH-64D\Cockpit\Scripts\Displays\EUFD\Pages\PRESET.lua and edited line 36-45 to be of the form AddText("Name_0", 11.0/28.0, aspect*6/7, {{}}, nil) That removes the preset name entirely. Best I have worked out so far.

This might help: https://www.476vfightergroup.com/showthread.php?4342-NTTR-map-info-public-release

A bit more detail in video form.

Background For some time it's been known that DCS has a few issues handling very widescreen monitors as referenced in this thread and described (but no solved) in this thread. The only known workaround at present is to change the DistanceFactorDefaultFovy setting in graphics.lua to have the (intended, I assume) effect of changing the FOV that DCS considers the "default" from which to apply effects as a result of zooming the view (primarily rendering more or less objects, or altering LODs). Bug In a recent patch a new bug appears to have been introduced where setting the DistanceFactorDefaultFovy to settings above about 110 creates a clipping effect on objects on the Marianas map leading to them disappearing. Further increasing the FOV setting increases the amount of object disappearance. See attached video which was captured with the DistanceFactorDefaultFovy set at 150. This effect has not been so far observed on NTTR or Syria maps. No other maps have been tested by me so far. This bug is interacting with the known DCS view distance calculation "feature" where the distance to an object for LOD/rendering purposes is measured as the vector component distance parallel to the observers line of sight, not the total straight-line distance from the observer to the object. This is responsible for the well described effect where objects are visible at greater distances near the edge of the screen vs the centre, and this effect is exaggerated with increasing FOVs due to wider monitors and/or lower zoom levels. This I assume is why the objects in the video disappear based on line of sight as well as distance and zoom. EDIT: This bug is also possible to produce on the Syria map, it just appears very few objects are affected and the range of distances over which they disappear is smaller.

And another update in the wonderful world of DCS... The above fix does not work correctly on the marianas map. If you se view settings above FOV 100 on that map there is a strange graphics bug where tree disappear at certain LODS. The higher the defaultFOV setting, the more LODS disappear. It now seems that view distance and LOD settings are being handled totally differently on different maps, meaning you may need different DCS graphics settings optimised specifically for each map... Yay...

Just coming back to this topic as I've run into the same problem and there is a simple solution I've found. in graphics.lua there is a setting "DistanceFactorDefaultFovy". This does what it says on the tin and sets what DCS considers the default FOV to be, and therefore the reference to apply the LOD distances to. If you increase this then the problem described goes away. For my 40" ultrawide I've now got mine set to 150 instead of the default 90. As per the DCS instructions this edit is best done via autoexec.cfg in saved games so you don't have to re-do it on each update. Instructions for this are in dcs/config/graphics_readme.txt

I'm getting this on Mariana, Syria and now NTTR as well. Mainly it's trees for me, but the rendering distance for tree with everything set to maximum is about 4nm, which is WAY less than it used to be.

Just found this thread and wondering if you could share where you found the files that control the tree LODs. I'm getting a connected bug/feature where because I'm on a very widescreen monitor my tree rendering is now only about 3 miles away on the maximum setting.

Clean win11 install a few months ago. No noticeable difference form win10.

Yes, just create the folder as required.

OK, I'll have a try. I hadn't quite followed the code through to be able to work out if the script would give 5-lines for every enemy it detected, or only the ones it spawned itself.

What I'm getting at is that at the moment the script spawns the forces and then provides the communications and CAS 5line to players. There might be circumstances where mission designers wanted to hand place the units in an exact way and then use the script to request fire support, issue the 5-line, and have the other functions. If there was a version where instead of the spawn logic the units could be already in the mission and then added via a filter this could be easily done by re-using big sections of the code.

Just found this and wondered if you'd considered a lightweight version that just had the comms and 5-line functionality so mission designers could add it to a mission with existing red and blue forces?

Isn't this a DCS limitation in that you can't specific two difference guidance types for one missile on a ground unit. I guess given the choice whoever originally made it chose the optical instead of the radar. I don't know of any DCS air-defence that actually has different sensors modelled.

I have zero experience with apple products, but the link works on 3 PCs and 2 android devices I've tried. Might be worth trying it on anther device I guess. You could also try the link from the homepage of the CaptZeen website. http://www.captzeen.com/helios/index.asp https://discord.gg/sS66aJf