Harker

For the fuel state, a simple way to do it is to select the appropriate loadout and once you are at the desired altitude, start dumping fuel until the FCS allows at least 7.3 G. That would give you the max fuel state they could've had, assuming that the FCS G limiter in DCS is working with the same numbers.

+1. I'd say that this is a very important feature. And it's not only controlled by the RDR/JMR priority option, the radar takes priority when it's supporting an AMRAAM as well.

In the HUD, the number below the current G value doesn't show the max allowable G, it shows max G that was registered, if it' above 4.0 G. i.e., your FCS could allow for 7.5 G, but if the max G you pulled was 5.2, the HUD will display 5.2 under the current G value. Since the HUD in the Jetstream video shows 7.3 G, this is the max G they pulled. So they are at least light enough to have 7.3 G allowed by the FCS (it's also safe to assume that they're even lighter than that, as the max allowable G by the FCS is 7.5, so they could be much lighter and still be limited to 7.5 G), assuming they didn't disable the limiter with the paddle switch (I really think they didn't).

It makes sense for the CCIP cross to be displaced one way and the AUTO ASL the other. Both solutions are having you fly the same way. At least that's consistent... But I agree with your post. There appears to be what I can only describe as a fake wind effect that's tied to the INS drift, since the INS attitude is not affected, but only the bombing solution is. In all cases, without wind, the CCIP line should extend towards where the INS thinks the ground is, so the INS drift would have no effect here. And if the INS attitude was truly affected, then the HUD horizon would be at an angle so that the CCIP line should be 90 degrees off that, towards wherever the INS perceives "down" to be. After thinking about it, it seems to me that DCS is taking the drift between the coordinates in the INS and the "real" coordinates and it adds that drift into the bombing calculation. But of course, that's wrong, since the INS is the only position-keeping system here. The INS is wrong, but it doesn't know it's wrong. Lastly, the whole thing with DTED has no bearing here, since that would only affect the bombing solution's vertical displacement.

No worries, no offense taken at all :) It's just that sometimes people assume stuff like that and I just wanted to be clear that I neither affect or have any insider knowledge of DCS's development. What I was suggesting is that ED should put more effort into fixing and expanding the CA module, according to the product description. This is, after all, what people paid for. That should come before more features, IMO, as it'll keep the technical debt manageable. Unfortunately, new features mean new bugs etc, it's just the nature of the beast. And as for my suggestion to move to an RTS-only implementation and for DCS to focus on flyable modules, this is just my opinion, as from what I've seen, making CA the experience more engaging will likely require a significant overhaul of how DCS works and especially how maps work. An RTS engine on the other hand is easier to manage and would likely offer a lot of content for CA players interested in the commander role. Some other posters made good suggestions on the topic. But of course then, it wouldn't be the product that people paid for... I'm not saying that it's not doable, but I'm skeptical whether it *currently* is. If I think about it, one possible solution would be to have people in ground/naval vehicles see and exist in a more complex terrain, with a smaller rendered radius, that communicates in real time with the "aircraft" map, so things like unit positions etc are the same between the two. This could maybe be achieved using multiple LOD layers, but I'm reaching my knowledge limit with regards to game development now and I have no idea if something like that would be possible. Apart from that, it's a matter of developing the necessary APIs for high fidelity ground and naval assets and while that would be very nice, it would be a monumental task for ED to do so and at the same time manage the resulting technical issues. Would I like to see DCS offer a simulation of anything that can be in a battlefield? Absolutely. I'm just afraid that trying to do everything will come to the detriment of the current part of DCS. OTOH, ED is already developing an RTS engine for the dynamic campaign, so maybe an expansion of that could be integrated into CA, in order to add more value. And of course, this is just a wishlist thread, I just wanted to chime in with my personal opinion, that's all.

I recently got the G2 (first VR headset) and I agree, the IFLOLS blooms too much in VR. I don't know how to help with that, but you can turn the pop-up off in the Special Options, in the Options menu. If that doesn't work (because that setting is often bugged), go to \Mods\tech\Supercarrier\PLATCameraUI\, open FLOLS.lua with a text editor, go to line 41 and change FLOLS:setVisible(val) to FLOLS:setVisible(false) That'll disable it for good.

