Jump to content

EbonySeraphim

Members
  • Posts

    122
  • Joined

  • Last visited

2 Followers

About EbonySeraphim

  • Birthday 11/11/1985

Personal Information

  • Flight Simulators
    DCS World, Falcon BMS, Microsoft Flight 2020
  • Location
    Seattle, WA
  • Interests
    Game development, running, biking, movies, flight sims
  • Occupation
    Software Engineer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This was my issue. My binding was on a physical switch that held the button down the entire time, so I guess that also allowed the throttle position being zero to pull things back from idle in game despite the IDLE button not being pressed. I tested/verified last night but forgot to update until now.
  2. EDIT: @Ramsay what you said makes me wonder and want to test something. My finger lift bindings are non-momentary switches. Maybe I'm experiencing these problems because the finger lift binding for that engine is being held down the entire time. I'll try pressing and releasing and maybe I get different behavior. I was probably being misleading, and allow me to be a little nit picky -- it is during startup that I'm having problems. After raising the finger lifts, when I need push into IDLE the following happens with my CM3 setup: The throttle axes at rest in the STOP detent is holding down on the "STOP" DCS binding; DCS sees 0% (technically below) on the throttle axes I start moving the physical throttle into "IDLE", which will settle the DCS axes at 0 Along the way, the physical axes moves to a position that comes off of the STOP button binding and activates the IDLE button binding Along the way, the throttle axes DCS sees will register above throttle = 0 as I push past the detent (probably over 3% but I haven't checked) because of the shape of the detent The IDLE button binding will turn off BEFORE I've pushed past the detent When I'm fully past the detent and pull back fully on the throttle, DCS sees throttle = 0 again Given this setup, during startup when asked to push into IDLE, when I physically pull back on the CM3 throttle such that throttle = 0 again, in game it disables the IDLE setting and goes back into STOP. I can see this happening in the in-game cockpit. I don't know if there's scripting around the 3% such that because I'm pushing past it, and then dipping below it during start up, this is happening. I'll double check but I think this (engine shutdown) does not happen mid flight if I pick a free flight mission. Maybe these words aren't clear and I have to post a video. If not for my monitor/MFD setup making the controls indicator difficult to grab, I could trivially do this immediately. I'll give this a day or two for suggestions. Part of the understanding is seeing the physical action; I'm quite happy with how I have the CM3 setup for all modules, and what I'm doing seems extremely straight forward and should be reasonably expected and supported.
  3. I'm using a Vipril CM3 with a stop-idle detent that presses buttons as I move those axes up. Once I've moved past those "buttons", and full push down, that position is what DCS sees as "0" for the throttle axes in game. This setup works great for all fixed wing aircraft except the F-15E because (I suspect) of the special settings "Throttle cutoff detent" option. The lowest value I can set it is 3, and I cannot turn it off. I'm guessing this means that the module will see a throttle value lower than 3% and registers it as the throttle lever being set to idle, which is absolutely not what I want. Is there any way to disable this so I can pull full back on my detent without shutting the engines off? I'm absolutely sure this isn't actualy the IDLE or STOP button/binding being triggered because the detent is firm, and it's been well tested and long used for multiple modules. It's never shut down the A-10C or F/A-18.
  4. If it supports DLSS 3.0 then it will help in terms of being able to AI generate a frame inbetween two actually simulated and rendered frames. So if a CPU bound scenario is a drop to 60fps (I know, pretty beefy PC already) you'll still have a visual experience closer to 100fps. But DLSS 1.0/2.0 is resolution upscaling. You'll be able to uptick your graphics settings and keep the same average performance. Whatever your CPU bound FPS was is still going to be about the same -- although likely DCS World 2.9 will run a bit differently in other ways as well.
  5. Uninstalling VIACOM Pro, deleting the App folder within the VoiceAttack plugins folder in program files, plus removing the LUA import line in Saved Games / DCS.OpenBeta / Scripts / Export.lua and deleting the VIACOMPro scripts subfolder is all I did and everything is fine now.
  6. Will try this. I thought it happened before I ever installed VIACOM Pro but in hindsight, those were when I didn't quite understand the right comms bindings. But since VIACOM Pro, it's been well out of whack.
  7. This is actually not a new bug, but the comms menu pops up randomly for me in both MP and SP, and all modules without pressing anything. It seems to be, or might be correlated with mission scripting because it seems to happen more often when overlay text becomes active, either in a training mission or MP picture report. I do not have Easy Radio or the assist for radio activated in the special options menu, and I know what my actual radio bindinds are so that doesn't seem to be the problem. Even further, it happens even if I'm not touching anything. This isn't exactly a bug report, but I'm thinking this is a known and solved problem so I'm posting to see if there's an an easy and clear resolution before I deep dive. The frequency that the menu pops up for no reason is starting to get annoying. Normal bindinds are fine, but if I try to access F10 menu, or am trying to text chat in an MP server, having that menu up changes things.
  8. I'm seeing this too. I've seen it before but previous times it was resolved by a restart of the DCS application. This time around it's persisting across many restarts. If it's related, I also just purchased the Sinai map and was downloading it right as I was trying to login too.
  9. When I fly this mission, during the time you're forced to listen to the narration in active pause, the carrier is not actually held still anymore. The carrier is slowly rotating in place. Easy to notice as by the time you actually fly the gates, the carrier isn't even close to the proper orientation. I replayed it again to look even closer and could see it rotate with my naked eye right at the start of the mission. This bug was introduced most likely with the most recent patch because I've played this mission 4 times a week ago (5/14) with no issue. Today (5/22) I have an issue. Attaching two track files that had the issue. Lesson 10-Case I Carrier Landing.miz_22052023_01-11.trk Lesson 10-Case I Carrier Landing.miz_22052023_01-14.trk
  10. The stuttering may not be stuttering in ST because your FPS is considerably lower to begin with. I didn't notice stuttering until MT made the performance drop to my 1% lows massive. But as I did a ton of profiling, the performance issue was very much there in ST as well. Debugging performance stuttering is a difficult problem to solve, even for an actual software engineer. You might get lucky trying random things, and have a fix in a few days. Or take a steady and process of elimination path and have a confident identification of the problem with a solution eventually.
  11. The ABRIS moving map scale feels kind of useless. The paraphrase of the training mission is that the scale is <centimeters>:<scale value> so "1:2.00KM" is 1cm on screen is 2.00KM in real life. At least the training mission subtitle is aware and also says "keep in mind that the ABRIS screen is 16cm wide." Unfortunately, nothing else on that screen helps you reference that size nicely along the width, and even worse the screen is clearly taller than it is wide so how to reference vertical distances with some accuracy is further lost. How do you properly read out distance on the AMMS in DCS? I've flown this module for over a long time now and am just realizing this because I'd like to fly more serious multiplayer servers and given the substantially reduced INS performance (errors) reading this map accurate versus reality is more important. I've gotten by this far because lasing gives precise distance.
  12. I'm not an expert in VR matters, but how do you remove the idea that the CPU is the culprit? DCS stutters can be a lot; I found serious stutters coming from both DCS-BIOS and DCS-ExportScripts -- I had to turn those off. VoiceAttack, SRS, TacView, VPCLinkTool, and DCS ScratchPad were all fine. I know you describe it as "terrain stutters" but honestly, the stuttering I've seen in general with this game have generally been most observable on terrain to the naked eye but is most certainly the entire game. Without stats from a profiling tool like MSI Afterburner, you don't know what you have.
  13. I can understand complaints about the flight model with respect to the flight performance and behavior in certain conditions, but there's a lot of "I can't control it" issues which is not really the flight model. I don't know what there is to talk about beyond a) calibrate your device however the manufacturer is says it should and b) check that DCS sees the full range of movement. Only after those two are confirmed should you then move to consider a) hardware adjustments or b) software adjustments. Hardware means, maybe get another device, maybe change up spring tension, clutch/dampener friction, or use an extension. Software adjustments involves deadzones, curves, and even saturation. EDIT: forgot to add one thing. Make sure you don't have any unwanted devices influencing the cyclic and collective axes. The latest patch seemed to change in nature slightly and I had plugged in devices that would be fine if untouched. Now, they seem to impact the axes behavior of the device I am using even if they're unmoving and centered (or in any position). I haven't tested in detail but the way it messes things up isn't obvious -- as in, it's not a clear override sticking the axis to the position of the unused device. So if you notice worse behavior with the latest patch, recheck that you only have one device with a binding for those main axes. If none of that makes the AH-64D flyable for you, then it's purely a "git gud" issue. Anyone who uses the term "squirrely" to describe the AH-64D is unfortunately telling on themselves. Hovering a helicopter is constant corrections -- a motor skill. If you call it squirrely, that means you're overcorrecting and/or not reacting fast enough when the heli is clearly accelerating in a direction so it ends up going all over the place. The thing about motor skills is that you can listen to advice all day, every day, about how to do it better and you won't have a eureka moment where things just click and it's easier. It takes pratice. Hover and fly for 15-30 minutes in the morning, and 15-30 minutes before sleep and you'll notice a huge difference over weeks. What takes your full attention to accomplish in week 1, by the end of week 2 you'll be able to do with 50% effort, then 25%, and eventually it'll slip into near second nature. What you're able to do with the extra focus is observe and deal with other factors: weather and atmospheric conditions, threat conditions, and overall operate some avionics while flying.
  14. This is somewhat of a question too because I don't even know if these are functional in DCS other than the visual and audio cockpit behavior. If these switches don't do anything them I'm fine not binding them.
  15. Also confirmed working for me. Now my UI is back to sensible. Only thing I need to be able to do is move (or choose placement of) the controls indicator.
×
×
  • Create New...