acceleraptor

And @derammo - i'd bet 2000 users is conservative... Probably my favorite piece of flight sim sotware TBH.

+1 on Helios being completely broken- it's a huge part of my being able to easily manage MFDs in the A-10, F18, and F-16. BIGNEWY- this page should have a list of the files that Helios modifies for you to pass along to the developers: https://github.com/HeliosVirtualCockpit/Helios/tree/master/Patching/Patches/DCS This change was clearly not thought through... If mods are going to be whitelisted manually, how do we verify those? Does every unique release of mods have to be whitelisted? Are these then tied all of a sudden to DCS releases?

In the case where the wind 'to' direction is less than 180, windDir would indeed be negative. However, it is corrected directly after by adding 360 degrees if windDir is less than 0: if windDir < 0 then wing_direction:set(360+windDir) else wing_direction:set(windDir) end In retrospect it looks like there's a bit of a typo there... Slightly Off-topic aside/edit: looking at this bit of code, it seems like that the use of atan2 implies that the in-game X axis runs North/South and the in-game Y axis goes East/West, unless I'm reading something wrong. Interesting...

Awesome mod here! Have had ton a fun cruising around in the T-45! On tiny thing I noticed- wind direction on the HSI is in the direction the wind is going, not the direction the wind is coming from, which seems like what would be displayed on that screen. For a quick work around, I replaced line 141 in Cockpit/Scripts/Displays/DisplayElectronicsUnit.lua with this: local windDir = math.deg(math.atan2(WIND_Y:get(),WIND_X:get())) - 180 It works great after that edit

Based on what I've seen so far, this doesn't seem like it's the case. Seems like some kind of regression that is specific to virtualized environments on the DCS side.

Just to add to this, I'm having the issue, but not with Shadow PC. In my case it's a QEMU VM. The thread linked before has a stack trace/call stack from where I _think_ the issue was occuring. Might help the devs track things down Give that a try. It should be the metashaders2 and fxo directories in %USERPROFILE%\Saved Games\DCS that you delete. That will force a shader recompile.

Looking at your logs, it seems your install gets farther than mine does, so I doubt we have the same problem. Out of curiosity, have you deleted your metashaders and fxo folders from your DCS saved games directory? Edit: Well i'm dumb. Posted in the wrong thread. Feel free to delete this, mods

