FalcoGer

That is not what I asked about. I asked if there is some system in place that would prevent a single, bad measurement from messing up the aim. The apache's default range is first reflection, but can be swapped to last. I guess I could give that a try as a workaround, but still not what I asked for.

I'm well aware of that. Which is why I wrote a bug report about it.

Here are a few random thoughts in no particular order regarding damage and system failures that I have noticed so far: The main landing gear seems pretty much indestructible. You can slam down really hard and the chopper doesn't care There are some bugs with single engine operation, in particular torque requirements more than double Pylons and tail can be shot off, balance is affected. Also without tail you will start to spin at low speeds. Dual engine out will result in power loss, emergency hydraulics seem to work as they should, providing control authority for a few seconds to land safely DECU can be killed, resulting in engine going full pelt Overspeeding engine shaft can be snapped by providing a sudden increase in torque requirement by slamming the collective up. This will result in the engine failing. Computer failures (WP/SP/DP) appear to not be a thing. CPG and PLT can be shot dead. After being shot, you can not have George get an oil change to be put back into action. Never had a gun malfunction or optics (TADS/PNVS) malfunction. Cockpit windows can be shot, but you don't see the holes from the inside. WSPS seems to work in some cases. if not it usually just snaps the rotor blades. I've never had an engine fire Never had a hydro failure Never had an oil issue Never had an avionics overheat issue Power loss was always associated with engine failures, TRU/Gen failures are not a thing unless you specifically turn stuff off yourself. Failure checklists are not loaded into the DTU (sadness), so no quick references on the engine page. Ice indications jump happily between between severe, moderate and light icing, even at insane temperatures. But nothing is affected. I've had a few radios fail on me before I've had my radar altimeter shot out before, it was stuck at the last value it read (so the best thing to do is to turn it off completely and rely on baro instead) Zeroize doesn't do anything. One of them should fry the chips and do irreversible damage. Can't remember which one though. No canopy jettison (sadness), as an extension, no injuring people in the 50ft danger area when jettisoning the canopy. INUs seem to drift, and independently. But it's really tame and you only really notice when you return after a long flight and the helicopter indicates movement when you're clearly still. Nothing much else seems to be modeled.

So is that correct? Or is there some sort of filter, perhaps an averaging, or something going on to prevent single, erroneous readings like that from affecting the targeting? Surely someone at boeing must have thought of that, or fixed it after it happened in testing/combat.

We were happily flying along when my CPG reported both engines out and blades spinning down while I was having no such issues. Apparently for him we were flying with the rotor being stopped while for me everything worked perfectly well. Files were recorded on a big multiplayer server, so track size is large. The bug happened about 40 minutes into the flight. https://drive.google.com/file/d/12ZWgvhbp-REiqVR9cpsc9aauogN-T-XQ/view?usp=sharing

My experience is this In multiplayer, as CPG I don't get aural RLWR warnings for SAM sites don't get visual ASE indications for SAM sites don't get aural warnings for missiles do get aural warnings for AI aircraft, such as E3 or Mig 29, both searching and tracking (unsure about player aircraft) do get visual ASE indications for air radars on the ASE and TSD pages As pilot I get all warnings and indications as expected. In SP I do get all indications and warnings regardless of which seat I am in.

I think they changed the logic. When you put a new frequency in, the current frequency is pushed to standby, and the standby frequency is lost. Not sure about the latest patch though.

Don't be silly. You already have the models for infantry. All you need to do is pull the skeleton points around a bit to make them fit onto the new weaponry. Surely your engine can do at least that very basic thing? I mean you do have working skeleton animations for carrier crew and the newer infantry models. I for one couldn't care less about the patches on their arms or if they have the correct helmet on. You can always add the details later. Besides, you really shouldn't be having the crew as part of the weapon model in the first place. If you look at other games, the infantry in a car isn't part of the car. Reasons: 1. Storage. You have 1 model of some guy, instead of having the same model of some guy baked into 50 different units 2. Reusing assets. No need to do modeling work (delaying production as we see here) over and over and over again 3. Extensibility. Later down the line the crew might disembark from their vehicles. Now you don't need to make a new model without the crew, taking extra storage and yet again, the crew as a model. Both taking time to develop and drive space For instance if a pilot ejects right now, it generates a generic pilot model. Instead you could create two models. The aircraft, and the pilot (to simplify, obviously the aircraft has more parts that constituate it's parts, such as the ejection seat or canopy for instance). And voila, you get for free the correct model for an ejected pilot.

The question isn't: "What should I do" or "Why don't you look outside". The question is how to accurately simulate the aircraft in such an event.

