Ahmed

As it didn't get any feedback on the wishlist and I'd call it more of a inaccuracy needing fixing than a feature request, I post it here. The LSO view position on the right console is inacurrate for the controlling LSO (and even backup LSO). In the in-game position the wind deflector covers the view of the wires so that it is impossible to tell if someone trapped or boltered until you see them going off the deck. The fact that the view position cannot be changed more than roughly a meter unless in VR and any attempt of LUA editing disables the module makes matters worse. References for realistic LSO view position:

Search youtube for "f-16 rudder test" for an example HUD video of how an F-16 reacts to rudder deflection (didn't embed the video due to some footage of another sim at the end of it)

Same perception here. The rudder seems to have very little effect aside from at very low speeds / high aoa. It also especially exhibits very little roll coupling (with no visible FCS counter action in the FCS page). Airliners do indeed have a rudder limiter to avoid overstress. However a tiny bit of rudder does develop a significant yaw and roll rate on them at any speed, as Stearmandriver says.

The cockpit is pressurised following a certain schedule. Flight altitudes in excess of ~30.000ft result in cabin altitudes in excess of 10.000 ft according to NFM-000. That said, the cabin altitudes listed there are not high enough as to cause a rapid onset of hypoxia and would normally require prolonged exposure to cause any impairing hypoxia (>30 minutes?) Is canopy damage simulated and will it cause a cockpit decompression and hypoxia?

While testing pitching deck mechanics I noticed that the PLAT camera seems to be stabilized with the horizon (deck moves, crosshairs don't), instead of pitching with the deck as it should (horizontal crosshair moving). See attached screenshots (vs real) and track in case it helps. plat.trk

You can pan it alright with the mouse, so that issue may be different. My point is about the position of the camera itself being too far starboard from where the controlling and backup LSOs would be standing (it is even difficult to see if someone trapped or boltered from the current position...), and not being able to move the camera through any kind of in-game means or even lua edit (the later one due to the protection system apparently). Even using trackir/opentrack to move the camera wont get you far as the 6dof limits are within 50cm of the original position, leaving VR the only option. Being able to move the camera to the correct position in-game should be a must for the SC

Some kind of sea state control on the weather parameters would definitely help here

wow

yep, great idea

Lethality bands and HUD symbology are the main that come to my mind. It's a shame that the Hornet doesn't have as much public documents available as the Viper.

We've been there already with other systems such as the RWR (for which there were plenty of threads with lots of undeniable photo/video evidence of how it should work). And I'm afraid that unless public documentation exists, we'll have to get used to what we have now. This could possibly be due to ED wanting to stay well clear of any doubt of ITAR complicance and/or their military contracts. What I wonder is how the F-16's HTS is going to turn up.

Hi, I couldn't find any way of moving the position of the LSO camera. This together with the default position being far away from where the controlling LSO and even the backup would normally stand, is quite an inconvenience. Any chance of adding some way to move the camera within the LSO platform area?

Totally off-topic but thanks Javier for all the hours of entertainment I spent thanks to your boats!

Hi all, The command command heading steering marker in the HUD (NATOPS Figure 24-12) in the current DCS Hornet is showing steering for direct track to the waypoint without any wind correction. According to the explanation in 24.2.9.1, the steering should be corrected for wind drift. Regards,

The thing is also than in pc simulators we are to used as having perfect RWRs with perfect libraries. They detect everything, there are never ambiguities. Even they can discern between a missile launch on your wingman flying fingertip and you (this last one is a shame as it was working more or less realistically previously in the DCS Hornet but it got changed' a few months ago).

I'm afraid that stuff about the threat libraries (and generally most of the EW related stuff) is one of those highly classified matters...

Hi BuzyBee, thanks for the offer. I considered that approach of having a LUA add-on but this would be a client-side solution, right? Nothing would impede someone from not using it an accessing the units that I'm trying to hide. It would need a serverside solution

AAR is just formation flying with the tanker. That said, my main advise would be to look past the HUD. "Flying with the HUD" seems to be a common mistake in flight simming, especially when staring at a 2D screen. Ignore the HUD, ignore the speed, etc, just look out at your lead (or tanker). Practice enough to develop the feel of how your relative motion shows in the 2D screen and it will become easier with time. Also learn the visual references of the correct position. A too high FOV setting may make all this difficult so find a sweetspot. Somebody mentioned trimming nose down a little bit. I tend to do this in DCS as well for AAR too (just a tiny bit of trim down) as otherwise I become unstable, but I don't know if this is RL advice transferred to the sim or just cheap PC hardware. RL generally defaults to a trimmed hands-off aircraft. Definitely aim for small and controlled inputs the closer you are. If you are using VR then it should all be simpler due to having depth perception. In the end formation flying is like driving parallel to another car on the highway, just moving in an extra 3rd dimension.

Thanks, I have been using a similar solution. But this is exactly what I meant with half-solutions. Having only one client per group has side-effects on things like not showing wingmen as such on the F18 SA page or callsign issues. The issue should be fixed at its root by ED without having to take these kind of compromises of losing core system functionalities (or adding a submenu for each client on the group that is the other messy workaround)

Hello, I posted this on Discord but never got an answer so lets try here. I assume this has already been requested before, but just in case. The scripting functions addCommand addCommandForCoalition and addCommandForGroup have no way of identifying what player used the command in MP. The most elegant solution would be for the callback function to receive a second parameter with the player or unit that used the command and that's what I'd like to request. At the moment there is no workaround to identify the player other than e xtremely messy half-solutions. Thanks,

good find

Hi Vyrtuoz, I have a suggestion for a feature. We usually setup 'persistent' missions in our group that include units that are hidden from the briefing/ME map (such as, for example, mobile SAM sites). The issue is that, when we use TacView for debriefing, we will automatically gain intel on all of these. Would it be possible to have a TacView option to filter out these units from the acmi? I understand that in some contexts it is interesting to have them shown (like, for example, if engaged) but maybe you can come with an idea. Even something like LotATC's option of ignoring a unit when the name contains a certain string would give some flexibility.

The RWR should indeed discern between lethal and non lethal threats but this got lost in translation during development of the Hornet. Regarding the lock warnings, the RWR should not only issue lock warnings when an aircraft nearby* is locked but also launch warnings. The RWR in dcs used to do this but it was changed several months ago and now it doesn't have them even when flying fingertip with the target. Hopefully all this will be fixed one day but as the publicly available documentation is rather limited it is unlikely.

Well.. the RAZBAM one.... the real AdlA M-2000C does not have it even if it has the switches. Just to clarify.

I know, I didn't say that... or I didn't intend to mean that at least. I just meant that by overusing the "everything is subject to change" excuse, that example of completely ceasing development of an EA product could be an (extreme) situation that could also be justified by using that reasoning. I think that both ED and its customers would benefit from having a public well structured set of guidelines of how an EA product is going to progress throughout EA with some guarantees. As an example of what I mean: I'm pretty sure that noone expected the Viper to get TWS before the Hornet when they bought their EA Hornet.