Scaley

https://www.digitalcombatsimulator.com/en/files/3321955/

This bug is still present, and still only appears on MP servers so is very hard to get a track of. One things that is absolutely reproducible is that when this happens it is associated with the TADS slaving back to a point different to that marked by the ACQ Source dashed cross marker. When you slave the TADS you see the TADS move to point at the incorrect location, but simultaneously it is showing correct cueing information (dashed cross and cueing dots) to the correctly stored location. The pilot always sees the correct location, and in their version of the sim the TADS is pointing the correct location. The offset between the stored location and where the TADS slaves to is a fixed offset (in our last test around 680m) and this offset remains constant with repeatedly storing points and slaving to them. In all cases the point is stored in the correct location, but when the TADS is slaved it points to a location offset from the stored point.

OK. What we saw was that it got fixed at some point in one of the previous patches, and for a while we could use LMC, but now as you say it desyncs.

I think it actually WAS fixed, but was re-introduced in 2.8, along with the related bug where the CPG stores coordinates via the TADS and the location the (desynced) PLT version of the TADS is used to generate the coordinates.

Yep, 2.8 made widescreen even worse, so now things render at all kinds of odd distances. I've got several lua hacks applied to get my view settings to work correctly: DCS World\Config\graphics.lua edit line 269 (or the equivalent in whatever view distance you have set in game - line 269 is for extreme) lodMult = 1.7; DCS World\Config\terrain\terrainoptions41.lua This part is required to help prevent stuff disappearing when you add the line to autoexec.cfg ass below. edit from line 340 bufferSize = 50000; checkBufferSize = false; multiAppendBufferSize = 9524288; parentBufferSize = 50000; childsBufferSize = 180000; saved games\dcs\config\autoexec.cfg add a new line options.graphics.DistanceFactorDefaultFovy=145; (higher numbers = render things at further distance, but eventually you will get the "close things disappear" bug, so you will need to test anda djust) The added line in autoexec/cfg obviously survives an update. the other have to be re-edited after each update or repair. Hope that helps.

As per the title - points in the database that are deleted by one crewmember remain in the database of the other crewmember. This was intermittent before 2.8, but now appears to happen 100% of the time, regardless of which crewmember deletes the points.

The only way to do this is to make sure the loadout you have selected in the rearm window matches what is currently on the aircraft. If you have half empty rocket pods this isn't possible, so if rockets are available at the FARP you will automatically get your pods refilled.

If you are employing in LOAL you should have a NAV range up, which should drive a countdown timer. If you engage without an alternate range, and with remote designation, then you're correct there is no range (as always, caveat, DCS not IRL).

Not sure who this is addressed to, but it happens with the designation (2nd) detent held down for self-designate shots, and it also sometimes happens for remote shots with no designation. Either way whether or not the laser is firing shouldn't affect whether the countdown timer appears when you shoot a hellfire.

Just wondering if there is any progress on this? The bug report is 6 months old, and this "feature" wasn't implemented at launch, it's been added (thus making the FLIR significantly worse) in an update. I know ED hate rolling back code, but even if we knew how to switch this off in lua it would be a good stopgap until the switches in the cockpit are implemented.

That is your endurance (time you can remain flying based on current fuel) in hours:minutes.

Just to touch on the point about whether you can shoot at an FCR target or whether you need to see it with TADS (and accepting I have zero access to the current IRL US Army doctrine/ROE, and never have done)... This isn't something that is going to have a single answer, even in a given warzone. By way of a few examples - in Syria currently could you employ on an FCR target? Very likely not, since even if you knew the vehicle was an AFV (tracked armour) it wouldn't tell you the owner. You wouldn't have met the mission specific ROE. Conversely in a Fulda gap "a massive horde of tanks are coming" scenario you might have a situation where knowing something was a tracked vehicle (aka very very unlikely to be civilian) and it being in a certain area (aka not a friendly vehicle) would meet the ROE and enable you to engage. The next day (or the next hour) the same AFV radar target might no longer meet ROE if you didn't have as precise info about friendly force locations. Whether a particular contact on a particular sensor meets the ROE and you can engage it is mission/time/situation specific, and that doesn't change whether you are in an Apache, a tank, a Hornet or destroyer. In addition, the ROE can't possibly cover ever situation, which leads back to Raptor's point about training.

We see this all the time in multi-player - often the TOF countdown just isn't displayed. Not sure if it's reported since to show it properly you'd need 2 trackfiles and a screen recording.

