WHOGX5

I think the question was more in regard to if a nation were to disconnect their entire internet from the outside world, whether there is any way to keep using the modules you've paid for if you live in that nation?

Yeah. I did a test a while back where I dropped 4 JSOWs abreast of eachother at the exact same locations each time against a square grid of enemy units, spaced 50ft apart in each direction. Against trucks I got an >90% probability in kill in quite a large area (about 500x250ft). Against SA-2 launchers, which you'd figure would be as vulnerable as trucks, the probability of kill was <20%. So yeah, I think this would have to be individually tested for each unit because there seems to be no logic behind it.

The reason server tracks work is that tracks are only bugged for yourself. This means that if you fly online for example, your own track will show everyone correctly except yourself. This also means that in an F-14 the pilots track file will invariably be bugged while a RIO in the same aircraft will get a perfect track, even of "himself".

To be honest, I don't remember which thread it was in since it was several months ago (if not years) last time I read anything about it. There have been several threads regarding G-LOC and G-Tolerance but they're all probably locked at this point, buried in several hundreds of newer threads. But the best thing would probably be if ED could just respond to this thread or include it in the planned systems post.

The autopilot will either maintain current altitude or maintain current attitude. There is no way to set a specific altitude or to follow steerpoint altitudes. Also, the F-16CM-50 has PGCAS which is an advisory system which will warn a pilot whenever he's about to fly into terrain (but not make the aircraft pull up) based on information from stored digital terrain data in the aircraft. The Block 50 can do automatic pull up using the LANTIRN navigation pod but ED has said they're not modelling it. Also, later blocks have GCAS which performs automatic pull ups which expectedly will not be modelled either. Actually, last I heard from ED we're not even getting PGCAS even though it's a M3 feature IIRC and we're getting an M4.3+, so you're just gonna have to keep your eyes open.

As mentioned above, they can be used for pre-computed pop-up or high altitude bomb delivery. There is a software called WeaponsDeliveryPlanner which was originally made for that sim whose name shall not be uttered in this section, but it can be used just as well to calculate OA1, OA2, VRP and PUP for these bomb delivery modes in the DCS F-16. Also, since we already have INS drift (and hopefully the FIX page soon enough) any scenario in DCS that takes place before 1994 doesn't have GPS support, these will be very useful if simulating a WWIII situation where GPS satellites would be destroyed or jammed, or if simply if simulating an old school scenario pretending you're in an older F-16 than you actually are.

It's not implemented yet, but last I heard from ED it will be implemented at some point.

Yes, I completely agree. I still think though that the F-16 would be the optimal platform for the initial implementation since it's an ED module, plus that it's L16 integration is currently being worked on by the F-16 dev team. But yes, this is definitely something that should be implemented as an API so that it can be expanded to other relevant modules as well.

Not only weather but also nighttime conditions in addition to their already inhuman accuracy. You can fly during new moon when it's absolutely pitch black outside and any type of unguided gun, whether emplaced or on a vehicle, will have no problem tracking you visually and firing with laser like accuracy from miles away.

I never said that the AMPCD in Legacy Hornets was unable of doing the same, I don't know if it did IRL. I said that the font color in those Rhino videos is probably pilot selectable and not fixed to one color, as is the case for the DCS Harrier. It could be a software feature that was introduced later than 2003 or different LCD panels using the same button interface. I don't know enough to say. Yeah, I can't speak for the F/A-18C but in the F-16C you can set the colour freely for pretty much anything you want in the data cartridge, even the individual colour of different types of symbology on the FCR and HSD. So it's not completely unreasonable that the F/A-18C would have something similar for its colour displays.

You have to add the STPT's in between, but all you have to do is add the new steerponts and give each steerpoint a coordinate of N 00 00.000 E 000 00.000 and it'll be blanked in the aircraft (it disconnects the lines on the HSD). My community uses blanking so we can mark airspaces and FLOTs in addition to our flight plans without everything being connected on the HSD.

First of all, the strive for more REDFOR units does not lead to a logical conclusion of the cold war turning hot in Germany. REDFOR units are used all over the world and could be realistically used in the Caucasus, Syria, Persian Gulf; even NTTR could realistically use it as the yanks got a hold of some of those air frames. And this is just mentioning our current theatres. Second of all, you can have a server with a 40 core CPU and 384 GB of RAM but that doesn't change anything. You still have to be able to edit and test the missions in the ME and units in DCS are real performance hogs. Just having a couple of artillery pieces or infantry units shooting at each other will cause a noticeable performance drop. And when it comes to Germany, even though it'd be a cool map, I think a lot of people in DCS would prefer more varied and larger/less densely populated maps rather than the opposite. The reason Syria is such a great map is that it covers multiple nations and is so big and covers so many airfields and cities in a layout with such a varied geography that you can twist and turn it every which a way and come up with hundreds of scenarios without it ever becoming stale. A small map of Germany would be a bit of a one trick pony compared to some of the alternatives, like a Balkan map with some lo-fi slices of the east coast of Italy, or the Korean peninsula with some lo-fi slices of Liaodong & Shandong peninsulas as well as the Fukuoka prefecture. Maybe even a lo-fi Vladivostok as well if you really wanna go bananas but that really is stretching it.

