Loophole

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}

I have been experiencing this same problem - hanging at "shutting the torrents down", for the last year or more of updates, both 2.x and 1.5. Killing the processes seems to work - the update is complete - but it seems an odd thing for the updater to struggle with so much! Just using Windows Defender; I'll have to try running as Administrator next time and see if that makes any difference.

See also these threads: https://forums.eagle.ru/showthread.php?t=174608 https://forums.eagle.ru/showthread.php?t=174756

Also this thread here: https://forums.eagle.ru/showthread.php?t=174608 As I reported in that thread, I and friends have been encountering this same problem for a while now. Comms menu randomly is available to some people, and blank or completely inaccesible to others, and who has a working comms menu changes through the course of the missions. This is even with simple scriptless missions we make for ourselves, using the latest version's mission editor.

I and my friends are constantly plagued by this problem. For the last couple of versions, the radio-comms menu will erratically disappear. Taxiing to take off, one person will have a comms menu, another person will have nothing, and a third will just get the AM/FM/UHF 'banner' but no options. A few minutes later the person who had no radio options will suddenly have them again, and the person who had radio options will have nothing! It seems to be completely random. This is both in older missions downloaded from the internet, and in brand new, simple missions we make ourselves. These are missions that have no scripting - nothing but a few simple trigger actions. It is frustrating, since it makes a lot of missions unplayable - no AWACS, no JTAC, etc. I'll have a look at the commands thing Fisherman82 mentioned, though I'm not sure I understand their post!

I ran the MiG-21 installation test again, with the autoupdate_dev.cfg file installed, as you requested. Behaviour did not seem to change - still hangs on the "Shutting the torrents down" dialog (left it for 30 minutes - no progress, no CPU used or IO counted) I tried attaching my Visual Studio 2013 debugger to it, but without symbol information it could not tell me anything useful. Log file attached. I'm happy to run further tests if required. autoupdate_log.zip

OK, I tested it by attempting to re-install the MiG-21 module (currently it causes a non-fatal error on startup, so I had uninstalled it). I have attached the log file, plus some screenshots of the process information. The log shows the torrents as being shut down, but the dialog remains. Killing the "waiting for torrents to shut down" dialog process does not allow the installation to continue; I have to kill both updater processes. I can generate a crash-dump of either or both processes, if that is of any help. The MiG-21 startup error message is unrelated to the torrenting, I just mention it in passing, and it happened to be a convenient module to test with since the rest are all happily installed; I'll get around to logging it as an issue in its own right. It's MiG-21-specific; I have no problems with the other 10 or so modules I have installed. Logs and screenshots.zip

Just the standard Microsoft Windows Defender. I can test disabling it if that would be helpful.

DCS Updater 2.6.15.58 Still hangs "Shutting Torrents Down" I encounter this problem every time there is an update, or I install a module. The updater runs (apparently to completion), but then hangs at the "Shutting Torrents Down". I've left in that state for over 2 hours on one occasion, with no change. The processes are performing no IO and using no CPU. Killing the processes will then allow DCS World to start, and all seems normal thereafter. This is on Windows 10. The autoupdate log does not seem to have any information beyond the "Shutting torrents down" point.

Beeroshima, yes you can (assuming you mean the A-10 RWR) - though you don't actually "export the RWR to Helios" as such. Rather, you tell DCS to display the RWR in a separate viewport, and align that with a "hole" in your helios panel that it can show through. Captn Zeen's A-10 panel is set up in this way. You have to edit one of the LUA files in DCS to tell the RWR to look for a specific viewport, and then define that viewport in your MonitorSetup file. For my screen setup, I added a viewport definition to my DCS World\Config\MonitorSetup\mysetup.lua file, like this (your coordinates and filename will be different!): AN_ALR69V_SCREEN = { x = 960+600; y = 2160+161; width = 175; height = 175; } In the DCS World\Mods\aircraft\A-10C\Cockpit\Scripts\AN_ALR69V\indicator\AN_ALR69V_init.lua file I add the following after the first "dofile" in the script: --- MB customisation: --- dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") render_target_always = false purposes = {render_purpose.GENERAL} try_find_assigned_viewport("AN_ALR69V_SCREEN") --- end customisation --- Note that script-patches like the above get overwritten every time there is a DCS update, so you have to reinstate them! Hope this helps!

Don't delete it! This was the only post that answered my question as to why I couldn't install the Mirage under my DCS 2.0 Alpha! For some reason, after running the 1.5 updater, the 2.0 updater failed to update - it would just flash up saying "updating", then go straight to DCS 2.0 without updating. A day later, after reading this post, I tried again running the updater from the Start menu, and this time it updated! Maybe a transient issue somewhere?

I have checked this in the beta version 1.5.0.45655, and the problem is still present. I noted that icons rendered onto the map are not distorted, only the map objects themselves: - The effect can be seen when zooming in on a town: the buildings are not 'square' - Also, the MGRS grid lines are not 'square'

I can confirm that this issue has been resolved in beta version 1.5.0.45655

