FusRoPotato

I'll have to try it as well. On the 25T, the detector pod sees the emitters just fine, but the missile just won't lock and fire on anything.

I'm noticing all the sudden with the last hotfix that Kh-25MPU's and MP's can no longer lock on to active radar beams. Just been testing them on active SA-6 and Chilkas. I had been using them due to a new bug with the MT update that caused Kh-58's to loft downwards. It appears the Su-25T no longer has any form of usable anti-radiation weaponry. I post this here because I suspect it might be related to the RWR system and IR beam failures.

I'd like you guys to explain something to me. It was first known that the F-16 in this game, for whatever reason, could never perform a knife edge. It was as if it had less than half its expected body lifting force due to sideslip. Ok, so then I suppose it would make sense that the rudder authority would have to be fictionally enhanced a lot as to not appear anemic in yaw. But wait, this creates a problem. At high speeds and low altitudes, this can create an oscillation because the gains for yaw were calibrated to realistic rudder forces. A problem we had that suddenly went away one patch, but how? However, when it went away, the aircraft was still not able to perform knife edges. So now I come around and find this in one of the FM files. moment_of_inertia = { 12875.0, 85552.0, 75674.0, -1331.0},--Ix,Iy,Iz,Ixy -- Ix(roll) = 9496, Iy(pitch) = 55814, Iz(yaw) = 63100 [slug-ft2] --moment_of_inertia = { 4610.0, 48882.0, 52678.0, 0.0},--Ix,Iy,Iz,Ixy I found a copy of these numbers from a paper: A nonlinear dynamic inversion-based neurocontroller for unmanned combat aerial vehicles during aerial refuelling - Jimoh Pedro (PDF) A nonlinear dynamic inversion-based neurocontroller for unmanned combat aerial vehicles during aerial refuelling (researchgate.net) Which referenced these numbers sourced from: Morelli, E.A. (1998). Global nonlinear parametric modeling with application to F-16 aerodynamics, Technical report, Dynamics and Control Branch, NASA Langley Research Centre, Hampton, VA. https://zenodo.org/record/1262949/files/article.pdf Which does not actually contain these numbers or derivations of them. Does it mean they aren't legitimate numbers? Not necessarily, but an interesting bit of this is that Iz and Iy are swapped in value. I found another source of inertias from Morelli_Flight_Inertia_JGCD_Paper_final0921.pdf (nasa.gov) extracted from experimental data slug-ft2 kg-m2 Ixx-roll 9,496 12819 Iyy-pitch 55,814 75348 Izz-yaw 63,100 85185 Izz is always the highest but somehow pitch inertia in the file is highest. Is it possible the reason pitch seems so floppy is that it has its Inertia value swapped with yaw? Or is it possible there's a problem with filtering somewhere causing excessive delay of input? Perhaps with some programming, I could extract some comparative graphs through the export lua but I'm not 100% sure I have the skill for that. I just know this plane feels significantly less responsive compared to all the other aircraft we have and also struggles to change direction, like it's behind a 200 ms ping. Are the Inertias backwards? Are the control surfaces constrained to be slow? Are they stuck behind an aggressive filter? Have the gains been tampered with? White paper me bro

I'm going to warn you, I have replayed this track many times and it only crashes half the time. It's possible it's not fixed. Somehow this crash is a diceroll on a track replay. Hopefully that is a clue to someone.

Oh were you able to verify that? What did they find?

