Loophole

I've seen previous reports of this issue (e.g. https://forums.eagle.ru/showthread.php?t=232935), but I can still reproduce the problem in Open Beta build 2.5.5.34644. Is the fix still "in the works" somewhere, or is it actually still an active bug? I can reproduce the problem 100% of the time as follows: 1. Create a mission with the Stennis, and an air-start F/A-18C marked as "client". 2. Ensure the air-start F/A-18C has NO WEAPONS ON IT. 3. Run it in Multiplayer as server and land the F/A-18C on the Stennis 4. Refuel and load AGM-65F on stations 3 & 7. Add some AIM-9Ms on the wingtips because no self-respecting Hornet pilot flies without some A2A weapons :-) 5. Take off. 6. Try to employ the AGM-65F's. Everything works except the Maverick page shows "TIMER: 3.00", it never counts down, and the missile never allows launch. You can lock on to targets with either missile, and the show "RDY", but you can never fire them. 7. Wait 4 minutes with the Maverik page displayed for the one station (3 or 7) - still no joy with either missile. Am I missing something critical here, or is this still a known issue?

See also this excellent report, with video demonstrating the problem: https://forums.eagle.ru/showthread.php?p=3983600

My flight-sim group is also encountering this issue pretty much every time we fly from a carrier. There have also been instances of aircraft (F/A-18s primarily) spontaneously exploding when stationary or taxiing slowly after landing at an airbase, with no other aircraft in the vicinity - I don't know if that might be another artefact of the same issue. - Good work with the video demonstrating the effect, BTW!

Actually for me the WebGUI will work on some systems and not others. I have two PCs with DCS installed, and Firefox. Both identically configured as far as I can determine, yet on one I can fire up the dedicated server and the local WebGUI will connect just fine. On the other I fire up the dedicated server, but the local WebGUI claims "server not responding" and won't connect. Have not been able to figure out yet what is different between the two!

I'm still encountering this problem - but weirdly, only on one of two PCs. On one PC I can run up the dedicated server, then start the WebGUI and connect to it just fine. On the other PC I start the dedicated server and the WebGUI, but the WebGUI reports "Server not responding". As far as I can tell the two systems are identically configured; nothing I have tried has been able to get the WebGUI to connect to its local Dedicated Server on the second PC.

I tested the "Sea Shelf Objects", "Oil Rig" model, and the maximum view distance seems to be about 10km. Beyond that it vanishes completely, despite being large enough to be quite visible at the 10km mark. In contrast, objects like the permanent static oil tankers floating around on the map have a visible range of around 60km. Oil rigs and other large static objects should have a similar visibility.

I think that part of the problem is that the fonts and lines on the DDI, MPCD, RWR and HUD are all being drawn at a set pixel-thickness regardless of zoom (if you zoom in or out on any of the displays, you can see that the lines don't change thickness; they are rendered a set number of pixels wide). In some ways this makes sense - the displays remain equally readable as you zoom in and out on them. However, it uses those same thicknesses when rendering exported displays - and if the exported display is of a lower resolution (e.g in my case a 1920x1080 display compared to my 4k main monitor), the chosen thicknesses are too fat and fuzzy. Likewise if you tweak the thicknesses so they look Ok on your exported display, that same thickness is too thin and weedy on the main display. With a number of hacks to the lua files to enable separate control over the DDI, MPCD and RWR font renderings I have been able to come up with settings that are an acceptable work-around for my particular display and viewport configuration, but whether that is possible for anyone depending on how their particular display sizes and viewport sizes are set up. I'll try and get my particular set of hacks packaged up and post them - they touch on some files not mentioned previously in the hacks along these lines.

If you pull up the Windows Device manager, and use the menu to switch it to "View Devices by Connection", you can usually identify which USB Hubs your joysticks and TrackIR connect to, and check them to see if Windows is allowed to turn them off. I've been having a similar TrackIR "freeze up" problem - typically if I leave it paused for too long while running through a lengthy startup checklist. It unfreezes if I unplug and replug the TrackIR, or if I swear at it for about 20-30 seconds. I have used the above approach to ensure all the relevant USB hubs for my joysticks and trackIR can't be turned off by Windows, and will see if that fixes the issue.

I have recently been experiencing a similar issue - though with a much faster flashing rate, and only intermittently. For me the DCS logo will flash up for only a frame or two, maybe twice per second. It starts happening at some point during a mission, and might persist for 5 minutes or so before stopping. It appears to be linked to being in Borderless Windowed mode stretched across several monitors (two in my case). If I press ALT+ENTER while it is happening, to compress the display onto just full-screen on my main monitor, the effect stops, but resumes if I ALT+ENTER back to borderless-windowed mode. I strongly suspect it is a video driver related issue, as I have friends using DCS in a similar configuration (multi-monitor, borderless windowed) who do not experience the problem at all. My video card is an nVidia GTX 1070, running driver version 398.82. DCS Open Beta 2.5.2

You can almost achieve this. The display part of the NS430 can be mapped to a viewport, just not the rest of the panel (i.e. the bits you need to actually control it). I guess if you mapped *all* the NS430 controls (and maybe created a Helios panel for it) you could do without the NS430 pop-up panel at all. I just added a Viewport to my MonitorSetup file; e.g. NS430 = { x = 10; y = 10; width = 900; height = 600; } then made the following change in the NS430_init.lua file: purposes = {render_purpose.GENERAL} --- MB customisation: --- dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") try_find_assigned_viewport("NS430") --- end customisation ---

I've observed a number of threads on the forum from people like myself who are encountering problems with the pop-up NS 430 display on non-trivial multimonitor setups. The problem arises because the NS 430 pop-up seems to always default to the lower-right corner of the DCS World window, but on complex multimonitor setups that location can often be off the edges of the physical screen displays. I think it only needs two changes to address the problem: 1. Have the NS 430 popup window persist it's XY location between sessions, and always redisplay at the same location next session. 2. Either add some settings in the DCS World options page to manually change the XY location for the popup, or add logic to the program to check its location against the physical display layout, to ensure it is actually on a physical display. The latter is probably a more complex solution, but would avoid initial user confusion and forum-searching, and anyone smart enough to set up a complicated multimonitor setup can probably figure out the right coordinates to put the pop-up onto a visible display :-) Sadly, the NS 430 pop-up window is rendered as an in-game element, not an actual "Windows" window, so an external scripting solution like "autohotkey" can't be used to work around the problem. I have also examined the visible LUA script in the mod and haven't spotted anything obviously controlling the popup position.