The effect seems to be like the objects become semi-transparent, resulting in odd appearance and flickering. I have seen this on bridges, and on Shilkas when viewing them through the TGP in black hot or white hot mode. In normal TV mode they render correctly. While a thermal image might have some ability to see "into" an object (if there are hot things inside, like an engine), I doubt I should be able to see through a concrete road bridge clearly enough to make out the support pylons and the stream running under it! :-)

Looking at the behaviour of this issue in my multimonitor system, I suspect the problem is that, although the F10 map is correctly displaying itself on just the primary viewport, instead of calculating it's extents based on the aspect ratio of the target viewport, it is instead still using the overall aspect ratio of the full desktop.

Problem seems to occur with most custom exports other than the two 'standard' A10-C MFDs. I export the following in addition to the MFDs: AN_ALR96V, CMSC, CMSP, DigitalClock and UHF_Radio (freq_status, preset_channel & repeater). All of these latter exports exhibit the problematic behaviour. It is worth noting that in order to export each of these, the ???_init.lua file for each one must be customised with code like this: --- MB customisation: --- dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") render_target_always = false purposes = {render_purpose.GENERAL,render_purpose.HUD_ONLY_VIEW} try_find_assigned_viewport("AN_ALR69V_SCREEN") --- end customisation --- Now maybe there is something new that has to be added to that custom code to make the rendering work in 1.5, or maybe it can only be fixed by a change in the rendering logic. (BTW, it would be nice if all renderable instruments had a viewport mapping built in by default!) Hope that adds some useful information for this issue - it's going to be a real pain for me if it can't be corrected!

By my understanding, there are no default viewport mappings defined for most of the instruments, just the MFCDs. I've had to edit each specific instrument's init LUA file (under mods\aircraft\???\Cockpit\Scripts\???\indicator\???_init.lua) Typically, I have to add a bunch of lines like this at the top of each file... --- MB customisation: --- dofile(LockOn_Options.common_script_path.."ViewportHandling.lua") render_target_always = false purposes = {render_purpose.GENERAL,render_purpose.HUD_ONLY_VIEW} try_find_assigned_viewport("AN_ALR69V_SCREEN") --- end customisation --- However, this still suffers from the "no erase" problem that seems to be plaguing everyone with multi-monitors at the moment. Note also that not every instrument init file is the same. A few already specify a "purpose" line, which needs to be commented out do that the above additions can have effect.

It would actually be really neat if they could set the F10 map up to look for a dedicated viewport (e.g. "MAP") and render in that if found - that would allow multi-monitor users to control where the map is displayed!

Oh, and remember that the gauges won't respond until you unpause the sim - I'm sure you knew that already, but it was worth mentioning!

IndiadamJones, Sounds like you have a couple of different issues; I'll try and help. - Gauges not responding. I think this has to be a problem with the Export.lua script. That is the only thing I know of that can cause that behaviour. The current iteration of the Export.lua in this thread is pretty robust - it generally works whether you start the Helios profile before or after jumping into the cockpit. If the gauges are not responding, that indicates that Helios simply isn't connecting to the Export.lua. Either it is still in the wrong place (despite what you think :-), or it is corrupted in some way. There is a log file that DCS generates - I think it is the one in Saved Games\DCS\Logs (it's been a while since I've had to use it). Check that for any error messages about the Export.lua. Also, what is the exact path where you put the Export.lua? I noticed in your original post that you say it is in "saved_games", which if literally true, isn't right. My Export.lua, as an example, sits in: "C:\Users\Loophole\Saved Games\DCS\Scripts" Best way to get to the right folder is to click on your user-name in the Start menu, then look for "Saved Games" in the folder that pops up. - Grey background blotting out the Shkval. That is something set in the Helios profile, I think. Sounds like it is either a panel or shape, or if you are sure there are no objects, then an overall background colour set for the monitor. In the Helios editor, if you pull up the Properties for the monitor, you'll see there is a "Background" section with a "Fill" option and a colour. That might be what is doing it. Hope this helps a bit.

Thanks for the mission! Four of us flew it online tonight, using just the dumb ordnance as fragged. Most enjoyable. Liked the navigation directions based on box designations. The first task went well, though the helicopters seemed to hang around for an inordinate time after the "We've picked him up and are out of here" call, before leaving. The second task went well also (though my team-mates kept stealing the kills on the targets the JTAC gave me). However, after the JTAC gave us the all clear, nothing else happened - we were left a bit unsure whether we were supposed to RTB, or wait for new tasking (we had enough ordnance left for probably one more task, since one fellow had to fetch a new aircraft from base :-). In the end we just headed home and landed. A nicely done mission. Not too over-the-top, so the less experienced pilots were able to have fun and be effective. Challenging enough for the more experienced pilots to have some fun low-level strafing and dodging AAA!

Very pretty! Nice work - thank you. Thanks also for the HSI corrections - I've incorporated them into the file attached to my post.

Latest DCS versions fix the alignment problem. I replaced the attached file MELIOS.TGA in the FUI / Common folder. This version gets rid of the black masking around the crosshair. Might help. (I had to Zip the TGA file so it would be accepted as an attachment - please unzip before use!!) MELIOS.zip