After doing some digging, it seems like kernel32.dll:FatalExit()is being called, which may be suppressing/bypassing DCS's normal error handing/crash reporting routines. Regardless, the execution appears to terminate without executing DCS's crash handler. The stack seems to be a bit corrupted at the time of the FatalExit call, but I was able to pull this call stack out: Address To From Siz Comment Party 00000035ED10EEC8 00007FF6DE6C40C4 00007FF6DE6B37D0 B0 return to dcs.sub_7FF6DE6C3FE0+E4 from dcs.00007FF6DE6B37D0 User 00000035ED10EF78 00007FFFC802F706 00007FF6DF762FBC 10 return to ucrtbase._malloc_base+36 from ??? System 00000035ED10EF88 00007FFFBC394D3E 00007FFFBC393DE0 20 return to lua.00007FFFBC394D3E from lua.00007FFFBC393DE0 User 00000035ED10EFA8 00007FFFBC38D188 00007FF6DE6C3ECF 40 return to lua.00007FFFBC38D188 from ??? User 00000035ED10EFE8 00007FF6DE6C3ECF 00007FF6DF762D8F 130 return to dcs.00007FF6DE6C3ECF from ??? User 00000035ED10F118 00007FFFC53EE4B3 00007FFFC53F0410 2D0 return to apphelp.SE_GetProcAddressForCaller+303 from apphelp.__security_check_cookie System 00000035ED10F3E8 00007FFFAB1F6CAC 00007FFFAB1F6B04 F0 return to vcruntime140.DName::DName+68 from vcruntime140.private: void __cdecl DName::doPchar<1>(char const * __ptr64,int) __ptr64 System 00000035ED10F4D8 00007FFFAB1F6AC6 00007FFFAB1FAA78 C0 return to vcruntime140.DName::append<pcharNode>+26 from vcruntime140.public: void * __ptr64 __cdecl _HeapManager::getMemoryWithBuffer(unsigned __int64) __ptr64 System 00000035ED10F598 00007FFFCA4C48EA 00007FFFCA4C0CF4 20 return to ntdll.RtlpFreeHeap+49A from ntdll.RtlpHeapAddListEntry System 00000035ED10F5B8 00007FFFAB1F8C8B 00007FFFAB1F9D44 20 return to vcruntime140.UnDecorator::getBasicDataType+3F3 from vcruntime140.private: static class DName __cdecl UnDecorator::getECSUDataType(void) System 00000035ED10F5D8 00007FFFCA4C786B 00007FFFCA4B3B3C C0 return to ntdll.RtlpLowFragHeapAllocFromContext+21B from ntdll.RtlpLfhFindClearBitAndSet System 00000035ED10F698 00007FFFCA4C6E2C 00007FFFCA4C7650 20 return to ntdll.RtlpAllocateHeapInternal+12C from ntdll.RtlpLowFragHeapAllocFromContext System 00000035ED10F6B8 00007FFFCA4C786B 00007FFFCA4B3B3C 50 return to ntdll.RtlpLowFragHeapAllocFromContext+21B from ntdll.RtlpLfhFindClearBitAndSet System 00000035ED10F708 00007FFFCA4C786B 00007FFFCA4B3B3C 80 return to ntdll.RtlpLowFragHeapAllocFromContext+21B from ntdll.RtlpLfhFindClearBitAndSet System 00000035ED10F788 00007FFFCA4C786B 00007FFFCA4B3B3C 1A0 return to ntdll.RtlpLowFragHeapAllocFromContext+21B from ntdll.RtlpLfhFindClearBitAndSet System 00000035ED10F928 00007FFFC803200E 30 return to ucrtbase.__crt_seh_guarded_call<int>::operator()<<lambda_638799b9deba96c50f710eeac98168cd>,<lambda_22ebabd17bc4fa466a2aca6d8deb888d> &,<lambda_a6f7d7db0129f75315ebf26d50c089f1> >+4E from ??? System 00000035ED10F958 00007FFFC8031FB0 00007FFFC8031FC0 F0 return to ucrtbase._register_onexit_function+A0 from ucrtbase.__crt_seh_guarded_call<int>::operator()<<lambda_638799b9deba96c50f710eeac98168cd>,<lambda_22ebabd17bc4fa466a2aca6d8deb888d> &,<lambda_a6f7d7db0129f75315ebf26d50c089f1> > System 00000035ED10FA48 00007FF6DE893C6E 00007FF6DE2ED750 40 return to dcs.00007FF6DE893C6E from dcs.00007FF6DE2ED750 User 00000035ED10FA88 00007FFFC8527034 30 return to kernel32.BaseThreadInitThunk+14 from ??? System 00000035ED10FAB8 00007FFFCA4FD0D1 return to ntdll.RtlUserThreadStart+21 from ??? System The first entry in the call stack corresponds to this snippet of the binary: 00007FF6DE6C4033 | E8 B8B0C2FF | call dcs.7FF6DE2EF0F0 | 00007FF6DE6C4038 | 45:33FF | xor r15d,r15d | 00007FF6DE6C403B | 48:8B05 76472400 | mov rax,qword ptr ds:[<&?globalWorldManager@@3PEAVWorldManager@@EA>] | 00007FF6DE6C4042 | 4C:3938 | cmp qword ptr ds:[rax],r15 | 00007FF6DE6C4045 | 75 38 | jne dcs.7FF6DE6C407F | 00007FF6DE6C4047 | B9 C8000000 | mov ecx,C8 | 00007FF6DE6C404C | E8 63F11C00 | call dcs.7FF6DE8931B4 | 00007FF6DE6C4051 | 48:8BD8 | mov rbx,rax | 00007FF6DE6C4054 | 48:8945 AF | mov qword ptr ss:[rbp-51],rax | 00007FF6DE6C4058 | 48:85C0 | test rax,rax | 00007FF6DE6C405B | 74 15 | je dcs.7FF6DE6C4072 | 00007FF6DE6C405D | 48:8BC8 | mov rcx,rax | 00007FF6DE6C4060 | FF15 3A492400 | call qword ptr ds:[<&??0WorldManager@@QEAA@XZ>] | 00007FF6DE6C4066 | 48:8D05 13B62C00 | lea rax,qword ptr ds:[7FF6DE98F680] | 00007FF6DE6C406D | 48:8903 | mov qword ptr ds:[rbx],rax | 00007FF6DE6C4070 | EB 03 | jmp dcs.7FF6DE6C4075 | 00007FF6DE6C4072 | 49:8BDF | mov rbx,r15 | 00007FF6DE6C4075 | 48:8B05 3C472400 | mov rax,qword ptr ds:[<&?globalWorldManager@@3PEAVWorldManager@@EA>] | 00007FF6DE6C407C | 48:8918 | mov qword ptr ds:[rax],rbx | 00007FF6DE6C407F | 48:8B05 CA212400 | mov rax,qword ptr ds:[<&?globalOptions@@3PEAVIOptions@@EA>] | 00007FF6DE6C4086 | 48:8338 00 | cmp qword ptr ds:[rax],0 | 00007FF6DE6C408A | 75 2D | jne dcs.7FF6DE6C40B9 | 00007FF6DE6C408C | B9 40010000 | mov ecx,140 | 00007FF6DE6C4091 | E8 1EF11C00 | call dcs.7FF6DE8931B4 | 00007FF6DE6C4096 | 48:8945 AF | mov qword ptr ss:[rbp-51],rax | 00007FF6DE6C409A | 48:85C0 | test rax,rax | 00007FF6DE6C409D | 74 0D | je dcs.7FF6DE6C40AC | 00007FF6DE6C409F | 48:8BC8 | mov rcx,rax | 00007FF6DE6C40A2 | E8 89B10600 | call dcs.7FF6DE72F230 | 00007FF6DE6C40A7 | 48:8BC8 | mov rcx,rax | 00007FF6DE6C40AA | EB 03 | jmp dcs.7FF6DE6C40AF | 00007FF6DE6C40AC | 49:8BCF | mov rcx,r15 | 00007FF6DE6C40AF | 48:8B05 9A212400 | mov rax,qword ptr ds:[<&?globalOptions@@3PEAVIOptions@@EA>] | 00007FF6DE6C40B6 | 48:8908 | mov qword ptr ds:[rax],rcx | 00007FF6DE6C40B9 | FF15 91312400 | call qword ptr ds:[<&?createGlobalLand@@YAXXZ>] | 00007FF6DE6C40BF | E8 0CF7FEFF | call dcs.7FF6DE6B37D0 | 00007FF6DE6C40C4 | E8 77ACD2FF | call dcs.7FF6DE3EED40 ( ****** FIRST CALL STACK ENTRY ****** ) | 00007FF6DE6C40C9 | 48:8B05 086F2400 | mov rax,qword ptr ds:[<&?globalConfig@@3PEAUlua_State@@EA>] | 00007FF6DE6C40D0 | 48:8B08 | mov rcx,qword ptr ds:[rax] | 00007FF6DE6C40D3 | 48:894C24 38 | mov qword ptr ss:[rsp+38],rcx | 00007FF6DE6C40D8 | E8 149C1A00 | call <JMP.&lua_gettop> | 00007FF6DE6C40DD | 8945 87 | mov dword ptr ss:[rbp-79],eax | 00007FF6DE6C40E0 | BA EED8FFFF | mov edx,FFFFD8EE | 00007FF6DE6C40E5 | 48:8B4C24 38 | mov rcx,qword ptr ss:[rsp+38] | 00007FF6DE6C40EA | E8 0E9C1A00 | call <JMP.&lua_pushvalue> | 00007FF6DE6C40EF | 90 | nop | 00007FF6DE6C40F0 | 48:83BE 20010000 00 | cmp qword ptr ds:[rsi+120],0 | 00007FF6DE6C40F8 | 75 5F | jne dcs.7FF6DE6C4159 | Let me know if there's any other info which might be useful! Interesting... I don't have a Shadow PC per say, but I do use DCS in in a QEMU VM...

