Flagrum

Regarding step 7 - yeah, I fell into that trap when I experimented with your procedure. If you have QTY selected, the coordinates will be updated for all selected JDAMs. And that, no matter what procedure you follow. STORES page or individual TOO MSN page, all selected bombs will update their coords. But if you select QTY after setting individual coords, they keep them (unless you mess up with not undesignating at the end). This seems to be some somewhat inconsisten behaviour. Why should it matter _when_ i select a certain option? One could say, this is a quick way to deliver multiple weapons at the same target - similar to rippling a few dumb bombs. But why can I then step between the QTY selected weapons, if I can't change their setup individually? Makes no sense to me ...

When uncageing the MAVF, the seeker head automatically slews to the designated target and tries a lock-on. But if there are other objects in the path the seeker head traverses, the missile will lock-on those instead. Track, s. attachement. Here I briefly inspect the targets with the TPOD. Then I designate TGT2 with the TPOD and the uncaged MAVF slews to it perfectly. But when the designated target is TGT1, then uncaging the MAVF will result in a lock onto a random building of the village between boresight and TGT1: What I would expect: the missile should only attempt to lock somethig after establishing the desired seeker head position, i.e. after slewing is finished. MAVF lock after uncage.trk

Hrm, I tested it just a few hours ago - while the MAVF slews to the designated target, it locks on random objects on it's way. So, that is at least not fixed (or broken again). Visually it looks as if the MAVF seeker head / the reticle stops half way between bore-sight position and designated target position. Are you sure that this is not the problem this thread is about?

The issue seems to be that the MAVF is locking the first suitable object that it sees while it slews the seeker to the designated target after uncageing. So, at the extremes of the gimbal limits, the way it has to slew the seeker is long and chances are high that it encounters a random bush or hut that it then locks on to. If you point the borsighted MAVF as close as possible to the intended target, then only minimal slewing is necessary and thus a higher probability that it only sees the intended target and also locks on to it. --> MAVF should only start to attempt a lock after the seeker head has reached its final position over the designated target. (maybe all this is a side effect of not having "realistic TDC slew" enabled? Would the MAVF only attempt a a lock, if TDC-depress is released? And without "realistic TDC slew" the TDC is always in a "depress released"-state?) edit: (no, "realistic TDC slew" has no effect on the MAVF behaviour in this case. just tested it - it still locks on at any random object along the way the seeker head is slewing to the intended tgt)

I think what he means is this: your TPOD remains centered on the general target area, but you can designate several targets around the original target point. But, as I seem to have learned today, just slewing the offset cursor does nothing. You need to designate a different target with TDC depress. You will then stay in the offset cursor mode while the TPOD is still centered at the original point. From there you can continue to slew and designate the next targets with the offset cursor. Only if you leave that ATRK/PTRK mode, the regular designated tgt diamond will be slewn to the last designated point.

No, that is not what I meant. I am atm just focussing on the regular TPOD reticle. This shows the reticle when there is no tgt designation (i.e. snow-plough). A cross, a bit smaller than the ATRK cross. Then I moved this reticle and designated a point on the ground with TDC depress: The "designated target" diamond is still slewable, but now the JDAM coordinates are constantly updated. Wherever the "designated target" diamond is, the designated target is - and thus transferred to the JDAM. As I said, right now, I am only concerned with this, not the offset cursor. I only mentioned that earlier, because on the TPOD page, the offset cursor is not a diamond and I concluded that that is the reason why no coordinates are transferred ... as the current designated tgt point is not changed just by slewing the offset cursor. Instead, it needs a TDC depress to alter the position of the designated target point.

Starting from snow-plough mode with no designated target, I ground stabilize the TPOD reticle with either ATRK or PTRK mode. If i press UNDESIGNATE, the TPOD returns to snow-plough mode. But that works only if the point on the ground is still visible for the TPOD. Once I fly past that point and the TPOD stows itself (shows "MEM" at the TGP page + no video feed), UNDESIGNATE does not work anymore and the TPOD does not return to snow-plough. If a designate a target point with TDC depress (in either mode, OPR/ATRK/PTRK), UNDESIGNATE works in both cases - tgt point visible or not. tpod stowed no undesignate.trk

