Rongor

Can confirm this happens frequently. TMS aft on WPN SOI page is the only cure I came about.

This. And I reported it in this forum, so ED can save us the errand by adjusting the default config or tell us why they choose to leave it that way and eventually drop some lines about this in the manual.

It's nice you guys can explain how to adapt to the situation. If you had paid attention you would have seen I am not looking for workarounds. I have no idea how many time you guys waste to cancel a thread. The current default situation of the MFD configuration in both Override modes is a problem. It's possible ED simply didn't implement it yet in a reasonable way. Probably they didn't made their minds up what should still be selectable in the right MFD by default. We just don't know, until we can read it up in the manual. What we do know is that you guys don't care for ED to review this. Of course, ED keeping it as it is now would enable you to go on lecturing people how smart you can work around an issue like this. I understand that now.

As explained in this thread, wind currently can affect availability of ILS. This also leads to bug reports addressing specific maps. Yet it seems to be a more general problem instead. In many occasions, ILS is not available, as if there was no ILS at the airfield at all. Please fix and advise me how to deliver additional data, if needed.

As of today, ILS of Hatay still doesn't work. No indications on the needles. No morse identification.

The way you depict it here is totally misleading and is not suited for people actually intending to understand how TACAN works. TACAN doesn't operate on VHF. You can't receive a TACAN by converting its channel to a VHF frequency. This is a common misconception from this misinterpreted table. TACAN, DMS and transponders share standardized 2x126 channels in the frequency band of 960 - 1215 MHz. All these are basically some sort of secondary radar. It is a system of clients polling a serving station. The civilian DME is compatible to the ranging segment of the military TACAN and therefore uses the same freq range, stepping and (internally) channel numbering. To not have the civilian operator needing to enter DME channels, DME is usually incorporated into the VOR receivers, which work in the range of 108-118 MHz. When a civilian DME is constructed, often co-located to a VOR, the list you posted is the VOR frequency of a VOR which operates a DME on that respective TACAN-compatible channel. You are basically tuning your civilian DME receiver by tuning your VOR receiver to a VOR, which under the hood always looks for a DME in the list of DME channels corresponding to each VOR frequency. You can use that table, convert the TACAN channel to a VOR frequency which you can enter in your VOR receiver to then recveive the TACAN's DME segment. That is all. You can't do it backwards. A VOR frequency or even the presence of DME has no say if there is a TACAN. The fact that you have a DME channel on a map doesn't tell you if there is a TACAN present. Also a VOR frequency doesn't tell us, if there is a TACAN. In some cases TACANs are co-located to VORs. This would be visbile on a map by a special symbol, called a VORTAC. VORTACs enable civilian aviation to make use of the co-located TACAN's DME, so the operator of the VOR ground station at the same location doesn't have to errect a DME there. If the Israelis don't want the TACAN to be published (be it as DME or as a VORTAC), the map symbol probably wouldn't give this away and therefore the published VOR frequency gives us no idea if there is a TACAN at all. So why would the Israelis or anybody want to "hide" that TACAN? It's most likely not for security reasons but to keep the system running. TACAN, just like the civilian DME can only serve a maximum number of clients. If the station is saturated by polling clients, it can't handle additional queries. So the idea in a regularly busy airspace would be to keep the TACAN's serving capacity as high as possible instead of risking military flights not being able to use it because there are already 120 civilian flights using the DME.

After switching to dogfight override, you used OSBs to switch right MFD pages which is necessary because DMS doesn't do the job anymore. You are basically demonstrating what I described multiple times now. Well thanks so much for this vague comment. Again, it's known we can put them back. I am questioning the fact that selecting an override mode by default blanks out all other page formats, so that DMS doesn't affect that MFD anymore. The manual mentions that MFD getting switched to the respective SMS page. No where it is stated that other pages OSBs get blanked and for what purpose the configuration of the SMS page includes blanking out the other pages (so you can't use DMS on this MFD anymore as single and only effect).

probably this happened to me too then. Right after designating system targets, the Acquisition cursor likely rested over it, effectively having a cursor target. So this legitimately caused antenna control to stop. Solved for now. Thanks

I can confirm this. It's even in the manual. You can read it up there. DMS doesn't work on the non-FCR MFD while in any of the two override modes. This will regularly be the right MFD and in this case, DMS right. DMSright.trk

It's nice that you can setup your MFDs for the override modes. Yet this has nothing to do with the problem I explained. The problem's are: - DMS is not working for the non-FCR MFD while in Override - when switching to HSD using the OSBs on the non-FCR MFD while in Override, going back to SMS doesn't display INV under OSB 3, although pressing the OSB still opens the INV page. These may be bugs and deserve attention.

System tracks are not bugged tracks. The FCR isn't providing missile launch parameters at this point so there is no need to hand off antenna controls to the FCR. Designating a system target does nothing to the radar, it's merely a function the pilot can use to sort targets on his B-scope. The TWS is literally made for maintaining scanning while tracking, so if the FCR starts do take over after designating system targets, something might be wrong.