Thanks for the follow up, but I think we've got a different problem. I think this fix is related to issues with authorization failing. Our installs don't even get to the point where they check authorization. I did try this, and it had no effect.

I'm affected by the same issue. I have an AMD 3950X, with a 2080Ti and Asus 570x prime motherboard. It fails with or without a fresh Saved Games folder, as well as before and after a repair or reinstall. I've tested both. Having talked to someone else with the issue I can add the following info: It affects both the steam and standalone versions It affects both Intel and AMD chips (the other person had a Xeon) There are no windows system logs placed other than a generic (and totally unhelpful) "Application Hang" event in event viewer. Having looked at a few other people's logs, it seems like the next step in the startup process normally would be to go ahead and initiate the steam authorization process, but that doesn't start. At a low level, I've been able to determine that immediately after the last log messsage ("Dispatcher: InitLow") a bunch of threads terminate, but the parent process stays running. I haven't been able to figure out how or why these threads are exiting, unfortunately. A TCP HTTPS connection to digitalcombatsimulator.com is initiated as part of the startup process, but it seems to be closed after the threads crash. One question- can I get DCS to make this connection through a proxy? If I could, I'd be able to provide _much_ more helpful info to help track this info down. I tried configuring windows to use a proxy but DCS seems to ignore that windows setting....