I'm having this same problem - the NS430 is currently unusable on a non-trivial multi-monitor configuration. Is the default location of the window stored in a config file or a LUA file somewhere?

Hmm, some two years after these posts above, and still no keybindings for Master Arm On and Master Arm Off. Indeed, there is (oddly) a "three position switch abstraction" for master arm - even though it is a two-position switch! Would like to see some attention to these small items at some point!

I also have always experienced this issue, with every updater version including the latest 2.8.1.58 (which I am currently watching sitting on "Shutting the torrents down..." as I type this). Killing the two updater processes seems to be Ok - the update is complete, but always it hangs there. I've even left it sitting overnight - still hung in the morning. Interestingly, the autoupdate log seems to think the torrents were shut down - even though the UI is apparently hung waiting for them! Logs attached - hope they help! AutoUpdate Logs.zip

I can confirm that the UIMainView hack does indeed fix the positioning of labels, but sadly screws up not just shadow rendering (as mentioned), but also the rendering of smoke markers :-( All of which is insane - the UIMainView setting should have nothing at all to do with the rendering any of these things! Something is seriously screwed up in the depths of the code here!

The repair didn't help, despite the downloaded files. Which is very odd, because the problem looks like it was caused by a bunch of corrupted files in the bazar\textures and bazar\world folders. Just a few days ago I moved my DCS World installation onto a new SSD, and had retained the installation copy on the HDD for backup, so I was able to do a fulll comparison of the two folders. On the SSD copy there were a large number of files in the bazar\textures and bazar\world folders that were the same size as their HDD originals, but filled with nulls. The weird thing was, this was AFTER running "Repair" on the SSD install. I ran "Repair" again to be sure, and it downloaded nothing. Finally I had to delete the bazar\textures and bazar\world folders entirely, and re-run "Repair"; it then downloaded about 5GB, and a file comparison showed everything was now intact. After that I ran a test using the A-10A "Instant Action" mission stand-alone. When I ran it before the final (successful) repair it exhibited weird graphical anomalies - the world outside the cockpit rendering black, missing textures on the control panel, weird figures on the HUD, etc. All consistent with the empty files I discovered. After the final delete-and-repair, everything was back to normal. So, the crashes noted from my logs were probably all caused by these corruptions. The only questions now are: where did they come from, and why did Repair not notice and rectify them?

Ran a "Repair" on my installation - it decided it needed to download 156MB of fixes. Some of that will be just LUA files I customise to run Helios instruments, but there must have been more than just LUA files it decided needed to be downloaded. (my customised LUAs only account for 87kB)

Fourth rejoin. Just stayed in Spectator view while people cleaned up the last AI MiG-15. No crash, until watching a friend in an F-86 engage ground targets at the enemy airbase using GAR-8's. First attack missed, and caused no problems - just a large explosion near my viewpoint. Second attack hit something out of my line of sight - crashed DCS. Log: https://www.dropbox.com/s/8h2pfunlzk5e0l4/dcs.log-20180314-113540.zip?dl=0

Third rejoin. Tried to join in an A-10A. First attempt seemed to leave me in Spectator view. Tried again in a different slot : crashed again before even seeing the cockpit. Log: https://www.dropbox.com/s/5ppjzwkl71mukzj/dcs.log-20180314-112305.zip?dl=0

Second rejoin of the same mission. Again got about 10 min flying, found an AI enemy and started ti turn with it. A friendly Spitfire crashed into the ground somewhere (not nearby) - crashed again. Log: https://www.dropbox.com/s/bthljfnmd5rd4gb/dcs.log-20180314-111659.zip?dl=0

Rejoined the mission (which was still continuing), and flew Ok for maybe 10 minutes. Joined the furball, but crashed again just as I was watching an AI MiG-15 hit the ground nearby. New log: https://www.dropbox.com/s/3l7wc0obrih9je3/dcs.log-20180314-105857.zip?dl=0

Trying a multiplayer session, with player MiG-15s, F-86s and a single Mustang vs AI MiG-15s. Flew out to engage, then crash occurred shortly afterwards after a player F-86 was shot down. I was simply manoeuvring at the time. For crash log see: https://www.dropbox.com/s/8q19lrklcocixdm/dcs.log-20180314-103433.zip?dl=0 (Attachments don't seem to work at the moment)

I have also experienced this same issue, for many versions now: the installer hangs at "Shutting the torrents down" and the processes have to be manually killed. I seem to recall that at one time I have a second PC I used for LANs that was running Windows 7, which didn't seem to suffer the problem, so it is possible the issue is associated with Windows 10 or 64-bit systems?

Its odd - I've been trying to add some startup quick-reference pages for the Viggen, using the normal mechanism (adding appropriate JPG files to the Saved Games/DCS/KNEEBOARD/AJS37 folder) and it doesn't work. I checked the logic in the init.lua in Mods\aircraft\AJS37\Cockpit\scripts\KNEEBOARD\indicator, and it looks like it ought to be working - it appears to scan lfs.writedir().."KNEEBOARD" and the aircraft-specific subfolder, but the custom pages from either folder never appear. What does seem to appear, though, are about 60 "blank" (transparent) kneeboard pages in addition to the pages generated by the AJS37-specific lua scripting, so I think there is still some sort of bug in the kneeboard scripting logic. If I could figure out how to attach a real debugger to DCS's lua scripts I'd try and fix it for you, but I haven't figured that trick out yet!

I can't give you model enlargement, but you can get a crude enhancement using customised labels. If you put the following in your Saved Games\DCS\Config\View\Labels.lua file, you will get range-limited, dot-only labels that don't show which side the target is. Its not perfect - the labels show through clouds and the cockpit, but it might be an acceptable stop-gap for you. -- Label parameters -- Copyright (C) 2004, Eagle Dynamics. AirOn = true GroundOn = true NavyOn = true WeaponOn = true --------------------------------- -- Label text format symbols -- (Symbol): ` [ ] { } ' | ~ -- %N - name of object -- %D - distance to object -- %P - pilot name -- %n - new line -- %% - symbol '%' -- %x, where x is not NDPn% - symbol 'x' -- %C - extended info for vehicle's and ship's weapon systems ------------------------------------------ -- Example -- labelFormat[5000] = "Name: %N%nDistance: %D%n Pilot: %P" -- up to 5km label is: -- Name: Su-33 -- Distance: 30km -- Pilot: Pilot1 AirFormat = {} AirFormat[40] = "" AirFormat[400] = "%P" AirFormat[500] = "" AirFormat[10000] = "`" AirFormat[20000] = "`" AirFormat[30000] = "`" GroundFormat = {} GroundFormat[500] = "" GroundFormat[10000] = "`" --GroundFormat[20000] = "`" NavyFormat = {} NavyFormat[500] = "" NavyFormat[10000] = "`" NavyFormat[20000] = "`" NavyFormat[40000] = "`" WeaponFormat = {} WeaponFormat[400] = "" WeaponFormat[5000] = "`" --WeaponFormat[10000] = "`" -- Colors in {red, green, blue} format, volume from 0 up to 255 ColorAliesSide = {183, 91, 1} ColorEnemiesSide = {184, 91, 0}