Flagrum

Probably roughly related: https://forums.eagle.ru/showthread.php?t=281179

With a LG82 selected, the SMS format shows the CODE function at the left bottom push button which allows you to set the PRF code for the weapon via the UFC. Since last patch, this push button function is also active at the SMS main page (i.e. without any LG82 selected). Selecting different weapons shows it's respectife SMS format correctly (i.e. without CODE push button). But it gets somewhat problematic, if you just select GUN. Then the very same push button is assigned one of the two possible ammo types - while still also being assigned the CODE function. The displayed text is mixed up / overlayed over each other. The CODE function seems to have priority, though. Whenever it is selected, you can even set the PFRF code for the LGBs, without having them selected. edit: SMS main page CODE.trk

No, you pre-ordered it.

Try hitting a moving target with it.

It would probably collapse into a relativistic singularity ... taking the whole universe with it. I.e. it is not possible - or would require "different" laws of physics/mathematics/etc. than we have in our world. If you want to make something look bigger than it is, you have to take that part of your picture (i.e. what you currently see) and stretch it in all directions. And that is effectively changing your FoV. The only other way is to get closer to the object you want to see bigger. But what you see then is not really "bigger than it is", because it IS that big then.

Could Triggered Actions in the Mission Editor do the trick? Afaik there is an Action that can set cockpit args ...?

So, ED said, they would focus on bug fixing. And you heared "we are focusing on F-16 bug fixing". Did I get that right?

I bought the F-16 as well and I am, as well, not happy with the state it's in. But what I don't get is, why ppl are now angry that this patch doesn't help that much in this regard. It was clear that ED would focus on bug fixing - supposedly, and as it seems, in actuality - all across DCS:W + modules. That the F-16 would not get an extra treatment here was clear, imo. Perhaps you should have voiced your concerns in regards to this update earlier, when ED announced it. Something like "Uh, no, please no bug fixing! Just some attention for the F-16!". Maybe you would have found supporters and would have made ED to reconsider that decision .......

The situation with the F-16 is clearly far from optimal, but seriously, what did you expect to happen with this update? That the F-16 will be brought up to at least FA-18 level? I mean, when ED clearly stated that they were focussing - and rightly so, especially after the last update - on BUG FIXING. What the F did you guys expect would happen!?

I read somewhere something about PDU / Pilot Display Unit (https://forums.eagle.ru/showthread.php?p=4348166#post4348166). Is that the same as ODA?

No, the pylon stores nothing. But the SMS can only address pylons, not individual weapons on the pylon(+BRU-55). So you tell both bombs that TOO1 is coord-x and both bombs that TOO2 is coord-y. Then you drop the first bomb on that pylon using TOO1 and the second bomb using TOO2. It is all a bit weired and very unintuitive and that makes me believe that this behaviour is actually not 100% like in RL. Either we need a different software version of the SMS that can address individual bombs on a BRU-55 - like Swiftwin said - or we perhaps should not be using the BRU-55 as it is not completely compatible with our current SMS software version ...

Have you set the bomb fuzes correctly?

I never got it to work reliably, but I tried it now once more after reading this thread (haven't flown the sabre for ... well, years now). At first, it was like it always was: unreliable. In only 1-2 of 10 run-ins I was able to get an auto release. Then I sat down and started thinking ... and I think, "I got it" now. I think, the key factor here are the sight gyros. If I banked over to get my nose down at the target, it usually did not work. But if you do it exactly how it is worded in the manual, push the stick forward to get into a dive, it works much better. My theory is now, that smoothnes is of utmost importance. If you jink the stick, roll the aircraft around and do all kind of "extreme" maneuvers, the gyros get upset. Maybe the system already senses the "below 1 G" criteria already while you are still trying to get your nose down and haven't yet consented to the weapon release. Or maybe the gyros just get out of whack in general. If I now push the nose geeeeeeently over, don't have to jink left and right to get my pipper placed correctly, then I usually get a release - and I get the bombs even quite close to my aim point! Perhaps even banking over to get into a dive might work - I would need to experiment more here. But if it works, I would assume that the whole maneuver needs to be very smooth. And probably will require a few seconds to keep the pipper steady to allow the gyros to "re-align"(?). Just my 2 ct - maybe something to ponder about.

is this issue being revisited? I believe the [no bug] is not valid. thanks!

bump - track is provided now, could we get an updated [tag] that this is being investigated/reported, please?

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 ;)