Update: 4 airstart attempts, no crash 2 ground hot attempts, no crash 2 cold attempts, 2 crash 1 hot attempt, no crash 2nd hot attempt trying to iteratively change switches around to isolate condition, all heater switches to the right of external lights on, ->crash with crash report and a track that lead to the crash this time, although replaying this track doesn't appear to cause a crash itself.dcs.20230321-053138.trk 2023-03-21 05:31:37.507 INFO EDCORE (Main): # -------------- 20230321-053138 -------------- 2023-03-21 05:31:37.508 INFO EDCORE (Main): DCS/2.8.3.37854 (x86_64; Windows NT 10.0.19044) 2023-03-21 05:31:37.509 INFO EDCORE (Main): d:\games\DCS World OpenBeta\bin\CockpitBase.dll 2023-03-21 05:31:37.510 INFO EDCORE (Main): # C0000005 ACCESS_VIOLATION at 00007ffdbae0b710 00:00000000 2023-03-21 05:31:37.511 INFO EDCORE (Main): SymInit: Symbol-SearchPath: 'd:\games\DCS World OpenBeta\bin;', symOptions: 532, UserName: 'jeram' 2023-03-21 05:31:37.512 INFO EDCORE (Main): OS-Version: 10.0.19044 () 0x300-0x1 2023-03-21 05:31:37.513 INFO EDCORE (Main): 0x00000000002eb710 (CockpitBase): cockpit::GunSight::updateFEDS + 0x250 2023-03-21 05:31:37.514 INFO EDCORE (Main): 0x00000000002e3b69 (CockpitBase): cockpit::GunWeaponCommon::release + 0x49 2023-03-21 05:31:37.515 INFO EDCORE (Main): 0x000000000011f0c6 (CockpitMi8): cockpit::Mi8::avWeaponSys_Mi8::releasePayload + 0x16 2023-03-21 05:31:37.516 INFO EDCORE (Main): 0x000000000011edee (CockpitMi8): cockpit::Mi8::avWeaponSys_Mi8::release + 0xFE 2023-03-21 05:31:37.516 INFO EDCORE (Main): 0x00000000001ce361 (CockpitBase): cockpit::binding_context + 0x141 2023-03-21 05:31:37.516 INFO EDCORE (Main): 0x00000000001d482d (CockpitBase): cockpit::ccCockpitContext::release + 0xFD 2023-03-21 05:31:37.516 INFO EDCORE (Main): 0x0000000000390c65 (CockpitBase): cockpit::c_draw_debug_cockpit_tripod + 0x6465 2023-03-21 05:31:37.516 INFO EDCORE (Main): 0x000000000052f07d (DCS): SW + 0x98BDD 2023-03-21 05:31:37.516 INFO EDCORE (Main): 0x00000000006ae817 (DCS): SW + 0x218377 2023-03-21 05:31:37.517 INFO EDCORE (Main): 0x000000000068e49b (DCS): SW + 0x1F7FFB 2023-03-21 05:31:37.517 INFO EDCORE (Main): 0x00000000005687de (DCS): SW + 0xD233E 2023-03-21 05:31:37.517 INFO EDCORE (Main): 0x000000000085b252 (DCS): SW + 0x3C4DB2 2023-03-21 05:31:37.517 INFO EDCORE (Main): 0x0000000000aa8358 (DCS): SW + 0x611EB8 2023-03-21 05:31:37.517 INFO EDCORE (Main): 0x0000000000acaea1 (DCS): SW + 0x634A01 2023-03-21 05:31:37.517 INFO EDCORE (Main): 0x0000000000ac913d (DCS): SW + 0x632C9D 2023-03-21 05:31:37.518 INFO EDCORE (Main): 0x00000000000798ce (edCore): Mail::Reader::stream + 0x158E 2023-03-21 05:31:37.518 INFO EDCORE (Main): 0x0000000000ab527b (DCS): SW + 0x61EDDB 2023-03-21 05:31:37.518 INFO EDCORE (Main): 0x0000000000ab5521 (DCS): SW + 0x61F081 2023-03-21 05:31:37.518 INFO EDCORE (Main): 0x0000000000ae6f5c (DCS): SW + 0x650ABC 2023-03-21 05:31:37.518 INFO EDCORE (Main): 0x0000000000acbaaa (DCS): SW + 0x63560A 2023-03-21 05:31:37.519 INFO EDCORE (Main): 0x00000000008948e0 (DCS): SW + 0x3FE440 2023-03-21 05:31:37.519 INFO EDCORE (Main): 0x0000000000852c04 (DCS): SW + 0x3BC764 2023-03-21 05:31:37.519 INFO EDCORE (Main): 0x0000000000853ae4 (DCS): SW + 0x3BD644 2023-03-21 05:31:37.519 INFO EDCORE (Main): 0x000000000235679e (DCS): AmdPowerXpressRequestHighPerformance + 0xFB179A 2023-03-21 05:31:37.519 INFO EDCORE (Main): 0x0000000000c51c92 (DCS): SW + 0x7BB7F2 2023-03-21 05:31:37.520 INFO EDCORE (Main): 0x0000000000017614 (KERNEL32): BaseThreadInitThunk + 0x14 I'm not sure if this is going to be the same crash though because this is the first time it asked me if I wanted to submit a report