The beam's vertical element only indicates the maximum articulation of the pylons (and the beams position indicating your yaw error). It shouldn't affect anything as long as it's valid.

Even when I fly over the woods, or park right in front of them, the framerates are fine. Only when the camera is pointed at the woods near horizontally is when the problem is occurring. Even if the camera is pointing downwards over the forest it's fine. I can do nearly anything else and the game is running fine. It's particularly bad when I'm flying and the camera just happens to be pointing horizontally in TV mode and I have the video underlay on one of the MFDs. If I turn that off it's immediately fine again, even though the very same woods (with the very same complex shadows) are right in front of my nose as I fly over them. Edit: I have since upgraded to 64GB RAM @ 3200MHz, same issue still in latest openbeta (7th of January 2023)

Even if you cut the throttles, hit the fire button and have the ground crew drain the aircraft to 0 fuel, the dead engine rpm will stick.

can not reproduce? I even gave you a track file. I guess I'll have to provide a video as well. Here is a video of the previously recorded track played back with the framerate counter present.

When you press the L/R button, the cursor jumps to the other screen as it ought to but then it immediately switches back to the origin screen. You can work around that bug by pressing it twice in a row fast. Real pilot was in the back seat. server-20220722-031857.trk

still an issue after this patch. Here's a track, other bugs are present in it. server track is me, sitting in CPG, running as server other track is pilot, running as client. Ah64Issues-20220722-112042.trk server-20220722-031857.trk

I'm aware of the workaround. I was wondering how the real Apache handles it to get a better simulation.

I think it's a bit strange to be setting 17 knots surface wind, then climbing up in an airport in the mountains and 50m off the ground be suddenly hit with 40 knot winds.

A workaround would be to selective jettsion the already missing pylon. I found this makes the aircraft loose the pylons from the weapons page, even if the pylon is already gone.

Yes. That's what I mean. Now that you mention it, it kinda makes sense.

This should be interesting. I wonder how it behaves if a vehicle moves behind something. Will i try to keep track inertially and try to reacquire behind the obstacle or will it just give up? Also those vehicles look to be mostly unmanned, just sitting there while everything around them blows up. Also I noted that the video appears to be distorted. I don't mean the atmospheric effects of the hot ground, but you see the symbology is blurry and at some point the lines don't connect right. What's up with that? Looks like the recording bitrate and resolution are really crap. Why can the army afford multimillion dollar helicopters but can't afford something that any consumer camera could record better in their multimillion dollar sighting system? The actual tracking itself seems to follow a fairly simple and straight forward algorithm of trying to finding connected pixels of similar intensity, then drawing a box around the outermost edge of those connected pixels and slaving the camera to it's center. I heard people talking about how IAT isn't that great, how explosions make it go wild. From what I see here it just tries to auto track the explosion dust before it gives up because the area is too big, presumably. First of all, that doesn't make it less usable, since the target is dead at this point. It just makes it slightly less convenient since you're now a few hundred meters, at worst, off target. For stationary targets or targets moving without cover this should be perfectly fine. I shall make liberal use of it, as those pilots seemed to have done as well. At one point you can see that the contrast wasn't great and the auto track tried to box the ground below as well before giving up. The pilot just tracked manually at that point, but for every other instance he used the automation to reduce the workload. I never said it was magic, but it's not nearly as useless as some people here suggest. I imagine the software for it could be updated to use more advanced algorithms. With AI vision and some additional logic this could become quite good. I'm sure they have plenty of footage to train their models on. Of course DCS' implementation will be magic, as it usually is. We never get a proper contrast lock, evidenced by the fact that we can't lock onto burned out vehicles. In aircraft like the a10, ka50, su25t, f16 and f18 which all have some kind of point track, this can be abused to identify destroyed targets because the camera will not "snap" to them.

You mean like you press the button to take control and then move the axis somewhat close to the other pilot's before control is actually transferred? What of no axis is bound, like for example I don't have the throttles bound to an axis, so I can't match it.

I could still hit the ground close enough nearby to destroy the equipment. You don't need to hit the fencepost if you can hit anywhere in a 20m radius around it and still be confident that the equipment is trashed. I understand that the laser spot is wide, especially at a shallow angle, but george is way more unstable than I can be. Also what do you think would happen to a predator drone over an SA15 site?

Why is that thing in the artillery section? Isn't a Grad a wheeled truck with an MLRS on the back?

With 2 rapier sites, at least 1 tunguska and a sa 15s around, I couldn't exactly hover at 200m with no cover. I was flying stable and I would've hit those targets myself.

Related post: