Vakarian

2 sidewinders and 2 empty tanks weigh less than the difference in fuel you had in sorties. While it is possible that the damage taken could hamper the engine performance, that would also be indicated by some warning going on and you should see it on annunciation lights. Were the weather conditions (temperature is of most relevance here) identical in those two flights and did you land at exactly the same place (airfield)?

Threaded inserts for combining large pieces. For attaching buttons holder to the faceplate, just use M2.5 screws and screw them directly into the plastic.

The switch I'm using is ON-ON switch so as long as it's in the position it will keep the "on" signal active. Just double checked it in the button tester , so that shouldn't be an issue. Also, I've tried both separate on/off bindings and toggle binding, none of them managed to activate anti-skid. Only mouse clicking was able to do it, no other bound control seems to work. The thing is where I've bound ON-ON switch to it, ingame switch would be in position but anti-skid wasn't engaged. When I've used toggle button it was in "on" position for as long as I've held the switch but it always spring returned to off. Added new track to support this. First I've used mouse button couple of times, then I've used ON-ON switch, then I've used button that was bound to "Anti Skid On else Off (2-way switch)" and that only remained in up position for as long as I've held the switch. Finally I've used mouse button again and just flicked the switch to up and it worked. Now I'm more sure it's a bug because none of the bindable controls seems to work. antiSkid2.trk

Buries it at 0 MSL. That was the first thing I tried hehehe

Thanks for the input. I know you can edit the desired elevation, but that wasn't the issue. Thing is that I don't know what elevation the waypoint should be so it's 0ft AGL, but the DTED inside jet knows that. So I wanted to learn how I can make jet reset the elevation for the existing waypoint, as it would set correct elevation for new waypoints. The solution provided by ASAP was just that. Re-enter MGRS coordinates of the waypoint and jet pulls the correct elevation from DTED. All good now

Hmmm, that was one thing that didn't cross my mind, but it certainly sound plausible. I will test this tonight when I get home. Thanks for the idea. EDIT: Yep, that was it. Thanks once again

I start this with an assumption that the jet is able to do this. So in a mission where mission designer has forgot to properly set waypoints to 0ft AGL, we have them stuck at ~6500ft MSL in the air. How can I fix this in CDU so it corrects the elevation of the said waypoint back to 0ft AGL? I assume the jet knows the correct elevation because when I make new waypoint or offset, it is automatically at 0ft AGL based on data from DTED. Following this logic, there should be a way for jet to "reset" the elevation from those default ~6500ft to 0ft AGL.

At work, so can't post a track at the moment, but this bug should be easily reproducible. AFAIK, hot-start or cold-start shouldn't matter, outcome is the same on both. I have anti-skid switch bound to one of my button boxes. The issue is that if I activate anti-skid using that switch, I see the cockpit switch move, but anti-skid light on annunciation panel is on. Then I do disengage anti-skid, engage it with a mouse click this time and it works as intended. This has been bugging me for months now and I've only accidentally stumbled yesterday on a solution with a mouse clicking the switch. So it's not the issue that switch is not recognized by DCS at all (because cockpit switch moves when physical switch is moved on button box), but something is missing as the anti-skid functionality in the A-10 is not activated. Could this be looked at? I can provide track in ~10 hours if it's needed. Added .trk file. Tested with both hot and cold started jets. Clicking the switch activated and deactivates anti-skid as one would expect. Using physical switch on button-box can only disable anti-skid but cannot reengage it even though in-cockpit switch is in "on" position. Both switch position and annunciation panel are visible during testing. antiSkid.trk

As a basis, if you don't have any tool to check continuity, you are gonna have hard time figuring it all out. Those tactile switches. There are 4 pins, and 2 on each side are shorted. For ease of use, let's say that one side of the shorted pins is "+" and other side of shorted pins is "-". That way when you press the button those two sides establish a connection. Hope this helps you in figuring out tactile switches. For the toggle switches common configuration is that middle one is ground and two other are live. Then when you flick the switch on either side connection is established and should be wired accordingly. The base of where you start is to look at the datasheet of the equipment you get and start laying out schematic on paper to get the general idea first and then do some testing on the breadboard. Do all this before you start doing any of the stuff "for real" because it will make your troubleshooting easy. Understand how each component needs to be wired and read on any microcontroller that you will use and just scale it up. That's how I started with mine. Got one button, one encoder, one potentiometer and wired it to breadboard in steps (button first, then added encoder and then added potentiometer). Each time I've built upon what I knew was working so it I got into trouble I could easily step back, find and fix the issue and continue.

Devs literally said that R-40 is overperforming and needs to be fixed couple of posts up

