Flagrum

Seriously? Then name your planes after the girlfriend you had before her. ¯\_(ツ)_/¯

Why would that help? If there is a bug in the base game, it would have to be fixed in both products and then result in the same problems there (if any). It would add only to the workload to maintain two huge software products in parallel. Also, over time, the code in both products would begin to divert - how could ED maintain two such hugely complex products if they were struggeling already with one? Splitting it into two products would not halve the problems, but double them.

Ok, I got it now. During Ball-and-Chain there is nothing designated yet and therefore the aircraft has no idea wether or not the parameters will be met in the end. But once designated, I then see the proper DUD cue if appropriate. Learned somthing today - thanks!

Thanks Bignewy for the feedback. It makes totally sense now - I was too busy fiddeling with QTY and so on and didn't realize that I was descending to far... But ... But then there is a problem with the DUD indication on the HUD. Afaik it always worked when using CCIP, but in AUTO there seem to be issues as the DUD indication does not show up (otherwise I would probably have figured out by myself). The HUD indicates a perfectly releasable situation, only after pressing the pickle button the MC decides otherwises. Please see the attached screenshots!

That was the case here. I moved the offset cursor to the left building and TDC depress. The end of the track should show that I switch from PTRK back to OPR and the TPOD view jumped to the designated point: the building on the left, where I initially(!) had palced the offset cursor.

Hrm. left: tpod, right: dmt flir all displays at default settings. if only looking at the ground, it is better. but beware if you ever catch a glimpse of the sky or worse, the boiling water of the gulf ...

@tester team could you please confirm that these bug reports are looked into? I ask because they are missing the respective [tag] in the title ... https://forums.eagle.ru/showthread.php?p=4381785#post4381785 https://forums.eagle.ru/showthread.php?t=278376 https://forums.eagle.ru/showthread.php?t=278276 https://forums.eagle.ru/showthread.php?t=277769 Thank you!

:doh: There are one or two other issues they need to work on. In fact, they have a rather long "to-do list" and i bet, this issue is somewhere on that list. It is just, that you need to start somewhere and then work down your to-do list. But if you change your to-do list every time a posting on the forums appear, you will do nothing els than shuffeling the entries on your to-do list. what you probably won't do: fixing bugs. no, this issue is probably not rocket science, but yet, one has to work in an organized way.

Which bug do you wishthem to delay fixing for fixing this one?

My - unproven - theory: area tracking uses the optical sensor to keep the TPOD pointing in the area on the ground. I.e. it tries to maintain a steady view of the overall picture. Ground stabilized keeps the attitude of the TPOD steady (compensates for aircraft movement) in regards to the theoretical point on the ground it is looking at. So, ATRK is more similar to PTRK than to GS. The GS should probably drift a bit if the elevation data / height over ground is wrong and the theoretical intersection of view line and ground plane is below or above the actual ground. But that is only my theory for the RL operation. In DCS all this seems not to be modelled at least (or I am totally wrong with my theory ;)

Every other week someone accidentally posts there, but I don't think anyone still runs 2.0 ...

it's likely a bug. see https://forums.eagle.ru/showthread.php?t=277769

I haven't found out the exact pattern here, but something is broken with AUTO deliveries of dumb bombs when switching priority stations with the STEP function. The EFUZ setting seems to get lost sometimes if the QTY is changes before or after switching the priority station with STEP. The delivery options and fuze settings apply to all stations, it is not a setting per station/bomb, correct? So if I pickel several times, the aircraft itself switches subsequently through the stations and effectively all releases use the same EFUZ setting and all bombs explode on impact. But if I change either QTY or (or maybe both, not sure here) STEP to another station before pressing pickle, the newly selected station(s) sometimes do not respect the EFUZ settings (i.e. go dumb and don't explode). This seems to be only related to AUTO delivery, CCIP seems to work ok in this regard. Also this seems to be only a problem, if I manually STEP - if the aircraft switches stations, it seems to be ok as well. AUTO EFUZ 1r.trk AUTO EFUZ 2r.trk AUTO EFUZ 3r.trk