Regarding [CANNOT REPRODUCE, TRACK PLEASE] - see attachment. In this track you see me trying to slew, starting from snow-plough. I cycle through OPR (works), ATRK (no slewing, as expected), PTRK (no slewing, as expected) and then OPR again - but here slewing should be possible again, but isn't. I then do the same once more, ATRK, PTRK and back to OPR, but there still no slewing possible. Then I designate a target (TDC depress), the reticle changes from the small cross to the designated tgt diamond and then slewing is possible again. Cycling + trying to slew though ATRK and PTRK once more and in the end back to OPR. There the designated target diamond is still active and slewing is also still possible. In short, when returning from PTRK to OPR with no designated target, slewing the "no designated target" reticle does not work for me. tpod cycle modes.zip

I think, I found something out now ... There is the small cross that is slewable in OPR, if no target designation exists (i.e. snow-plough mode). No coordinates are transfered in this case. When designating with TDC depress, the TPOD reticle changes to the regular tgt diamond. Now this coordinate is transferred to the JDAM. But as the tgt diamond remains active when slewing now, the coordinates are constantly updated. I wasn't really aware that there are two different reticles in OPR mode, lol. When designating a tgt while in ATRK or PTRK with the offset cursor, only at TDC depress the coordinates are transferred. Which makes some sense, as the offset cursor is not the "currently designated target diamond" So, as such, this seems to be consistent. If I now have a WPDSG tgt, the TPOD slews to it and shows already the designated tgt diamond. If I slew the reticle away from that position, it is switched to the "no tgt designate" (small cross) reticle - until I designate a new one with TDC depress. The reticle changes to the diamond and from now on the JDAM coords are updated constantly. And here is one small bug, I think: WPDSG is still enabled, although there is a newer designation present. And besides all that, I still find it weired that the "designated target" diamond reticle, can not be reverted back to the "no active designation" cross somehow (without completely undesignating everything and starting over from scratch).

WAD? And no, I mean something different: Situation: no target designation exists, TPOD is in snow-plough mode Step 1: TPOD=OPR, I can slew the reticle without problem Step 2: Cycle to TPOD=ATRK, I do nothing as I can not slew anyways. Step 3: Cycle to TPOD=PTRK, again, no slew, but I don't even want to slew. Step 4: Cycle to TPOD=OPR. Now slewing should work again, right? But it does not. (Step 5: VVSLV + UNDESIGNATE --> continue at Step 1)

If no target is designated and TPOD is in snow-plough mode, the diamond can be slewn if TPOD=OPR. But when cycling though ATRK and PTRK back to OPR, slewing is no longer possible. A simple UNDESIGNATE, i.e. to get to snow-plough, does not work either. Only double-press UNDESIGNATE to get to VVSLV and once more 2xUNDESIGNATE to get back to snow-plough works and restores the slew functionality. edit: Important here is, that no TDC depress designation has happened. If a designated target exists or was set during the process, then everything works as intendet (slewing + undesignate)

When slewing the TPOD while the JDAM TOO mission format display is active, the coordinates are constantly transferred and updated at the JDAM page. I would expect that the update only is performed, if TDC is depressed in order to deliberately designate a target. I can, for example, slew offset cursor of the TPOD (ATRK/PTRK) around and the coordinates are only transferred if TDC is depressed. That makes sense to me: I could step through several JDAMs and set each target coordinate by TDC depress with the offset cursor while the TPOD is only looking in the general target area. This should work also with the normal OPR target diamond, right? But there is now always the risk that I mess up the coordinates by accidentally slewing the TPOD. Thoughts? Is this a bug or is my thinking wrong here? tl;dr JDAM coordinate transfer should ONLY happen on TDC depress/release, not by just looking around with the TPOD.

You won DCS - congrats!