Thanks, I threw in an air start and hot start just to test it but haven't had a CTD when dying with either of those yet. If I can figure out something consistent, I'll make a track file copying all my actions before death.

Well thanks for trying. There must be something particular about my server/mission that is causing some of us to crash, but only when dying in that specific helicopter. It has happened without other players present and I have been replicating this problem on the Marianas Map with a cold-start aircraft. I'd have to do a bunch of testing on Caucasus to see if I get away with it but unluckily, I am suddenly away and short on time. I will try to investigate Caucasus this weekend. There are super carriers, AI ground units, A2A units in combat, AWACS, boats moving around, and drones flying in the server. Often plenty of munitions craters and crashed vehicles littered about. If you'd like to check it out, it's a Marianas sever with Darkmatter in the name. It's possible there could be an issue with smoke effects, decals, or other possible impactors on ram or vram that may be contributing to the trigger, but I've had a few crashes on death while playing alone on a fresh map which suggests it doesn't take too much activity if activity is contains the trigger. Did you run with hot starts or already flying starts?

I didn't bother to test the laser guided rocket available on those pylons (because it doesn't have a loft feature), but the other 3 A2G missiles on those pylons all do the same thing, dive instead of loft. Makes it seem like it's not a problem with the missiles themselves, but rather either the pylons, or some generic loft function if that exists.

I haven't received a CTD in SinglePlayer yet, but I haven't done much testing there. Maybe only 3 deaths total in SP. I've crashed about 15 times in MultiPlayer from about 20 deaths. Rough guess without logs. Not all deaths and helicopter destructions resulted in a CTD, but I've been through as many deaths on several other modules without CTD so I assume there must be something special about the Mi-8. I don't know how to capture more information on the event, but if I did, I could probably replicate it again easily.

Title says it all. I've been crashing to desktop without message very consistently +80% of the time during death while inside an Mi-8 (and so has a friend of mine). Doesn't appear to matter what the initiator killer is. It can even be death by crashing into the ground. It will just send us to desktop without warning. This is after a slow repair, no custom files, in a multiplayer server, and happens in both MT and ST. These are the last lines of my log. No crash or track files are being created. 2023-03-20 05:12:46.910 WARNING EDGRPC (Main): GRPC channel is not opened! 2023-03-20 05:13:14.217 WARNING LOG (12912): 13 duplicate message(s) skipped. 2023-03-20 05:13:14.217 INFO ASYNCNET (Main): Current ping: 53.4ms 2023-03-20 05:13:15.074 WARNING EDGRPC (Main): GRPC channel is not opened! 2023-03-20 05:13:38.646 WARNING LOG (12912): 47 duplicate message(s) skipped. 2023-03-20 05:13:38.646 ERROR ED_SOUND (684): render time = 0.607814s exceeded allowed slice of 0.010000s

# C0000005 ACCESS_VIOLATION at 00007ffe29d6abef 00:00000000 Sounds like memory management issues. Considering a lot of people are getting these right now, it's probably a DCS problem.

I've been using ST due to no noticeable improvement with MT. Assumed I'd be safe from bugs, but crashing a lot with ST this patch.

please fix

Nice work Tim, I can appreciate a keen eye for flight model abnormalities. I've been getting into DCS lately flying some of these choppers and they all seem to have strange behaviors when it comes to torques, moments due to velocity (on all axis), stability, and vrs. When I go in and dig through some of their files, I often find what can only be described as a careless butchering of invented numbers. "FalseTailArea"??? Makes no sense to me. I just tried out this module and the Mi8 recently after going through the Ka-50 a few months back. At first I couldn't tell if the yaw moments were just off, weak, or what, but I did notice that all of these choppers have a very strong yaw stability that increases with speed, nearly nullifying most yaw input so long as there's just 10 or 20 m/s forward speed. Once they fix (if they fix) the power and tail issues you describe, I suspect you'll find it doesn't end there.