Get out of Nevada for starters

When you are in SP mission with Client slots or any MP mission, if you go to menu and select "Choose slot" you have good chances that you're gonna get kicked out of the seat. Procedure goes like this. You start the mission, then select one slot and get in the cockpit. Now, if you go to menu and accidentally (most of the times for me) click on "Choose Slot" option. From this point on you cannot click "Back" or "X" in top right corner. Both of those selections will kick you out of the seat. Only option you have is to select the same slot you selected before to remain in the cockpit. This is not so hard in this demo scenario, but imagine you are in crowded MP session, you see that some of your keybindings are not working. You quickly go to menu to change them and missclick the option "Choose slot". Because this is not what you wanted, you will most likely click on "Back" or "X". I bet you are going to be annoyed when you are booted out of your seat 1-2 hours into your flight... Video describing the issue: I see two options to fix this: 1. Implement some sort of mechanism that will check if you are already in the seat, so clicking on "Back" or "X" does not boot you out in this case 2. Add a warning dialog saying that you will be kicked out of the slot unless you select correct one in the selection screen I would prefer the first option to be implemented, but even the second one will lower the frustration as the end result will/could result is staying in the cockpit. TakeControlBug.trk TakeControlBug.miz

It was very nice and enjoyable to watch. Nice flying man, keep it up and if you make another one at any time I'll be sure to watch it.

CPU like all other components in your PC are guess what, meant to be used. If you have component that's sitting idle then you have "wasted money" because you bought a product you are underusing. Just because there is high CPU usage that doesn't always mean something's wrong, it could be just that there's a lot CPU needs to do. And also, if you check it more closely, you'll see that it's maybe one/two cores running high, others are chilling. That it no concern as that's how DCS runs and there's nothing you can do. Hopefully, we'll have multicore soon and that'll help in getting more of the CPU being used and running more smoothly.

Only thing I know is that this is not related to Apache, but it's a DCS wide issue. I've had it happen in Harrier and A-10 but don't know how to reproduce it exactly to post a track for the devs to look at it.

Just because those planes flew there historically, doesn't mean 100% of DCS community flies exclusively historical missions. As soon as you deviate even 1% from the 100% percent realism, all these arguments fall down. DCS is a sandbox, not historical conflict recreation tool. I mean, don't get me wrong. I'll buy any map that comes to DCS as that gives me more options/variety to make missions, but making your one and only argument "planes flew there in X conflict, that's why we need Y map" is childlish at best.

I've only flown it for ~half an hour yesterday after the patch and I found it to be a lot less twitchy, especially in the yaw department. In all other regimes the Apache seems (to me at least) a much more stable platform than before. Some would say it got more sluggish compared to before the update, but personally I like the change. Haven't had any difficulties evading ATGMs fired at me when hovering while CPG is shooting, I could do all maneuvers I wanted in stable, smooth manner, transitions hover <-> forward flight were way more stable and had a lot less yaw oscillations... Also, I could kill all curves I had on my pedals, so that's nice

From the changelog today: * Added trigger guard as option. See in AH-64D Special Tab in Options. So, this is sorted now

RAM is there to be used, not to sit idly. If you have 16GB physical RAM in your PC it will work OK and game will create swap if needed. If you have more RAM it will allocate that instead of using swap. And recommended setting is recommended. Not "this is maximum that the software will take". You could play SP and you'll be fine with ~10GB usage. Go to a crowded MP server with bunch of units on the map at the same time and just watch the RAM usage increase. That is fine BTW, you want as much of the stuff loaded in RAM instead of your SSD or even worse HDD.

IIRC this was reported multiple times already

I'd guess it's the way DCS is doing de/serialization of list type objects. Lists might get "scrambled", but there's nothing stopping you from rearraning them or copying list in an ordered manner in the file. As long as all the data is there and when deserialized in the mission editor it gets displayed correctly, you shouldn't be concerned if it turns out a bit out of order. Ensuring the data is serialized/deserialized in specific order is not worth the time most of the times. All those channels have their indexes in the square brackets so they should (haven't tested it) get populated in mission editor according to them. So even if they are shown here like this, that doesn't mean they are going to be shuffled in the actual radio presets.

Probably just SSL certs expired, nothing to really worry about

CMWS sees a missile launch and it warns you. It doesn't know if the rocket plume at the back of the missile is from a friendly or enemy aircraft. That's why it's important to call your shot before you shoot so if you call "rifle" and then your friendlies CMWS starts yelling, there are good chances it picked up your launch. This is working as intended, not a bug.

It works, but if you are on some MP server than it might not allow outside views so that's why it might appear not working as there is a mission setting to disable outside views.