I tend to agree that CCIP can be more accurate than CCRP - given that the symbology is exact. In CCIP, you always see exactly where the wepon will impact. Slight corrections of the aircraft attitude result in precise adjustments of the pipper. In CCRP however, you only have your velocity vector that you have to a align properly in respect to the bomb fall line. Slight attitude corrections are barely visible due to the thickness of the lines of the symbology. One degree deviation is maybe a visual difference of one pixel but it would be clearly visible in fractions of an inch with the CCIP pipper. But maybe this thread isn't the right place to discuss this ...

The PTRK offset cursor (ATRK not tested) does not stay ground(?) stabilized at the with TDC depress designated position. Instead it is "DDI stabilized", meaning, it's absolute position on the DDI screen does not change. (The red box ensures that the lines are parallel to the DDI frame. ) In both pictures, the right border of the red rectangle goes through the offset cursor and the right side of the attitude indicator, although the video feed has changed as we got closer to the target. Note: a) the actual target designation with the offset cursor (tank on the left) is correctly maintained! This becomes evident when switching from PTRK to OPR: the target diamond is then correctly placed where the designation was (and not where the offset cursor cross was in the end). b) Zoom and FOV scale the position of the offset cursor correctly on relation to the video feed. I.e. as the image gets smaller when zooming out, the reticle moves accordingly as well - but is still in it's wrong relative position. TGP offset cursor.trk

"presume", "may be" ... hrm. If we all don't really know, what is wrong with asking? I, too, find this behaviour a tad bit ... strange. It is really no big deal, but it seems to be somewhat "backwards"? Or at least less intuitive? I mean, we have one button that performs one function in this context: undesignate. What do we gain, if we add another function, that even perform two tasks (1. undesignate + 2. enable VVSLV)? Why not keep it simple: 1 x for undesignate (no ambiguities here), and when in snowplough: 1 x to enable VVSLV? I could easily be convinced that the documentation says something like "to enable VVSLV, depress UNDESIGNATE twice". ED interprets this then as double-click, but it could also be very possible that my solution was actually meant. The only differens for the pilot is the timing of the two depresses - instead of click-click only click, click ...

The calculated range should be quite the same if I measure the bottom or the top end of a larger target, right? Perhaps the slant range is a few ft shorter at the top, but that is negligible here. The follwing pictures were taken when in Active Pause (so that the overall range does not change). The TPOD is telling us, that the slant range difference is 0.2 nm between top and bottom of the water tower!? This is rather the difference between the bottom of the target and the point on the ground behind it. (Also, after PTRK-->OPR, when the TPOD slews to a new position, designated using the offset cursor, the range information is not updated. Only after moving the reticle a bit, the range info is updated. But this is probably a different issue.)

Yeah, I just re-watched it. But there are some interesting details in that scene: - LST/R is not shown during that process, so I assume the laser wasn't even armed? - At least shortly during/after TDC depress I would expect LST/R to be shown _and_ flashing as indication that the laser was doing something - the range shown was updated continously as the aircraft came closer to the target. I assume, this is just the calculated (slant?) range, probably based on the initial laser ranging. In the A-10, the aircraft utilizes the digital map data to calculate the slant range, even without lasing first. What I try to say here: just because a range is displayed does not mean that lasing must have happened initially. So, my bet is on "still WIP" here. Slant range calculation + display works, but the initial laser ranging is probably not implemented, yet.

Indeed. I found three different threads that the issue is known WIP / maybe fixed / related to a different WIP issue: Hrm, I might experiment a bit with realistic TDC slew on / off ... edit: and just now this So it might be related to wether it is the first Maverick being selected and fired or subsequent ones. In my case, I have probably only restarted the test mission with CTRL+R (SHIFT + R?) several times to eventually produce the .TRK. So, maybe there is some global initialization issue with the MAVF code? I'll check that as well.

Can I get a [REPORTED] here pretty please? ;D

I think, laser ranging is not implemented, yet.

Afaik single press to undesignate which will cause the TGP go to snowplough. Double press enables VVDSG.

The LTD/R switch at the sensor control panel activates (ARM) with LMB and deactivates/SAFE with RMB. All other switches use the opposite binding (i.e. forward/up = RMB, back/down = LMB).

After some research, I am now convinced that the constant updating of the coordinates is correct. Also the behaviour that all respective weapons in case of QTY > 1 get updated with the same coordinates seems to be legit as well. Source: ### self redacted, see 1.16 ###

To replicate this bug: make sure that no target designation exists (i.e. TPOD shows no target diamond in OPR). For example, right from snowplough mode.