To your first point, it's exactly what I'm saying. The current iteration of CA should be ironed out by ED well before anything else along these lines is even considered. As for the aspirations of ED, they're just that for now, aspirations. DCS might become that in the years to come, but in the near future, unless we experience a technological leap in processing power, memory management and associated manufacturing, there are limits to how many things you can run well, in high fidelity, under the same hood. If DCS gets more complicated in the short term, it should be in terms of sensor and electromagnetics simulation. BTW, the "DCS Ground Crew" doesn't mean I'm associated with ED in any way, it's just a volunteering thing in the forums, nothing more. Just clarifying.

Paying for a new iteration of CA when the original one isn't working correctly, is a bad idea. What message does that give? Personally, I'd say that it's better if CA stops existing in its current form and instead is developed as a 2D or 3D RTS interface; it's the best long term solution and one that adds a lot of depth to the game. DCS cannot be an everything simulator and it shouldn't attempt to be. Trying to fit high fidelity aircraft, naval assets, ground vehicles, infantry and their respective high fidelity environments into the same software is impossible, within today's limitations.

Yes, we should have TAMMAC, but as you say, our HSI layout is pre-TAMMAC. So, until the HSI changes to reflect the inclusion of TAMMAC, I assume we do not have it. If we're supposed to have TAMMAC, according to ED, then they need to change the HSI.

Good question. Since AZ/EL is only available in A/A, then yeah, you'll lose that one and you'll probably go to TAC. Same goes for any page that is mode-specific. Getting rid of the unnecessary page changes when entering A/A or A/G will help a lot, especially when doing air-to-ground work. IRL, MSI processing stops in A/G and you only have RWS available, so it's common practice to prepare everything in NAV, while MSI still works and you can maintain better SA and then switch to A/G when you're ready to attack. If you do that in DCS right now, you'll mess up your displays as soon as you enter A/G.

If you do have information that points to the current implementation, then I have nothing more to say. It was never pointed out to us, so I wrote my comment in that context, plus the conversation that was presented. Also, thank you for the reply and I appreciate the update. It'll be interesting to see where the investigation leads.

There have been two separate issues reported, regarding the positioning of SA page elements: Ownship symbol location (disparity between HSI and SA, reported here: https://forums.eagle.ru/topic/273003-hsisa-page-ownplane-misaligned/?tab=comments#comment-4680387). This issue has been present for a long time. All other element symbols (reported here: https://forums.eagle.ru/topic/277903-the-target-icon-on-the-sa-page-is-misplaced/?tab=comments#comment-4731660). This issue appeared with the latest OB patch. In my testing on previous versions of the game, the SA page worked correctly if line 34 in the SA.lua file in \DCS World\Mods\aircraft\FA-18C\Cockpit\Scripts\Multipurpose_Display_Group\Common\indicator\Pages\MPD\SA\ was corrected from addStrokeSymbol("aircraft_Track_UP", {"stroke_symbols_MDI_AMPCD", "136-aircraft"}, "FromSet", {0, -25}, nil, {{"MPD_SA_ModeShow", MODES.TRACK_UP_MODE}, {"MPD_SA_EXP_PlanePos", LittleCompassInternalRadius}}) to addStrokeSymbol("aircraft_Track_UP", {"stroke_symbols_MDI_AMPCD", "136-aircraft"}, "FromSet", {0, 0}, nil, {{"MPD_SA_ModeShow", MODES.TRACK_UP_MODE}, {"MPD_SA_EXP_PlanePos", LittleCompassInternalRadius}}) It is only a number change for the ownship location, the -25 needs to be corrected to 0. This makes the ownship symbol be in the same position between HSI and SA (corrects Issue 1) and subsequently corrects the wrong positions of all other SA page elements relative to ownship. It seems that in the last patch, the wrong relative position of all other SA elements was "corrected" by artificially displacing them lower, to match the wrongly displaced ownship symbol. But it lead to the problem that they now do no longer correspond to their real locations, as is shown in the bug report for Issue 2. So, whereas before, there was only Issue 1, which was very easy to fix, we now have both Issue 1 and Issue 2. I would like to kindly propose that the position adjustment for SA page elements be reversed in the code and the simple fix for Issue 1 be applied (change a number from -25 to 0). This would be the easiest and cleanest way to solve both issues at once.

I'm going to start sounding like a broken record, but I'd like to again point out that, unless there's documentation that explicitly states that something cannot be done, then common logic (it can be done in all other comparable aircraft) and witness testimony (three people with IRL experience) are the next best things. The laser arm switch is a consent switch that allows the laser to be fired, it doesn't remove power from the entire relevant system, when in SAFE.

The LDDI and MPCD shouldn't change at all with any mode change. Only the RDDI should switch to the RDR ATTK page, upon entering A/A mode. Furthermore, assuming that the corresponding display cannot be assigned the TDC, SCS Left should bring up the STORES page in NAV and A/G (not implemented) and the AZ/EL page in A/A (implemented) on the LDDI. SCS Right should bring up the RDR ATTK page on the RDDI in all modes (implemented).

If you switch the AMPCD to Night mode, you can adjust GAIN, CON and SYM manually. I find that a low GAIN value, coupled with a CON of 4 gives me good enough results, but you're not wrong that it's not always clear. I usually lower GAIN and CON to the point where the map video is barely visible. I use a Reverb G2, for reference. MDG_strokesDefs.lua I also made a small mod to help highlight the AMPCD symbology better, by increasing the black border of the display elements. Give it a shot and see if it helps. Place it in DCS World\Mods\aircraft\FA-18C\Cockpit\Scripts\Multipurpose_Display_Group\Common\indicator\ . You're going to have to replace the current file and replace it after every update/repair or better yet, use a mod manager, such as OVGME.

I meant decoy implementation in DCS in general. If ED implements logic for the ALE-50 and the TALD is already in-game, there is no real reason to skip the GEN-X. Agree about VS. It's a simple mode, since it does not produce MSI trackfiles and if the work is done for the Viper, there is no reason for the Hornet to remain without it (not that there was one to begin with, besides the fact that it's not used a lot IRL, but I'm guessing that's true for the Viper as well). Thanks, BN. Looking forward to the update, but in the meantime, I'm happy to see much more pressing issues surrounding the radar and MSI, being worked on.

