-
Posts
17 -
Joined
-
Last visited
About Shimakaze514
- Currently Viewing Topic: Unit:getCategory() return Object.Category?
- Birthday 03/02/1873
Personal Information
-
Flight Simulators
DCS MSFS2020 P3Dv5
-
Location
Osaka
-
Interests
DEBUGGING
Recent Profile Visitors
308 profile views
-
After reading everyone's comments, I think some details about the game freezing need to be re-clarified: 1. The freezing occurs anywhere the DCS menu is open, which can be the main screen, the online menu, or the settings page. 2. When you cut out the DCS window, for example, hang DCS in the background and start browsing Chrome, or even browsing your own desktop, the PC freezing caused by DCS will still make your entire computer unresponsive, and the mouse and keyboard are unavailable. If you are willing to look at the windows minidump after the crash, you will find that this is caused by DCS's very poor USB driver handling. The PC freezing is neither due to the RAM size and pagefile size mentioned by @sleighzy, nor the tacview plug-in mentioned by @MAXsenna, but the DCS code that reads the USB driver has a serious problem, causing the polling to enter an infinite loop. After freezing for dozens of minutes, Windows detected that the IRP response timed out and decided to restart automatically. DCS's scheduling problem with USB drivers seems to have become serious after the April version update. Although there were some suggestions like "lowering your G502 mouse polling rate can increase the DCS frame rate" (https://www.youtube.com/watch?v=RrqZnFzPMps), I didn't take it seriously for a long time. Until the April version update, both of my computers (Windows 10 and 11) had device-related problems. On the Windows 10 computer, when entering the cockpit to play, a track IR device plugged prompt will pop up every two or three seconds (I don't have any track IR), and then the game screen will freeze for half a second, then the device will unplugged, and freeze for another half a second. I temporarily solved this problem by disabling hot plugging. However, the problem on the Windows 11 computer is more serious and cannot be solved by disabling hot plugging. At first I didn't think the DCS issues on these two computers had anything to do with the youtube video, until a few days ago when the computer automatically restarted due to DCS freezing (I found that if you leave DCS alone after freezing, it will always restart automatically) and caused Windows to create the minidump file, I realized that this might be a serious, long-standing DCS code problem with the USB driver. It's funny that the mouse polling rate affects the game frame rate, but now there are problems with trackir spawning from the void, or directly locking the USB driver to cause the PC to freeze. Considering the situation of this post, it is obvious that I am not the only one who has encountered this problem. What can we do? At present, it seems that we can only wait for Eagle Dynamics @BIGNEWY to notice this problem and pay enough attention to it, or wait for the subsequent DCS updates to make this problem worse. I am not completely ignorant of computers. On the contrary, I have spent a lot of time and energy using various tools to find the cause of this freezing problem, eliminate various interferences, and finally have a considerable degree of confidence that the problem is indeed caused by DCS's improper scheduling of USB drivers. Please do not post messages like "You don't have enough RAM", "Your PC is a low-end device", "You have too many plugins installed", "DCS log files can reveal problems" in this thread, unless you have also done relevant research and can use a unified theory to explain the three situations I mentioned above (mouse polling rate, spawn track ir and main menu freeze). RAM size has nothing to do with USB drives. No matter how good a PC is, it cannot jump out of the infinite loop code. DCS log does not produce any useful information as far as I can see. Those who clamored to see the DCS log did not propose any effective solutions for these logs after we posted them. We will give those suggestions that are easy to say but costly to do, such as "reinstall your DCS", "reinstall your system", "change a computer", "upgrade your RAM", "reinstall the chipset driver", "reinstall the graphics card driver". It's easy to say, but for everyone who encounters the DCS freeze problem and is at a loss, these solutions have no clear direction, do not reveal the cause of the freeze, and are costly. I hope everyone can scientifically and rigorously explore the cause instead of making such "suggestions" irresponsibly.
-
Just encountered another freeze and auto restart, third time opening DCS after the update and third time freeze auto restart now. Here's the log, but I think it is useless: dcs.log
-
After the 2.9.15 update, the freezing problem is more serious. Before, there was only a chance of freezing on the main menu page, and if you continued to operate quickly, you could still enter the multiplayer server and play. Now there is a high probability of continuous freezing on the main menu page, and even if you click directly into the multiplayer page, it will freeze when refreshing the server. I just encountered a freeze on the multiplayer page, which lasted for dozens of minutes, and then the computer automatically restarted with a black screen. This is the first time that the computer cannot automatically recover from a freeze. I checked the event log, maybe this will help. It says DCS raised an error called "Top level window is idle". Thanks to this automatic reboot, it generated a minidump file, after I analyzed it using windbg, it showed that the driver UsbHub3.sys caused the computer to crash, I think this may be the reason. I will try to fix it now and post the fix method later ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_POWER_STATE_FAILURE (9f) A driver has failed to complete a power IRP within a specific time. Arguments: Arg1: 0000000000000003, A device object has been blocking an IRP for too long a time Arg2: ffffc704420b8c40, Physical Device Object of the stack Arg3: ffffd88d2ec9f738, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack Arg4: ffffc7044a081810, The blocked IRP Debugging Details: ------------------ Implicit thread is now ffffc704`356cc040 *** WARNING: Check Image - Checksum mismatch - Dump: 0x20b7be, File: 0x20b850 - C:\ProgramData\Dbg\sym\BTHport.sys\7A9A74EE202000\BTHport.sys KEY_VALUES_STRING: 1 Key : Analysis.CPU.mSec Value: 1203 Key : Analysis.Elapsed.mSec Value: 55878 Key : Analysis.IO.Other.Mb Value: 15 Key : Analysis.IO.Read.Mb Value: 1 Key : Analysis.IO.Write.Mb Value: 47 Key : Analysis.Init.CPU.mSec Value: 281 Key : Analysis.Init.Elapsed.mSec Value: 62131 Key : Analysis.Memory.CommitPeak.Mb Value: 181 Key : Analysis.Version.DbgEng Value: 10.0.27793.1000 Key : Analysis.Version.Description Value: 10.2410.02.02 amd64fre Key : Analysis.Version.Ext Value: 1.2410.2.2 Key : Bugcheck.Code.LegacyAPI Value: 0x9f Key : Bugcheck.Code.TargetModel Value: 0x9f Key : Dump.Attributes.AsUlong Value: 0x1808 Key : Dump.Attributes.DiagDataWrittenToHeader Value: 1 Key : Dump.Attributes.ErrorCode Value: 0x0 Key : Dump.Attributes.KernelGeneratedTriageDump Value: 1 Key : Dump.Attributes.LastLine Value: Dump completed successfully. Key : Dump.Attributes.ProgressPercentage Value: 0 Key : Failure.Bucket Value: 0x9F_3_UsbHub3!HUBPDO_EvtDeviceD0Exit Key : Failure.Hash Value: {00e27064-02f5-d601-a099-ac4f455b9037} Key : Hypervisor.Enlightenments.ValueHex Value: 0x1417df84 Key : Hypervisor.Flags.AnyHypervisorPresent Value: 1 Key : Hypervisor.Flags.ApicEnlightened Value: 0 Key : Hypervisor.Flags.ApicVirtualizationAvailable Value: 1 Key : Hypervisor.Flags.AsyncMemoryHint Value: 0 Key : Hypervisor.Flags.CoreSchedulerRequested Value: 0 Key : Hypervisor.Flags.CpuManager Value: 1 Key : Hypervisor.Flags.DeprecateAutoEoi Value: 1 Key : Hypervisor.Flags.DynamicCpuDisabled Value: 1 Key : Hypervisor.Flags.Epf Value: 0 Key : Hypervisor.Flags.ExtendedProcessorMasks Value: 1 Key : Hypervisor.Flags.HardwareMbecAvailable Value: 1 Key : Hypervisor.Flags.MaxBankNumber Value: 0 Key : Hypervisor.Flags.MemoryZeroingControl Value: 0 Key : Hypervisor.Flags.NoExtendedRangeFlush Value: 0 Key : Hypervisor.Flags.NoNonArchCoreSharing Value: 1 Key : Hypervisor.Flags.Phase0InitDone Value: 1 Key : Hypervisor.Flags.PowerSchedulerQos Value: 0 Key : Hypervisor.Flags.RootScheduler Value: 0 Key : Hypervisor.Flags.SynicAvailable Value: 1 Key : Hypervisor.Flags.UseQpcBias Value: 0 Key : Hypervisor.Flags.Value Value: 21631230 Key : Hypervisor.Flags.ValueHex Value: 0x14a10fe Key : Hypervisor.Flags.VpAssistPage Value: 1 Key : Hypervisor.Flags.VsmAvailable Value: 1 Key : Hypervisor.RootFlags.AccessStats Value: 1 Key : Hypervisor.RootFlags.CrashdumpEnlightened Value: 1 Key : Hypervisor.RootFlags.CreateVirtualProcessor Value: 1 Key : Hypervisor.RootFlags.DisableHyperthreading Value: 0 Key : Hypervisor.RootFlags.HostTimelineSync Value: 1 Key : Hypervisor.RootFlags.HypervisorDebuggingEnabled Value: 0 Key : Hypervisor.RootFlags.IsHyperV Value: 1 Key : Hypervisor.RootFlags.LivedumpEnlightened Value: 1 Key : Hypervisor.RootFlags.MapDeviceInterrupt Value: 1 Key : Hypervisor.RootFlags.MceEnlightened Value: 1 Key : Hypervisor.RootFlags.Nested Value: 0 Key : Hypervisor.RootFlags.StartLogicalProcessor Value: 1 Key : Hypervisor.RootFlags.Value Value: 1015 Key : Hypervisor.RootFlags.ValueHex Value: 0x3f7 BUGCHECK_CODE: 9f BUGCHECK_P1: 3 BUGCHECK_P2: ffffc704420b8c40 BUGCHECK_P3: ffffd88d2ec9f738 BUGCHECK_P4: ffffc7044a081810 FILE_IN_CAB: 041825-11859-01.dmp DUMP_FILE_ATTRIBUTES: 0x1808 Kernel Generated Triage Dump FAULTING_THREAD: ffffc704356cc040 DRVPOWERSTATE_SUBCODE: 3 BLACKBOXBSD: 1 (!blackboxbsd) BLACKBOXNTFS: 1 (!blackboxntfs) BLACKBOXPNP: 1 (!blackboxpnp) BLACKBOXWINLOGON: 1 CUSTOMER_CRASH_COUNT: 1 PROCESS_NAME: System STACK_TEXT: ffffd88d`2ea16640 fffff805`3544883d : 00000000`00000000 00000000`00000000 ffffa300`14d91180 ffffa300`14d91180 : nt!KiSwapContext+0x76 ffffd88d`2ea16780 fffff805`354b881f : 00000000`00000000 00000000`00000000 00000000`00000000 ffffc704`356cc040 : nt!KiProcessDeferredReadyList+0x29d ffffd88d`2ea16af0 fffff805`354b67ac : ffffa300`00000000 00000000`00000000 ffffa300`14d91180 fffff805`354ce347 : nt!KeSetSystemGroupAffinityThread+0xff ffffd88d`2ea16b60 fffff805`354fdd5b : 00000000`00000104 ffffd88d`00000000 00000000`00000000 00000000`00000104 : nt!KeGenericProcessorCallback+0x114 ffffd88d`2ea16d30 fffff805`3a7d47ae : ffffc704`420e58f0 00000000`00000000 ffffc704`420e5a40 00000000`00000000 : nt!KeFlushQueuedDpcs+0x10b ffffd88d`2ea16fb0 fffff805`3a7c577e : ffffc704`46c3b001 00000000`00000500 ffffd88d`2ea170b9 00000000`00000000 : Wdf01000!FxTimer::Stop+0xf022 [minkernel\wdf\framework\shared\core\fxtimer.cpp @ 757] ffffd88d`2ea17010 fffff805`64809f12 : ffffc704`420e58f0 ffffd88d`2ea170b9 00000000`00000003 ffffffff`dc3cba00 : Wdf01000!imp_WdfTimerStop+0x3e [minkernel\wdf\framework\shared\core\fxtimerapi.cpp @ 294] ffffd88d`2ea17040 fffff805`3a82cc73 : ffffd88d`2ea17460 ffffc704`47137d98 ffffc704`46cd2060 ffffc704`47137820 : UsbHub3!HUBPDO_EvtDeviceD0Exit+0x352 ffffd88d`2ea17120 fffff805`3a7cff2a : ffffc704`47137d98 00000000`00000004 ffffc704`47137a00 00000000`00000300 : Wdf01000!FxPnpDeviceD0Exit::InvokeClient+0x23 [minkernel\wdf\framework\shared\irphandlers\pnp\pnpcallbacks.cpp @ 285] ffffd88d`2ea17180 fffff805`3a82ef6c : 00000000`00000000 00000000`00000003 00000000`00000003 ffffc704`47137820 : Wdf01000!FxPrePostCallback::InvokeStateless+0x32 [minkernel\wdf\framework\shared\irphandlers\pnp\cxpnppowercallbacks.cpp @ 408] ffffd88d`2ea171b0 fffff805`3a82edab : ffffc704`47137820 ffffd88d`2ea17350 fffff805`3a84dd60 ffffd88d`2ea17460 : Wdf01000!FxPkgPnp::PowerGotoDxIoStoppedCommon+0x178 [minkernel\wdf\framework\shared\irphandlers\pnp\powerstatemachine.cpp @ 3100] ffffd88d`2ea17220 fffff805`3a82e9c0 : ffffc704`47137820 ffffd88d`2ea17350 00000000`00000420 00000000`00000000 : Wdf01000!FxPkgPnp::PowerGotoDxIoStoppedArmedForWake+0xb [minkernel\wdf\framework\shared\irphandlers\pnp\powerstatemachine.cpp @ 3195] ffffd88d`2ea17250 fffff805`3a82f997 : 00000000`00000000 ffffc704`47137a00 00000000`00001000 00000000`00000420 : Wdf01000!FxPkgPnp::PowerEnterNewState+0x194 [minkernel\wdf\framework\shared\irphandlers\pnp\powerstatemachine.cpp @ 1699] ffffd88d`2ea17390 fffff805`3a82f7c4 : ffffc704`47137820 00000000`00000000 ffffd88d`2ea17500 ffffa300`14d91180 : Wdf01000!FxPkgPnp::PowerProcessEventInner+0x177 [minkernel\wdf\framework\shared\irphandlers\pnp\powerstatemachine.cpp @ 1613] ffffd88d`2ea17410 fffff805`3a840499 : 00000000`00000000 00000000`00000001 ffffd88d`2ea17580 ffffd88d`2ea17590 : Wdf01000!FxPkgPnp::PowerProcessEvent+0x1c0 [minkernel\wdf\framework\shared\irphandlers\pnp\powerstatemachine.cpp @ 1394] ffffd88d`2ea174a0 fffff805`3a8409d1 : ffffc704`47137820 ffffc704`46cd21d0 00000000`00000004 00000000`00000000 : Wdf01000!FxPkgPdo::DispatchDeviceSetPower+0xe5 [minkernel\wdf\framework\shared\irphandlers\pnp\pdopower.cpp @ 216] ffffd88d`2ea174f0 fffff805`3a7c7a94 : ffffc704`47137820 ffffc704`46cd21d0 00000000`00000000 00000000`00000000 : Wdf01000!FxPkgPdo::_DispatchSetPower+0x21 [minkernel\wdf\framework\shared\irphandlers\pnp\pdopower.cpp @ 91] ffffd88d`2ea17520 fffff805`3a7fe02e : ffffc704`4a081810 ffffc704`4a081810 ffffc704`46cd2060 ffffc704`4a081c88 : Wdf01000!FxPkgPnp::Dispatch+0xd4 [minkernel\wdf\framework\shared\irphandlers\pnp\fxpkgpnp.cpp @ 771] ffffd88d`2ea17590 fffff805`3a7fdf75 : ffffc704`4a081810 ffffc704`46cd21d0 ffffc704`46cd2060 00000000`00000000 : Wdf01000!DispatchWorker+0x9a [minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1590] ffffd88d`2ea175c0 fffff805`3a7f455f : ffffc704`41fb69a0 ffffc704`46c3b0d0 ffffc704`4a081810 00000000`00000000 : Wdf01000!FxDevice::DispatchPreprocessedIrp+0xa1 [minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1652] ffffd88d`2ea17600 fffff805`64807d75 : ffffc704`46cd2060 ffffc704`4a081810 000038fb`b932df98 fffff805`35646f06 : Wdf01000!imp_WdfDeviceWdmDispatchPreprocessedIrp+0xef [minkernel\wdf\framework\shared\core\km\fxdeviceapikm.cpp @ 258] ffffd88d`2ea17640 fffff805`3a7fe7b8 : ffffc704`4a081810 00000000`00000016 00000000`00000001 ffffc704`46cd2060 : UsbHub3!HUBPDO_EvtDeviceWdmIrpPnPPowerPreprocess+0x435 ffffd88d`2ea17690 fffff805`3a7cb964 : ffffc704`4a081810 ffffc704`46cf5860 00000000`00000001 00000000`00000000 : Wdf01000!PreprocessIrp+0x58 [minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1519] ffffd88d`2ea176c0 fffff805`35525ba7 : ffffc704`4a081810 00000000`00000000 00000000`00000000 ffffc704`4a081cd0 : Wdf01000!FxDevice::DispatchWithLock+0x3ea4 [minkernel\wdf\framework\shared\core\fxdevice.cpp @ 1445] ffffd88d`2ea17710 fffff805`3541e30d : ffffc704`47624e10 fffff805`00000000 00000000`00000000 00000000`00000000 : nt!IopPoHandleIrp+0x3b ffffd88d`2ea17740 fffff805`3556b029 : ffffc704`504799e0 ffffc704`58c735a0 00000000`00000000 fffff805`35e3d0f0 : nt!IofCallDriver+0x6d ffffd88d`2ea17780 fffff805`3a9d9728 : ffffc704`356c08b0 ffffc704`6623cb30 ffffc704`58c73580 ffffc704`4a065820 : nt!PoCallDriver+0x9 ffffd88d`2ea177b0 fffff805`3a9b749a : ffffc704`47624e10 fffff805`35525c70 ffffc704`356c08b0 fffff805`6493a008 : ACPI!ACPIFilterIrpSetPower+0x338 ffffd88d`2ea17810 fffff805`35525ba7 : 00000000`00000007 ffffc704`4a081810 ffffc704`58c73580 00000000`00000000 : ACPI!ACPIDispatchIrp+0x648a ffffd88d`2ea17890 fffff805`3541e30d : ffff655a`6b654fdf fffff805`00000000 00000000`00000000 fffff805`64933ba8 : nt!IopPoHandleIrp+0x3b ffffd88d`2ea178c0 fffff805`3556b029 : fffff805`6493a008 fffff805`64914f8e 00000000`00000016 00000000`00000002 : nt!IofCallDriver+0x6d ffffd88d`2ea17900 fffff805`8cbb28db : ffffc704`4a081810 ffffc704`58c73580 ffffc704`58c73430 00000000`00000000 : nt!PoCallDriver+0x9 ffffd88d`2ea17930 fffff805`6491445f : ffffc704`58c735a0 ffffc704`58c73430 00000000`80000000 ffffc704`4a081810 : hidusb!HumPower+0xab ffffd88d`2ea17970 fffff805`64912007 : ffffc704`58c73580 00000000`00000016 fffff805`6493a008 fffff805`35526018 : HIDCLASS!HidpFdoPower+0x42f ffffd88d`2ea179f0 fffff805`355259ea : ffffa300`14da0000 ffffc704`356cc040 ffffd88d`2ea17b00 fffff805`00000000 : HIDCLASS!HidpMajorHandler+0x227 ffffd88d`2ea17a80 fffff805`354ded97 : ffffc704`356cc040 00000000`00000000 fffff805`35525790 00000000`00000000 : nt!PopIrpWorker+0x25a ffffd88d`2ea17b30 fffff805`35619a24 : ffffa300`14d91180 ffffc704`356cc040 fffff805`354ded40 00000000`00000000 : nt!PspSystemThreadStartup+0x57 ffffd88d`2ea17b80 00000000`00000000 : ffffd88d`2ea18000 ffffd88d`2ea11000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34 SYMBOL_NAME: UsbHub3!HUBPDO_EvtDeviceD0Exit+352 MODULE_NAME: UsbHub3 IMAGE_NAME: UsbHub3.sys IMAGE_VERSION: 10.0.22621.5192 STACK_COMMAND: .process /r /p 0xffffc70435764040; .thread 0xffffc704356cc040 ; kb BUCKET_ID_FUNC_OFFSET: 352 FAILURE_BUCKET_ID: 0x9F_3_UsbHub3!HUBPDO_EvtDeviceD0Exit OSPLATFORM_TYPE: x64 OSNAME: Windows 10 FAILURE_ID_HASH: {00e27064-02f5-d601-a099-ac4f455b9037} Followup: MachineOwner ---------
-
Thanks for the info, it is kind of a relief to see I'm not alone in having this annoying freezing issue. I have installed Process Lasso and Park Control, but random freeze still occurs after I set the core affinity of DCS to 0-15 in Process Lasso and disable core parking in Park Control. I don't have DCS running in administrator mode, it is launched via the default shortcut created on the desktop at installation. However, I did find 2 CPU cores with a 100% usage rate when I'm running DCS, and I have now disabled them. Sadly, right after a few minutes, I encountered another freeze.
-
When DCS is off, my PC never freezes. It is running smoothly with other games such as WarThunder, World of Warships, Microsoft Flight Simulator 2020, and Squad. All of those games are as or more CPU consuming as/than DCS, so I don't think it is a hardware issue of my PC. My PC spec (Lenovo Legion Y7000p 2024 Laptop): Operating System: Windows 11 (Build 22631.5189) CPU: Intel i7-14700HX GPU: Nvidia RTX 4070 Laptop RAM: 16GB Repaird DCS, still randomly freezes
-
The timing of the freeze seems completely random, it could be triggered at the main menu, during the server fresh and after the server refresh is completed. The duration of the freeze is not fixed, from seconds to minutes. I can't do anything with DCS opened in the background, it will freeze my PC randomly. Even when I was typing here, my PC was frozen 4 times, each lasted about 2 minutes. Here is a video recording the situation: QQ视频20250414170409.mp4
-
When I enter the main game interface, select the Multiplayer tab, and let it refresh itself, DCS freezes the entire system several times. It seems that it always freezes for tens of seconds when a new server is refreshed and the UI is updated. When all servers are refreshed and the refresh arrow on the top stops spinning, it will freeze for several minutes. When it freezes, I can't move the mouse, can't switch windows, and the monitor screen is frozen. I first encountered this problem a few days ago and tried reinstalling DCS, reinstalling the graphics driver, doing a windows update, and reinstalling the motherboard and CPU firmware, but none of them improved it. I used Process Monitor to observe and analyze and saw the CPU usage during the frozen time is 435%
-
A few updates ago(after some version in 2.8.x) , AGM-65 lost its ability of tracking fast-moving targets such as helicopters, while functioning as intended when tracking the slow ones. The Mavs can definately see the target, completely able to track it(target is within the seeker FoV and G limit) , having enough energy to hit, but it just 'refuses' to track it. That disabled the ability of fixed-wing aircraft to attack helicopters using any Mavericks. I have tested out all variant, including TV, IR, and laser guided. It seemed that the problem is at the weapon scheme: I've checked "DCS World OpenBeta\CoreMods\aircraft\AircraftWeaponPack\agm65_family.lua", found that max G of the missile is 16, the seeker Fi shows he can track targets 180° in the front hemisphere, and the 'Omviz' value is 99.9, which indicates a very big LOS velocity, in conclusion, it seemed that Mav's lua file won't stop it to track a fast-moving target. So I doubt it's the scheme, all Mavs share 2 schemes, agm65 or agm65e, now both of them are 'brocken' in some ways. If anyone wants to test it out, try shooting at a heli moving at ~100knots. It would be more obvious if you can ask a friend flying a heli and start accelerating from hover as you fired a maverick at him. At first I thought only the IR and TV seekers are broken. Recently I checked the Laser seeker, it turns out to be no joy either. The Maverick is flying like it lost any purpose, when the heli increase it's speed above threshold, the Mav won't control its rudders and allowing itself to fall.
-
Temporary fix: Edit this file in line 46, change HUD_only_back.material = MakeMaterial("",{0,0,0,255}) into HUD_only_back.material = MakeMaterial("",{0,0,0,0}) so that the background material will be transparent special reminder: uncomment line 51 will not cause any visible change.null edited file and preview screenshot are attached below IC unfriendly With regard to that players have different preferences on MFD background (some thought transparent background caused readability of MFD content to reduce, others thougt black background will block cockpit vision), instead of limit the option with IC, it might be a good idea to make a option under "settings - special - <aircraft>" that allow player to choose whether they want a transparent MFD background or not.MPD_common_bake_page.luanull
-
Temporary fix: Edit this file in line 46, change HUD_only_back.material = MakeMaterial("",{0,0,0,255}) into HUD_only_back.material = MakeMaterial("",{0,0,0,0}) so that the background material will be transparent special reminder: uncomment line 51 will not cause any visible change.null edited file and preview screenshot are attached below IC unfriendly With regard to that players have different preferences on MFD background (some thought transparent background caused readability of MFD content to reduce, others thougt black background will block cockpit vision), instead of limit the option with IC, it might be a good idea to make a option under "settings - special - <aircraft>" that allow player to choose whether they want a transparent MFD background or not. MPD_common_bake_page - edited.lua
-
MFD export effect before 2.8.3.37854.1 Open Beta update: After the update: My MonitorSetup: _ = function(p) return p; end; name = _('3440MFD+'); Description = '3440*1440' Viewports = { Center = { x = 0; y = 0; width = screen.width; height = screen.height; viewDx = 0; viewDy = 0; aspect = screen.aspect; } } LEFT_MFCD = { x = 790; y = 410; width = 620; height = 620; } RIGHT_MFCD = { x = 2030; y = 410; width = 620; height = 620; } --[[ CENTER_MFCD = { x = 1565; y = 100; width = 310; height = 310; } ]] JF17_LEFT_MFCD = { x = 350; y = 0; width = 620; height = 930; } JF17_CENTER_MFCD = { x = 2820; y = 0; width = 620; height = 930; } F14_TID = { x = 2030; y = 410; width = 620; height = 620; } GU_MAIN_VIEWPORT = Viewports.Center Previously I can see thru the MFDs on my screen and get a very clean view on the outside while don't have to lower my head and zoom in to see the MFDs, this can be a great help to enjoy flying and operating avionics at the same time, since you can choose a position you like to place the MFDs and read the information on them more confortably. Its for the same reason that some people buy a external screen and export MFD on it. building a monitor setup on the screen is just like building a cabin with many external screen at home, the only difference is one is virual and cheaper, the other is solid and obviously more costy. This should not be canceled just because of "simulation", it's player's freedom to display their MFDs wherever they like without obstucting the main view.
-
MFD export effect before 2.8.3.37854.1 Open Beta update: After the update: My MonitorSetup: _ = function(p) return p; end; name = _('3440MFD+'); Description = '3440*1440' Viewports = { Center = { x = 0; y = 0; width = screen.width; height = screen.height; viewDx = 0; viewDy = 0; aspect = screen.aspect; } } LEFT_MFCD = { x = 790; y = 410; width = 620; height = 620; } RIGHT_MFCD = { x = 2030; y = 410; width = 620; height = 620; } --[[ CENTER_MFCD = { x = 1565; y = 100; width = 310; height = 310; } ]] JF17_LEFT_MFCD = { x = 350; y = 0; width = 620; height = 930; } JF17_CENTER_MFCD = { x = 2820; y = 0; width = 620; height = 930; } F14_TID = { x = 2030; y = 410; width = 620; height = 620; } GU_MAIN_VIEWPORT = Viewports.Center Previously I can see thru the MFDs on my screen and get a very clean view on the outside while don't have to lower my head and zoom in to see the MFDs, this can be a great help to enjoy flying and operating avionics at the same time, since you can choose a position you like to place the MFDs and read the information on them more confortably. Its for the same reason that some people buy a external screen and export MFD on it. building a monitor setup on the screen is just like building a cabin with many external screen at home, the only difference is one is virual and cheaper, the other is solid and obviously more costy. This should not be canceled just because of "simulation", it's player's freedom to display their MFDs wherever they like without obstucting the main view.