Just noticed that while in TWS mode, the antenna elevation can't be adjusted anymore as long as there is at least one target designated as system target or higher. Returning all contacts to track targets returns antenna elevation control. IN RWS SAM/DTT modes, antenna elevation control is unimpaired. I suspect bugs? Would expect antenna elevation fixed in STT. If it's correct to have it fixed for system tracks, probably should be fixed for SAM/DTT too?

Tried that, you are right. It would be nice to see that corrected and added in the manual then. The reader needs to know, that not acknowledging the LATLON will still countdown to 10 and yet this mustn't be interpreted as "well done alignment" and that the SALT in fact isn't edited by ICP input...

The line below the pic on page 144 claims: "In DTT, pressing TMS left will swap the primary and secondary targets". This is obviously an error. TMS right is swapping targets in DTT.

I can't find a comment in the manual confirming this as correct. While in one of the two Override modes, DMS right (assuming we have the FCR on the left MFD) is ignored, preventing switching between SMS and the HSD. DMS up, left and down are working normally. Switching pages on the non-FCR-MFD is still possible by navigating through the respective OSBs, yet naturally you won't be in the mood to hit some OSB when in a dogfight (override-situation), as we have HOTAS for stuff like this. If you switch to HSD by OSB, navigating back to SMS won't show the INV as an option in the stores main page. You still can select it via OSB 4.

Currently it can't be edited, regardless of within or outside aligning. Also opposite to the manual, the values don't have to be entered/acknowledged, regardless if STOR HDG or NORM alignment. Even Wags doesn't do it in the Cold start training mission. This is what the manual says: If anybody managed to edit the SALT, please tell us how. Also if you bother to ENTR all the three data lines in the DED, you can simply stop doing so. Alignment will complete to 10 just normal.

This is exactly what I wrote in point 2. It is, PNEU is the initial mode when starting up the F-16. Following the Cold start checklist beginning on page 103, there is no item telling me to switch it to ELEC. in ELEC mode, the values match, but still it's not possible to edit the DED SALT value by the ICP keypad as demanded on page 79

During NORM INS alignment on the ground, we have to verify LAT LON and the SALT, acknowledging present values for these shown in the DED. If necessary, we can edit the numbers with the ICP. 1. I am unable to edit the SALT. Whenever I enter numbers on the ICP, pressing ENTR simply returns the SALT value to the number shown before in the DED. Therefore I can only acknowledge but not edit the SALT number. 2. SALT value seems to be affected by the Altimeter setting. Turning the QNH knob on your Altimeter not only adjusts the Altimeter readout but also the SALT value in the DED. 3. SALT number is shown higher than the Altimeter. There is a mismatch of around 50-60 ft. You can't bring them both to the same value, ideally this would be the current ground elevations as shown in the F10 map All three described items: Why? and: Bug? 4. SALT value is showing correctly only after completing alignment by turning the INS knob to NAV.

I don't think you got what I was saying. Hind was given into early access in June. Now after several updates, we have it almost in release state, yet the manual didn't receive updates, so sadly despite all the additional implementations we still can read up how most of the stuff is working.

I mapped switching the Yaw channel on and off onto my HOTAS for this. To the question regarding realism... we don't know. After half a year, the Hind sadly is still basically at release state and the meager documentation given along doesn't explain most of stuff.

Well at least now you save 3 button positions

Oh, then it actually could have a use on a HOTAS. Hope you get these additional bindings implemented then.

is what i'd wish for any update for the Blackshark. It's very shallow right now and also unrealistic. Battery doesn't seem to drain, you can fly without any hydraulics left and you can safely RTB or even continuing attacking the enemy with the shark's behind being chopped off behind your seat (no tail, actually the most frequent visible damage I get)

interesting point. Something to be tested.

Multi-engined helicopters are often equipped with different sizes of feeder tanks. This is a kind of built-in life insurance for the most careless of pilots, who failed to manage their fuel correctly and eventually are even up to ignore the fuel warnings. The idea is to have the crew land within a specific amount of minutes after the low fuel warning (as will be defined in the checklist/AOM). If the crew still carries on, one tank will empty before the other, so the shutting down of one engine will be your last and final warning. The first engine shutting down would normally be the left engine (number 1) with the Blackshark, as it is fed from the front fuel tank, which has a capacity of 705 kg. The rear tank bears up to 745 kg, so you will have around 40 kg left on the right engine (number2) to bring the helo to an instant but safe landing. If the rear tank is empty first while the front is not, something has gone wrong. The applicable emergency action would be to open the crossfeed valve to keep both engines supplied from the front tank and keep an eye on the fuel meter to verify front tank fuel level isn't suddenly dropping as well. Consumption from front tank will increase now of course.