Yes, and an important thing to note is that it follows FCR LOS. So even if you're within gimbal limits, if you turn your head quicker than the radar can rotate, then the ellipse will show the true direction the FCR is pointing in and lag behind until it catches up to your head movements. This is also clearly apparent in the video I linked above.

With the F-16 development focusing on adding LINK 16 functionalty and with the recent release of the TAF mode with LotAtc integration for the Mirage 2000C, I think this is the right time for this request. As a short background for those who are unaware, the F-16 (and pretty much every other L16 aircraft as well) has the ability to receive mission assignments over LINK 16 from C2 assets much like the M-2000C's TAF works, only a little more modern. It allows a C2 asset to send a plethora of mission taskings via L16 containing everything from A-A targets to attack or protect, A-G targeting showing areas to provide SEAD or CAS in to where and when to refuel or land. Each of these messages have to be accepted or denied by the receiving aircraft who can then respond with whether the tasking has been completed or not. I'll link a video below of the M-2000C's TAF in DCS so you'll get an idea of what it looks like, it's quite similar though a bit more basic. Implementing this functionality would greatly benefit not only F-16 pilots but the entire DCS community. Firstly it would benefit both those who mainly fly singleplayer as well as those who fly in multiplayer. As seen in the M-2000C, these messages could be sent both by AI units and players providing GCI/AWACS support. With an official implementation by ED this could also be controllable by mission creators allowing these messages to be sent according to the mission designers intent. Having an automated AI system as well would allow this to be used in every single mission irregardless of whether the mission designer told it what to do or whether or not you have another human providing GCI/AWACS for you. Secondly, it would greatly improve the GCI/AWACS experience in DCS multiplayer as well as remove any language barriers. It would allow whoever is doing C2 to send a so called Handoff message over L16 containing the appropriate mission channel and radio frequency for the recipient to connect to rather than spamming this into text chat. Once connected, the GCI/AWACS can send mission assignments to players who don't even speak the same language as them and still be able to cooperate and organize without any issues. The TAF system for the M-2000C has already been implemented into LotAtc allowing humans to send these messages to players. Giving the same functionality to ED's L16 network would lay the groundwork for a future native DCS implementation of more rigurous GCI and AWACS integration. And lastly, if this was developed as a framework, these mission assignments could be integrated into all current and future L16 platforms in DCS as well as platforms using other message standards that are incompatible with L16 like the M-2000C, MiG-23, MiG-29, JF-17, etc. who all support the same type of messages, though some in a much simpler form than others. Here is the video showing of the current TAF implementation by Razbam in singleplayer:

I wish I could mention other companies who do customer interaction 100% correctly but I don't want to get slapped with a warning. Suffice to say, there's an absolutely exemplary game company that is completely transparent with their progress in different areas of the development of their product and they can delay stuff for years without riling up the community at all. The reason for this is the clear communication and transparency. "This feature will not arrive as soon as we'd hoped because of our team running into issue X and Y and now we have to do A and B to try and solve this issue". It doesn't have to be harder than that. "Team E is still working on X and Y while Team F is just finishing up A and B". Then you give regular updates on the progress of different systems so the customers actually know why some system hasn't arrived for 24 months, but they can at least see what the reason is, whether it's difficult to implement, low priority, on the shelf, etc. The reason people are loosing their excreta in this subforum is because someone starts a thread wondering when some system will arrive after 24+ months of early access. That thread is going to be ignored by ED until it turns into an absolute flame war and then the mods show up and simply say "Yes, it's coming later in development, it's early access" and that's all you get. Two weeks or two more years; who knows? Who knows if anyone's even working on it? It's not good customer interaction and I'd say it's the main reason this subforum is so volatile.

