Jump to content

Avernus

Members
  • Posts

    89
  • Joined

  • Last visited

Everything posted by Avernus

  1. I see, so the previous behaviour was corrected. Also yes my mistake, i missed a step there with the NVS switch, which was not required earlier iirc. For some reason however, I still need to enable NVS, and switch sensor mode to from PNVS TADS with NVS enabled to get polarity to change at times since the change. I'll see if it's not something with the hotas sync. Polarity might not be such an issue if we could disable auto flir gain too maybe.
  2. Since the later versions of DCS, George has been zooming the Tads out after the initial zoomed in scan, making it a lot more difficult to VID when watching the tads as we cycle the target list. I'm not sure if there are any features planned for control over these particulars, but it would be nice to have this behavour reverted until we can get george to to stuff. Thanks.
  3. Pilot is unable to select Tads polarity as before. Unless PNVS is enabled first> select Tads sensor> switch polarity> disable PNVS. Thanks.
  4. Ya, i saw that. These are 3 different cards, using ddu to clear drivers on a completely new system, with only NTTR in that area affected. Very strange problem, Could displayport be a potential cause perhaps? There was a wierd issue i had with an MSI card that refused to boot the system at all, no POST if the DP was connected at power on, HDMI was fine. RMA was not approved due to no actual fault of the hardware. I guess no NTTR for me anymore? This is unlikely to be resolved by anything less than a wildcard lucky dip, as buying new gfx cards over and over is not a practical solution Maximov Humour me if you will please. Set the graphics driver to the maximum power target allowable and retest this issue. Do not limit framerate target, set texture quality in driver to 'high quality' and disable 'surface format optimisation' Use freecam mode to fly around the area and allow the gfx to plateu for thermals and power/clock levels. Use high speed at low alt for as long as you can tolerate. use various camera angles to throw the gfx power/clock values around a bit. The time of crash for me would appear to be random. I'm going to attempt this test again on a friends PC later when i get the opportunity. Thanks again.
  5. More fun testing with 21.10.2 Crash, sent report via dcs. No dx11gideviceremoved error, no gpu reset this time. Just a straight up freeze/crash. Acces violation.
  6. Ok here's an update on the situation. I've reverted driver for both Radeon and GeForce cards to 19.2.2 and 362.00 respectively. For the Radeon V64 card, the Max GPU frequency has been set to 1632 as default. For the GeForce 980, the cards base clock is set to 1203, and boost clock varies with a approximate max of 1304. For both cards, using driver Radeon 21.10.1 and Nvidia 496.13, These values are slightly increased and display higher variance clock speeds during positive throttling. Potentially resulting in this type of crash, of which DCSW seems to be very sensitive to, while other games such as Metro Exodus have no problem for hours. At the time of writing this, The Radeon V64 card has been hovering around the described area for close to 30 minutes now, which is potentially better than the usual random but small timeframe window as previously experienced. Both cards appear to be a lot more time sensitive to power and clock throttling with these earlier driver sets. The Radeon card doing it's best to not exceed 1632Mhz at +50% power and full fan speed, Core and Vram clocks set to 'Dynamic'. The Gtx 980 is also stable, no matter what i do, even overclocked +200mhz offset for core and +700 offset for Vram @+25% power target and maxed out fan speed. I have yet to test the Rx 6700xt, but have my doubts as the driver version is likely to predate the hardware. Preliminary conclusions: Newer isn't always better. Both companies Ati/Nvidia may be attempting to push the cards harder than expected. DCSW is attempting to use more power and clock value variance than the driver will allow in very specific cases, which the other maps do not exhibit. DCSW NTTR on V64 has been running hovering at low speed low alt freecam for over 30 mins now. This problem appears to be related to drivers and NTTR gpu/power usage. Newer Nv and Ati card users may have to hunt for earliest possible driver versions which predate the hysteris update, which in turn appeared to have lowered sampling rates from the Hardware, causing potential overshoots and subsequent crashes, regardless of underclocking attempts, Or request the Gfx driver teams to reinstating the faster HW monitoring update rate. Regards. No crashes this time. Not a hardware issue x3 :)
  7. Extending the TDR resulted in the same driver crash, and this time DCSW froze with no error on exit. From the HW logs of all 3 cards, I have noticed one thing in common. The moment before the crash, the GPU clock will exceed the maximum set frequency. For example the V64 card is set to 1630(max) and the log and LCD screen on the keyboard will display 1650mhz, just as the program crashes. I have a feeling this may be related to the power target value. Thoughts?
  8. Ah, the 'crashes' of doomvk/glquake are intentional, steam glquake is beyond out of date and crashes always, had to manually update. Doomvk, was terminated by user on startup. As for DCSW NTTR, there needs not be an aircraft used in my case, just a freecam fly over the area, give it time, perhaps push the resolution to 3840x2160 via VSR/DSR. Fly the camera low enough around the area, a simple once over may not be enough. This crash reminds me of when DCSW would throw me an error and crash when the FOV was set to or exceeded 150' with multiple screens, early 2.x versions. ED 'fixed' it by limiting the FOV to 140 which was impractical, thus i switched to a single screen. I'll try running the test again at 1920x1080 resolution with the vega card and report back. Edit: same result, attempting to extend win10 TDR delay via registry.
  9. Thanks for the response, The default frequency is set @ max @1630, i manually tweak the pwr to +50% and use a custom fan curve which maxes out at +60'C 3200rpm. I've tested with the Vega64 set to -10% core underclock @1467 and power to -50%, fan curve maxed out flatline. Vram is detault @975 stock/auto voltage, tested @900 to be sure also. For your amusement, I've attempted the test at 1920x1080 instead of 3840x2160, and set ui scaling to 1. All other settings remain as they are, DCSW crashes following a lot of hitching and small pauses with the mi-24, ending in the same crash. The position isn't always the exact same, but always within 5km of that area. As noted above, the new card is an ATI 6700xt, same exact problem.. and an older Nvidia gtx980, same result with a different gfx driver reloading affair than Ati. This is also a completely new pc. With the only remain components being Displayport 4k monitor, Creative ZxR, TMWH, Trackir, Pedals, and the main SSD for OS/DCSW on the same drive, oh and the tower and cables :) SSD was 'cleaned' using diskpart and repartitioned etc before the OS install and a clean install of DCSW. SSD was set as GPT instead of the prior MBR. I have pinned Win10 to 1909 as the newer build has messed something up with game controller hid devices and system standby/sleep. However during previous tests on the newer build 21h2, the outcome is the same. DCSW crashes, then gfx driver reset. To rule out and power/heat related potentials, I've run a 24 hour prime95 torture on CPU, and the MSI Kombustor program to try set fire to the gfx card. both ran for hours with no issues, while having the gfx maxed out @+50% power. with the problem following a new system, and persisting over 3 different gfx cards, it seems unlikely to be a hardware issue. or can i be just THAT unlucky? Only this map in that area, Surely not. Regards
  10. As requested here is the log Tested again, clean map, no units, used free cam to 'fly' over the area, and the result... DCSW crashes, followed by the standard GPU driver reset. All system settings are at default. There should be a new report on the server to follow. dcs.log-20211110-014635.zip
  11. Going to re-open this issue. I now have a new pc with all new hardware (except Hotas/Trackir/Pedals/Screen), Fresh install of OS and DCSW, This problem is very much still active. Approximately same place, same exact error. New gpu with power levels throttled to -50%/clocks @ stock and cpu features disabled to be sure of any potential factory OC issues. DCSW crashes followed by the Radeon driver reset as usual. Tried an old GTX 980 card, windows also reset the gfx driver around the same location. This is NOT a hardware issue. Other maps Caucusus/PG/Normandy/Marianas seem fine for hours.. Flying in NTTR near the location described results in a crash 8/10, with the Mi-24 having the most problems thus far. The game will hitch a lot before throwing a crash in this instance. Track file provided is not 100%, but if i play it enough times the crash is certain. Although i have my doubts as to whether my screen configuration is a potential suspect, Is it possible Displayport+10Bpp features enabled could cause such a specific problem, Just for NTTR in THAT spot?
  12. Hello again, Has this issue been looked at? It appears the Hind is not the cause for this, as I have flown several aircraft over this area with the same results. I have Reinstalled OS clean along with DCSW, file corruption is unlikely in this case. No mods or alterations, Just a clean DCSW install. Flying over this area will eventually throw DCSW out with a 'stopped working' error. ATI Radeon driver also restarts in some cases, but not always. I've set the card to -50% power and underclocked it a bit to rule out any hardware issue, This did nothing to supress the crash.
  13. I suspect the issue described is due to 'auto-start' potentially doing certain proceedures out of order. To check, Wait for the 'auto-start' to complete Use the 'Autopilot Disengage' button Reset trim Reset the ADI using the 2 'Cage' buttons. Re-engage SAS as desired. Set trim Let us know how this goes. The 'Control-helper' feature may have problems of its' own due to the WIP nature. Recommend not using these two features for now.
  14. Hi there, A quick bug report on the 'Air-Speed Stabilize' ACS feature. The buttons are getting stuck [IN] when used with keyboard bindings, Switches release as expected with mouse input. Thanks.
  15. Hi I have experienced a very persistent crash while flying the Mi-24P on the Nevada terrain. Approximate Coords: PV87 N 35'55'9 W 114'55'47, construction area north-east of solar panels. Flight route: Roughly 245' 7km from Boulder City Airport. edit: Here's a quick and nasty track which shows the issue at slightly different times when near the area each time the track is played. I've noted a dxgi device removed error driver restart will follow with most but not all attempts. Setting GPU to -50% power target/underclocking/undervolting had no effect on the crash. Thanks. server-20210701-235507.trk dcs.log
  16. HI, a slight issue with a few of the Sabres switches. Fuel densitometer Generator Emergency air ignition The covers will respond to the mouse, the switches do not. Thanks
  17. When you use the target software, the Hotas is combined into one device. As such DCSW will see this as new/other hardware, and use preset defaults as always. Due to certain limitations with DInput, you will not be able to use every button as defined by Microsoft due to there being to many DInput buttons for the API to handle. You may require some of the Hotas buttons to be keyboard inputs used by target instead. As for the zoom slider, re-check the Axes panel in DCSW with the combined Hotas active via Target program. If you run the Hotas without Target, each device is separate and as such will not exceed max DInput button cfg , requiring it's own configuration not related to the combined Target Hotas. As such you may find 3 Configuration files (throttle,stick,combined) and they are not interchangeable. Be aware, there can be a slight problem with initialization at times which can lead to having all 3 active in DCSW. The solution is to simply disable/enable the combined profile and have DCSW re-detect, however this has been a very rare experience.
  18. If one opens the canopy with MiG 21Bis, flood lighting enabled, look to the left, away from the glass. Flickering gone? sorta?
  19. For me with NV or ATI It is the screen space reflections. Any light reflected back at the canopy may produce a corona effect. This is where i see heavy flickering. Complete showstopper.
  20. Try the Mig-21Bis again. Enable the red cockpit lighting under the warning panel. That's all it takes for me.
  21. Yes, I have this problem as well. The red cockpit lighting responsible for screen space reflections on the canopy seem to trigger this, using the periscope mirror only makes it worse. That being said, i was only able to reproduce this issue on my Radeon. Same test with Geforce card did not seem to have the issue.
  22. Provided are two files modified to 110 degrees fov for most aircraft. This will pass IC check :thumbup: Spitfire, C101, Gazelle ,Mirage, Yak have not been added as i do not currently own them. Place these files in DCSW/Config/View and overwrite. Always make a backup first!. Reference Server.lua, CameraViewAngleLimits for min/max fov. SnapViewsDefault.lua Index [13] for initial Fov. If anyone is willing to provide the /entry/views file for those aircraft listed above, I will gladly add them to the file and upload them here. Please be aware that ED has a rather harsh max limit of 140. This can be verified with status window Rctrl+pausex2. Hope this helps. FOV.rar
  23. Ah, just a random blemish of sorts then. Thanks for the support guys, well met. Those new textures look outstanding by the way!
  24. Hi guys. This one has been around for a while. If the fuel pump switch is enabled/disabled in a short enough time, the sound effects will loop continuously slightly out of phase timing with each other. Is this correct behaviour?
  25. Hi guys, I've noticed a rather nasty issue with the Movenpick hotel. Grid 40R CN 09886 70805 As soon as the window frame texture is drawn (LOD) the FPS may drop by 50% or more. CPU usage spikes, GPU usage drops. Moving the camera one step away (LOD) so that the window frame texture phases out, the FPS/CPU usage returns to normal. Texture and Preload settings were set to lowest to keep Vram in check however this issue remained. If i use Alt-Enter a few times, this problem goes away and "comes good" but not always. It should be worth noting that this issue only seems to occur with my Win10 boot. I havn't been able to trigger the issue with Win7 regardless of how hard i push the system. Win10/7 I7 950 Gtx 980 4gb 18gb Ram
×
×
  • Create New...