It's a millimetre wave radar which, without getting too technical, means it has much higher resolution than a typical airborne radar, but also shorter range. To identify targets such radars are using a database of return signatures of certain vehicle types, and matching target returns against that. Most such databases would use key features the radar could pick out, such a gun barrels, the outline/profile of the vehicle, tracks, etc The range of the version we are getting should be 8km.

These has been a bug already reported about not being able to repair when one engine is damaged, since DCS seems to think that engine is still running.

Absolutely. The problem with the way it's been implemented by ED is that you get ALL the stuff in the mission, which if it's a large multiplayer online mission will fill every target point in your point database. Clearly you aren't going to use all those targets/threat/whatever. We just need the option to select, on the player side, whether we get all these points in our database or not. Even a setting in the special tab in settings to turn it off would be great.

Are any of you on widescreen monitors? If you are DCS interprets the wide screen as being zoomed out and will reduce the draw distances. There is a workround, but it breaks other things, requiring some lua editing, which in turns breaks something else requiring more lua editing. It's been reported but the last reply I had from BN indicated it was low priority to fix.

Good plan! That replicates exactly what I'm seeing and also was struggling to capture using OBS.

Of note it now looks like in 2.8 a new/interacting/worse version of the underlying problem has been introduced. Exact cause to follow after some investigating but now even with editing FOV settings if you have a widescreen monitor ALL ground vehicles and smoke effects are invisible outside a few miles. LODs for aircraft also demonstrate the same issue where the LOD scales to a distance version far too early.

Thanks, that makes more sense. There are clearly FM modifications that happen between the controls and the aircraft that won't alter the control indicator, but will alter the way the sim handles. I think I misunderstood you and thought you meant there was a mismatch between the controls and the control indicator, rather than the fact that the control inddicators don't tell the full story about the aircraft dynamics.

If that's NVGs you should not be seeing the HDU data in any way. It's a bug.

I totally agree, you don't need to in order to fly the aircraft and I never have the indicator up normally. However, for example if you are trying to teach someone, or learn something, then having control indicators that give you inaccurate information is fairly limiting since you might be learning based on inaccurate feedback about what the aircraft is doing, or supposed to be doing.

I fully appreciate it isn't finished, and WIP, and BETA, and EA, etc. What I was attempting to get at, perhaps badly, was that right now if you are saying the control indicator does not actually indicate the control position then trying to learn what the aircraft does/how the systems work is somewhat difficult. I realise it's all written in the manual, but as you have stated before the manual reflects how the real system works and how the DCS system will work in the future, it doesn't reflect the actual software we have right now. While it's obviously technically true to say "it's EA/WIP, stuff might be wrong" that's not too helpful to us mere mortals trying to learn to use this thing. Equally, from the 2nd post you've written it seems like you are saying "the green indicators MIGHT" be inaccurate not "they absolutely are inaccurate, because of x". For clarity I'm no ED bashing, I'm not trying to complain because it's EA and I want it better/faster/more correct, and I fully understand software development and the various pulls on dev time, budgets, coding expertise, etc, etc My only point is, if the control indicators are ACTUALLY KNOWN to be inaccurate then that is a bug, and a pretty big one. It's also one that is basically impossible for the user to identify without serious hacking the code or some VERY detailed testing. So far you're the only person I've seen suggest that the control indicator doesn't reflect the actual control positions. Either the ED devs think it is accurate (in which case I'm not arguing because I can't detect if it is accurate or not) or they think it isn't accurate, and it should be bug reported internally. Either way it seems like a simple thing to check.

Is that bug reported? That sounds like it's going to lead to loads of people struggling with the SCAS and/or misinterpreting what it's doing or not doing in various conditions.

Basically yes. I think the intent is the only real-world reference you can make is to forum-rule-compliant data SPECIFIC to the model of CMWS that is supposed to be modelled in the DCS Apache. Nothing meets those criteria, especially given we don't know what CMWS suite/version is being modelled, so I'd read this as "do not discuss or reference anything to do with the real CMWS in any way", which isn't a terribly bad thing. A lot of data at the level we would be interested in is publicly available or quoted/described in the usual suspect list of books. Correct, although there are some "missile" type warnings from the RLWR in DCS, which are the ones that say "LAUNCH" in place of "TRACKING". The generic "MISSILE, MISSILE" ones come from the CMWS via the ADF audio channel. The fact that both the CMWS and the ADF in DCS use one audio channel is obviously why there is that switch on the CMWS control box to change what is played via that channel.