I realized I still had a mod called "The Way" installed and reshade. I removed them and did a slow repair including remove extra files just to make sure, but no change in behavior. ST or MT doesn't matter. Additional note, the passive radar guided weapons that can be loaded on pylons 3 and 9 are not affected and still appear to work normally.

DarkMatter_Marianas_SandboxPvE_Endless_alpha14-20230316-010237.trk This should probably be its own thread. I thought the previous one was the same issue but it appears to be several issues from too long ago. These missiles are lofting downwards since the latest update and are basically rendered useless unless launched from a dive to something almost directly below. Something changed them because they were working fine before the update. They just go down into the ground. Two of them are passive radar, the third is optical, but all 3 are behaving inverted. I checked the hardpoint for other things like fuel tanks and gun pods, but they are not mounted upsidedown or anything like that. The track file provided shows a 25T firing vikhrs at first to test smoke lag, but later gets into a new 25T within minutes to throw some 58's at an SA6.

Same thing happens if you look through exhaust trails in FLIR (looking backwards in the harrier). Something is wrong with some of the smoke effects in game. This was reported in previous versions.

This bug is suddenly back with the MT update, but doesn't matter if using MT or ST. DarkMatter_Marianas_SandboxPvE_Endless_alpha14-20230316-010237.trk Track contains a few test fires of vikhr first due to an FPS problem with its smoke, but after that, 3 or 4 58's are launched from a 25T and they launch downward into the ground.

It's happening with BS2 now though... I think it's all modules that offer a 2nd view. I think they extended the range of something at no benefit but huge cost.

I had been developing a multiplayer mission that depended on a handful of IR laser spots coming from drones. Since the update, some of us can't visually see them anymore, but some of us can. Still working through to see if there's any similarity in settings, drivers, or hardware but haven't found anything yet. Regardless, the IR lasers are now gone for some of us but not others, verified through basic discord streaming. I suspect this might be related to some of the other bugs where external view models, smoke effects, and ground objects are now disappearing or showing up through clouds. Like hitting F2 only to see a flying clump of bombs. I've tested the F16, M2000, and Ka-50 so far on Marianas. Tried various graphics settings and cleared fxo and metashaders, but haven't found a root cause yet. Shoot, almost forgot to mention the obvious. The problem only occurs with the MT exe, not the ST. They display correctly with the ST version.

I've validated this problem a few thousand times. Once it's out, never goes back in. It has always been like that.

If I say I attempted to recalibrate the uncalibrated rack and it continues fail calibration, then I don't know what else to say. I know about a half dozen others who have been having this issue so I'll hand you some of your own: You must not have actually interacted with Mavs once within the past few updates. It's become a common saying within our larger community that if you want to use mavs, fly the A10, as they've historically always had one major issue or another active on this aircraft. Were you aware of the issue in the prior patch? It was 100% failure to calibrate. Now it's an occasional repeat of the same issue. Don't believe me? Guess who doesn't care.

You made a lowball assumption after a low effort read of a comment for an easy dismissal, not a very nice way to start "helping". Maybe read carefully and give the benefit of doubt before expecting appreciation, or steer away from problem reports that you haven't experienced yourself.

This is what happens when you don't calibrate both your eyes. I mean, does this not suggest anything? Take the hint, I've been seeing these bugs after attempting to calibrate both racks. One of them usually fails and becomes far worse off than it would have been in its initially uncalibrated state. Considering how I've also been seeing a lot of bugs with the TGP not properly snapping to its waypoints, FCR targets, and VIS points, but rather on occasion ignore SOI POIs or get stuck floating wherever, I'd say the problem with the mavericks is probably caused by some issue with a bugged TGP or POI state. Switching from one pylon to another must somehow be triggering that corruption, but my guessing ends there. There was a time these calibrated just fine and probably should have been left alone.