I don't have access to my documentation currently, but the ellipse that's displayed in ACM mode isn't supposed to just be statically attached to the JHMCS crosshair like it is currently in DCS. Rather, in real life, it shows the actual direction that the radar beam is pointing in. Therefore, when your radar reaches its gimbal limits, the ellipse won't be able to move any further in the direction your looking. The video below (depicting HAF 52+ using the same JHMCS as USAF F-16C's, posted in 2007) doesn't show the radar reaching its gimbal limit, but you can clearly see how the ellipse isn't just statically attached to the JHMCS crosshair but rather shows the actual true direction and movement of the radar beam.

It's a bug and it's been that way for ages. There is nothing you can do to get around it. When it'll get fixed, only ED knows...

Nope, DELTA TOS has not been implemented yet. It's somewhere in the pipeline but when we'll actually get it in DCS, nobody knows.

I don't know about you but I can't think of a single aircraft where timed HOTAS actions trigger on release. I have no idea how ED managed to interpret it this way and it doesn't help that they're refusing to back up their claims in any way or even just respond to the thread. ¯\_(ツ)_/¯

In the picture you posted you're not actually in the ideal position. The left director light is showing you as below centre. It's quite hard to tell, but it's showing a green up-arrow rather than the horizontal line. You can also compare how long the director strips look in your picture compared to the photo from the manual and you'll see that the director strips in your picture are longer, hence you are too low.

On the contrary I think he would definitely remember if actions triggered on release as it's such a big difference from every other US airframe. This would also mean that from the first F-16C Block 25 in 1984 up until the F-16C Block 50 in 2007 this easily rectifiable deficiency in the F-16's HOTAS integration would have either not been reported by pilots or pilots requests would have been willfully ignored for over two decades? Both of these scenarios are extremely unlikely considering how easily fixed an issue like this would be. As previously mentioned though, it would be best if ED could say what they base this implementation on. They must have a reason to make the F-16's HOTAS button presses different from every other airframe in DCS, right? It's strange that they haven't removed the "correct-as-is" tag for an issue that was marked as "reported" over two years ago, nor have they given any form of response to this thread.

First of all, I want to recommend this software called DCS-DTC which will automatically input various settings that would be set by the DTC if we had one natively, stuff like radio presets, MFD setup, countermeasure programs, etc. What I suggest you do is create one cartridge for each server that you fly on regularly and then you can simply choose to load the comms ladder for whichever server you decide to join. It doesn't break integrity check or anything so it can be used on all servers. Regarding the paper the answer is yes, it's on the flip up cover on the backup UHF radio. I don't know if it updates if you change the presets in-game, but I know for a fact that it displays the frequencies that were set for COM 1 in the mission editor.

The beauty of radio presets is that you don't need to know what the actual frequency is. IRL they use what's called a Comms Ladder where each preset channel corresponds to a specific agency. Here's an example of how it was setup in the sim that shalt not be mentioned by name: U1: Base Ops U2: Departure, Ground U3: Departure, Tower U4: Departure, Approach/Departure U5: AWACS, Check-in U6: AWACS, Tactical Frequency U7: Arrival, Approach/Departure U8: Arrival, Tower U9: Arrival, Ground U10: Alternate, Approach/Departure U11: Alternate, Tower U12: Alternate, Ground U13: Tanker U14: Guard U15: Flight 1 U16: Flight 2 U17: Flight 3 U18: Flight 4 U19: Flight 5 U20: OPEN So with a Comms Ladder like this you always know that Channel 6 is your Tac Freq and channel 15 is the intra-flight for the first flight in the package. All you need to worry about is making sure that the correct frequencies are loaded onto the DTC before mission start. If you need to know what the actual frequency of the preset is there are only two ways: 1. If the radio frequencies for COM 1 are set in the mission editor the frequencies for all the UHF presets will appear on the paper that is attached to the backup UHF radio. 2. Go into COM 1 and cycle through to the desired preset channel using the ICP controls.

I haven't even had a look in the RL manuals but I'm highly doubtful that it'd say "activate on release" or whatever since it's so incredibly obvious that it's not the case. Say that you want to switch from RWS to TWS by pressing TMS Long for >.5 seconds or whatever it is, there is literally no reason to depress it for >.51 seconds since there is no additional functionality to be had. It's not like dragging a folder to a new location on Windows where you can change your mind and cancel the move. Once it's depressed for >.5 seconds you're going to TWS whether you want it or not. Requiring the TMS Long to trigger on release rather than elapsed time goes against every fibre of user friendliness and only makes the process more ineffective by adding ambiguity to it, encouraging pilots to depress the TMS switch well over .5 seconds to ensure that they don't perform some other action they didn't intend. But ED has access to SMEs, right? Should be quite a simple thing to verify. It would also be nice if ED could give a reason as to why it's marked "correct-as-is" so we know what they're basing their decision on and, in turn, know what we need to disprove.

I don't know why this is marked as "correct-as-is" when it obviously isn't. I reported this same issue over 2 years ago and it's been marked as reported ever since. AFAIK this applies, like you mentioned, to every HOTAS Long action except HMD blanking. @BIGNEWY, is there any reason this is set as "correct-as-is"?