@BIGNEWY Considering the announcements made in the Viper's roadmap (https://forums.eagle.ru/topic/278635-dcs-f-16c-viper-roadmap/?tab=comments#comment-4739362), concerning the Towed Decoy and Velocity Search radar mode, can we get a clarification on why these features were removed and absent respectively, from the Hornet? If in-house development takes place for these features, both aircraft should benefit from it. It's fine if it takes a long time, but it would be important to know that we're getting them. Thanks.

Even if DCS could use sensitive documentation to model things and there was no threat of legal action taken against the developers, it's in ED's and a lot of 3rd party developers' interests to maintain good relationships with government agencies and militaries, since some are current or potential customers.

Interesting about the HUD. Further indicates that the radar should stay as the designating sensor unless positive action is taken with the FLIR. As for the FLIR driving the designation without being commanded to, as soon as you switch TDC priority to it, it's what I notice as well. For example, I get the problem when I track with the radar, switch priority to the FLIR just to zoom in with the antenna elevation controls and the radar stops tracking.

Agreed. Considering how diverse the fleets are, an EF that is not identical to a specific IRL jet, but feasible from a technology standpoint (in the sense that the feature in question is actually in use) is a good way to go.

Do you have any evidence that supports the current implementation? Because I looked in the 746 and I can't find this logic mentioned there. Plus, it's different from the logic for all other sensors. Right now, the FLIR will take priority from the Radar without being commanded. This works differently when the initial designation is made with WPDSG, where positive action (TDC Depress or commanded track) is required with the FLIR, in order to drive the designation. But it doesn't matter how the designation is created (functionally, using WPDSG and designating the same point in the ground with the radar should produce the exact same result), the logic should be the same (the WPDSG-type logic is correct) either way. Plus, it's 100% wrong that the radar will not be able to re-take priority either by being commanded to track with the SCS (which doesn't work now, if the FLIR has initial priority) or by designating a point with the TDC. If positive action is taken with another sensor, a new designation should be created by it and all other sensors should exit tracking and slave to the new designation. Right now, the relevant logic is definitely broken, as mentioned in the last point of my first post. At the very least, the latter point needs to be addressed ASAP. It's basic sensor logic. Again, I could not verify the current logic with my documents. If you have documentation that explicitly supports the current implementation in DCS, including the inability of the radar to regain priority, please let me know where to find it. Thank you.

Well said, that's what DCS is all about.

That'd be the best option.

Last time I had the wrong elevation, with WPDSG, AUTO worked as I expected it, in that it gave me a solution for the point in the air. In general, it's fine if we're talking about pre-planned targets, where there is a point of reference for the elevation. The problem appears when elevation data and ranging aren't available and we're still getting good solutions.