I think what Caput_58 is talking about is a little bit different... he's asking why point track fails when a target is visible to the CCD/IR sensor but the laser is mask, and I think he has a legitimate point here. If Point Track is indeed based on a contrast lock withiin the sensor (as you'd do with the laser off) then it makes no sense for point track to fail when the laser is masked but the sensor can still see the target. I suspect this has to do with how the a10 handles point track. Based on what I've seen, it snaps to a nearby DCS unit if the conditions are right, thus mimicking a true contrast lock.

As has been already documented in the forums, there currently is an issue where navigating the loadout editor menus will cause stutters in game. I've looked at the lua files and found a temporary workaround that solves the issue. It seems that whenever the menus are changed, the image previews for each weapon are reloaded from disk synchronously, which causes things to lag. As of the current open beta version, commenting out line 746 of Scripts\UI\MissionResourcesDialog.lua fixes the lag at the cost of having no weapon preview images in the menu. It should look more or less like this (the edited line is bold): if submenuItem then submenuItem.pylonNumber = pylonNumber submenuItem.launcher = launcher local filename, blendColor = loadoutUtils.getLauncherImage(launcher.clsid) [b] -- submenuItem:setSkin(SkinUtils.setMenuItemPicture(filename, blendColor or '0x000000ff'))[/b] submenu:insertItem(submenuItem) end

Try setting the TGP track mode on the HCMS section of the STATS MFCD page (right MFCD) to AREA. This means that when you press DMS Right Long it will drop to Area Track instead of Inertial Track.

So technically it’s adjustable... just pull on the rings above the seat and between your legs... :smilewink: As a bonus you get much improved ventilation too!!! :lol:

One viewpoint is for VR and the other is for 2D from what I can tell.

Regarding my last post- I think the gun boresight marker being blocked is just a matter of the hud clipping area not being big enough, not head position.

Another two things I've noted that are definitely issues with the current head orientation: The gun boresight circle (dotted circle with point in the middle) is clipped in the current HUD plane. Can't see it regardless of where my head is... Also, in its current state the default view blocks the CICU sctrachpad (ability to type numbers into the UFC). Without TrackIR and/or changing the position, there isn't a way to view what's currently in the scratchpad on the HUD because the HUD camera is blocking it.

Also why is this marked as fixed? I remember reading several posts earlier on in this thread indicating that everything was visible on the HUD from a normal head position. And yet, in the plugin's current state, to see the entire HUD, you have to be so far forward that your eyes are practically over the control stick. Just to give everyone an idea, here's where in the cockpit my eyes are, laterally, in game: This is nowhere close to the external model, which places the pilots head about 8-10 in aft of the current point in the cockpit.

I think this may be part of some kind of standardization to be more consistent. I have no issue with the changes, but I kind of wish they were communicated ahead of time.

I'd like to get some clarification on this as well. Also- is it indeed "expected" that the heading tape should be blocked in the default view configuration? Thanks, acceleraptor

Comparing Stable to the current Open Beta, I can see in Views.lua for the A-10C that the default head position has indeed been changed: Old: [13] = makeSnapView({xyz = {0.157, -0.008, 0.000},ypr = { 0.000, -19.000, 0.000},FOV = 75}),--default view [14] = makeSnapView({xyz = {0.2, -0.025, 0.000},ypr = { 0.000, -19.000, 0.000},FOV = 75}),--VR New: [13] = makeSnapView({xyz = {0.298, -0.041, 0.000},ypr = { 0.000, -19.000, 0.000},FOV = 73}),--default view [14] = makeSnapView({xyz = {0.298, -0.041, 0.000},ypr = { 0.000, -19.000, 0.000},FOV = 73}),--VR I don't know how the coordinate axes are laid out here... can anyone shed some light on this?

I can confirm that there has been a significant change in the last open beta. I use TrackIR, and if I set normal zoom and recenter my TrackIR, this is my sight picture: It appears that the head position is directly over the front edge of the seat cushion, about 2 inches aft of the stick... makes a TON of sense.... /s It seems like the HUD has been scaled up as well. If I move my head back to a sane position, using the "normal" zoom level, the HUD becomes all but unusable: Lastly, a bit of an aside: On top of the FOV issues, this is the second update I've seen in the past few months that has been released with significant (and arguably breaking) changes to the A-10C that were completely omitted from the changelog. In this update alone I've seen that a) a bunch of the switch positions and mouse bindings have changed (right/left click have been swapped) b) the warning siren is limited to the gear extension (a fix from the A-10c II iirc), and the seat position and hud has been changed, as we have been just discussing. I only found those within about 10 minutes of flying the warthog. I get that these aren't all bug fixes per say, but why don't these make it into the change log? It would definitely give us a better picture into what's happening in development...