Scaley

Personally what I'd doing right now is scrubbing the ENTIRE database using a voice attack script on each new mission, and only adding back anything I want. This is designed for MP where there are no waypoints in the mission. As people have said, this is purely a workaround for the (rather rash in my opinion) implementation ED have rushed to of dropping EVERYTHING in the targets and threats part of the database without an understanding of how that's used, and what those points are for. Scaley's Threat data scrub v0.1-Profile.vap Data Scrub Keybinds.txt

We might need some more details about the circumstances, location, etc. Is this a reproducible thing or has it just happened once?

We are working on some planning apps in the 476th. Currently we don't have a stable flight model, but the hover torques seem to have settled so as a first stage we've got some adjusted charts to do planning by hand but for the DCS Apache rather than the real one. What we currently lack is anyone who is really interested in making the actual app and interface part, so if anyone wants to take that up we can help and provide data and testing.

Nope, not at all. DCS knows nothing about your TIR centre position. All the boresight does is make the (simulated) aircraft know an arbitrary starting points for your (simulated) head. TIR re-centre function changes how your real head maps onto your simulated head, so will in no way affect the boresight within DCS.

What monitors are you guys using to get this bug? There is a known but not acknowledged bug/feature where DCS uses you horizontal FOV to scale the distance vs LOD calculation. Basically as you get a wider monitor the rendering distance reduces.

That's interesting, perhaps related to the current bug where if you export the MPDs or TDU they are actually rendered twice on the in-cockpit view.

If you join in CPG slot, leave, and then re-join the NVGs work in the front seat. Still annoying and clearly a bug, but there is a workaround thankfully.

This is already reported I believe, and Casmo has it captured in a video as well.

Somewhat intermittent bug, but editing a point does not move the point on the other cockpits TSD map, despite the coordinates showing as correctly updated and matching in both cockpits. Point Edit CPG.trk

As title, cursor locations do not match. Cursors CPG.trk

CPG gets a rotor brake caution in EUFD if they join an aircraft during flight, despite rotor brake being off in PLT seat. Rotor Brake CPG.trk

CPG TrackParking Brake CPG.trk

CPG Track Manual Stab CPG.trk

CPG Track Hold Modes CPG.trk

Friction exists for sure, but if you go for a fast taxi in any of the jets your discover that the friction is WAY too low. They all drift laterally in conditions that the manuals suggest would cause rollover. Similar odd things happen lie the fact you can pedal turn the Apache at relatively low torque settings with the tail wheel locked, and taxi forwards at 1-2 knots with the tail wheel pointing sideways and the friction will be so low it won't caster to the centre. There are a lot of threads in the forums about this over the years, some with numerical test data, that support the idea that DCS just has too little friction between rubber tyres and the ground.

George works reliably for everyone else. The problems you need to fix (based on your screenshot) are: Do not have the weapon actioned yourself Actually select the target in the list, this requires pressing the "George interface right" command once you have scroleld to the correct target. At that point the target list should disappear, and George will focus on just that target.

They absolutely are. You can drift the jets at 15-20 knots. Been that way forever.

I'm hoping at some point the whole TSD will properly sync, because right now actually more functions DO NOT sync between the cockpits than ones that do. In our group the only 2 things that seem to (mostly) reliably sync are creation of points, and adding them to routes. Almost everything else does not, or only syncs intermittently. Given the TSD point database is probably a fairly large code section to re-do I wouldn't hold your breath on any of the TSD stuff getting fixed unfortunately. Previous ED releases have generally shown that adding new features are prioritised over bug fixes for core systems, even when (as is evidently the case here) it's stopping people flying the module.

I think there is some confusion here about the difference between retreating blade stall and dissymmetry of lift. As you accelerate obviously the advancing blades (on the right) generate more lift and the retreating blades (left) generate less. To counter this you apply right and forward cyclic and the aircraft stays level. Blade STALL is when increasing angle of attack (by cyclic) does not increase lift, but rather decreases it. If you apply right and/or forward cyclic and it works you are not at retreating blade stall, you are just flying. If you apply right or forward cyclic and it produces left roll then you have retreating blade stall.

Sounds like something is wrong with your setup or hardwear. Have you checked what the shows in the controls setup screen if it's accessed directly from the main DCS menu rather than in flight? Also, have you tried cycling the various axis after the mission has loaded while you are still on the briefing/pause screen. While you are looking at that screen the sim engine is running and will detect any axis movements or button presses. If you have stuff you want to sync then if you move/toggle them at that screen they will always be in sync regardless of the "sync cockpit controls with HOTAS controls at mission start" setting

This is the normal solution. In my experience (and many other people) the controls sync much better with "sync cockpit controls with HOTAS controls at mission start" disabled. When this is disabled DCS makes some (very sensible) assumptions about the axis positions at startup like assuming throttle is idle, etc. Best to always have this off unless you have a specific reason for having it on. Also best to just run all your axis up and down a little before you drop out of the briefing screen just to make sure DCS has detected everything.

Just a little bump for this topic. Currently AH-64 recruiting on our website is marked as closed, but we are still interested in any experienced DCS helicopter pilots who might want to help instruct or develop material and tactics for the AH-64 and/or UH-1. Also worth a note that we have both US and EU time zone regular flight nights, and membership is currently split about 50:50, with a scattering of members from other locations around the world. A few people recently have got the impression we are a US based group.

Yep, almost every significant battle damage to the DCS Apache appears to result in some kind of FADEC failure on one engine which manifests as failed sensors/incorrect readings, and the requirement to manually manage the throttle. It seems it easier to cause this failure in the current damage model than to actually kill the engine completely (which I currently have not seen at all, only the low RPM state you observe here).

I'm not seeing the behaviour at all. In the current build the true airspeed in the HDU (I'm assuming that's what you are talking about) shows the wind speed if static on the ground and pointed into the wind. In the previous versions the readout that should have been TAS was actually GS at low speed, so it showed values even if you were going slowly enough that the ADS wouldn't read.

Yep, the ACM is implemented, but neither cockpit has a switch that works, so it's on all the time.