As I said, I am no expert in regards to 3d, but I assume that the terrain consists of a lot of binary data that has to match many other parts of what makes a map, like the buildings, streets, etc. You can't just modify one without having to adjust the other. All that makes it necessary to use specialized tools that take care of that to some degree. Those tools are probably quite complex in itself and if ED would release them to the general public, they would also have to be "fool proof". Probably ED don't want to support those, besides DCS World and their modules, as that would be a "Fass ohne Boden" (a barrel without bottom) as we say in german. For other parts of DCS World uses the LUA scripting language, which can be changes with any text editor. And texture files are usually also quite easily editable. I'd assume, that is the reason why terrain is unmoddable atm - to much binary data and complex interdependencies. I am sure, they did not make it that way to be difficult - it just IS difficult.

Track playback: two hornets start from cvn-71 Track opened in ME: 1 a/c group + supercarrier What I find a tad bit weired: the aircraft spawn at different positions when comparing track replay and flying the misson from ME.

From a modding and developers POV: the necessary tools to work with the terrain data are only available for registered 3rd party developers. There are texture mods available for different maps, but afaik we can't modify the 3d data at all. I have no clue about 3d modelling and such stuff, but DCS terrain seems to be quite a complicated beast. Allone due to the fact that there are several versions of the "terrain engine" that run the different maps (i.e. each map seems to have it's own special features and particularities which have to be known and properly taken into account)

If that was the case, the Mav should not have gotten a lock at all in the first place.

The whole idea of LGBs is that they hit where the laser is aimed at. The variable part is the bomb trajectory to get to that point. If lased too late, the bomb might have not enough time to correct it's trajectory if wind has blown it off course. So you can either lase earlier, but you risk that the bomb loses too much energy to be able to fly it's straight line towards the target and falls short or gets blown off course as well. Or you can try to compensate the wind effects by aiming the ballistic trajectory up-wind so that in the end the bomb is right on target and has only to do minor corrections for hitting the laser spot. You would probably do this by using CCIP and aim manually up-wind. But the laser should always stay on the intended target. If you misuse the laser for the wind correction, you only add yet another factor of uncertainity. Why lase at all in this case? Just aim it manually, if you don't even intent to hit the laser spot at all?

True, but at least it is a hint that there is(was?) an other helo in production, besides the Hind. The Cobra was, at that time, also a 3rd party project (Belsimtek) if anything. So, Apache could be still a possibility as neither of the mentioned helos was a genuine ED project at that time.

We were? :huh:

which is difficult because the sensor select switch first switches to area track and only at the second activation it switches to point track. During that time - however short it is - the reticle can not be moved. (I am starting to understand and appreciate the comments on how awesome it was that the pilot got a TPOD lock on that fast moving UFO - you know, the video that was recently unclassified by the US)

I had an odd experience last summer. I was driving in my car in the rural area I live in. You know, farmland, meadows and pastures everywhere only interrupted by an occassional farm building or small patches of forrest, bushes and the like. In the distance was one of those "lawn sprinkler" irrigating some patch of farm land - you know, those large sprinklers, commercial size, that have can cover a radius of perhaps 50? meters. From the distance and the corner of my eye the white jet of water, spray and spume totally looked like a SAM plume. I guarantee you, it is nerve wracking if you see a SAM launch nearby, the missile heading towards you ... IF YOU SIT IN YOUR CAR, MINDING YOUR OWN BUSINESS ... lol, had to do a double take in before I would have attempted to notch it (and ending up in the ditch). Maybe I am exaggerate a little bit, but certainly my heart skipped a beat in that moment.

How do you know the ratio of internally found/fixed bugs and open beta bugs?

Will we able to call in artillery strikes? And how will this feature be integrated into the DCS environment? I.e. will we trigger existing artillery assets that were placed by the mission designer or would the module itself "fake" it (generating explosiions at the target area)?

There are quite a few tutorial vids covering all kinds of aspects of the mission editor, but what I meant was more like a really, REALLY basic introduction to the ME. So that the audience you have in mind would have only to follow a hand full of steps to get their test mission set up. Really just - open mission editor - select aircraft, place aircraft, configure loadout - select target, place target - press fly button Once someone has done that 2-3 times, have overcome the "intimidation of the complexity ME", they probably start to experiment with more features of the ME on their own.