JCofDI

Yep - working for me now after those edits! A quick fix to the visor-only download might just be to include one of your existing visor roughmet files, then edit the readme to reflect the need to use that file and a corresponding description line. Thanks again for creating these (and all your other amazing liveries)!

Thanks for the response! First, I want to clarify my bug report on the JHMCS portion of the visor is incorrect - I had simply loaded up a different environment in ModelViewer than I was previously using which gave far less of a reflection. The JHMCS appears totally fine on all colors I tested. For the HGU-55 though, I was able to take a further look as I noticed that your other liveries that have custom visors such as the 18th FIS Birds did not have the matte bug. I checked and these liveries have an included roughmet.dds they use, while the custom visor pulls the default ED one which was updated to a red color where yours are pink. Adding the roughmet from these liveries into a livery I've added a custom visor to and adding the associated line to that description lets the visor work again as normal. Edit: Attached a gif for direct comparison of the two files. The one with the red HGU-55 visor coming straight out of the F-16C_50 Textures folder in the main install.

Thank you for these fantastic visors! It looks like the last patch messed something up on these unfortunately. The JHMCS visors have just a sliver of the chosen color near the top and the standard visor appears matte rather than reflective. null

Hat in hand - this issue appears to have been a result of me running a mod to "increase cloud quality" that I forgot I had even enabled. (The graphics files have an unselectable quality one step higher, the mod just re-enables that as part of increasing view distance.) I stepped back to the default highest cloud quality and the issue is gone. Thanks again for the mod, and sorry for the false report!

A few Hornet shots I've taken lately.

Not dismissing that other people aren't seeing it, just sharing screens to help show it. Two visible "seams" to the cloud layer looking different directions. Information bar included in shots to help narrow down location/direction to look. Also included a screenshot of the Mission Editor setup for any further setup parameters that might be needed. As mentioned, it's far less apparent than the shot I originally quoted, so if this lesser example is expected or normal that's okay with me too, just appeared at first blush like the sort of thing that was being requested. Edit: also meant to add, I run zero motion blur inside of DCS.

I was using Cirrocumulus 3 on a sunrise Kola flight and saw the same sort of issue in the top layer there, but not nearly as severe as that photo. Didn't think to grab a screenshot when I was on but can get it next session if needed. Fantastic mod by the way - thank you! Looking forward to those 2.1 cirrus clouds!

Thanks for the reply. Are you able to share a screenshot of what you're entering at the left? Also, could you confirm if you're using the local spreadsheet or the Google Sheets version? If able to try the other method, do you get the same results in each? At this point the only thing I can think is that it's an older Excel version causing issues with one of the formulas, but if you're using the Google Sheets version that wouldn't be it either. Sorry for the frustration! If nothing else, feel free to give me your exact detent location and I can share the correct user curve.

@i_am_lugnuts Glad to hear you got it to work out! Sorry for the delay in getting a new version out, but I actually just finalized the newest version tonight to include the F-15E and have updated the download page and first post accordingly. With a Thrustmaster Warthog you may be able to just use the Special Options, but otherwise using your proper Detent Location should get you all sorted out. Thanks for the interest! @WinOrLose Interesting results. If you're still having issues, would you be able to share what your User Curve looked like with the Mig-21? My Warthog throttle has a detent location of 31 which seems similar to yours and my numbers were as shown below. With this user curve my A/B kicks in just over the detent and the remaining post-detent range just controls how hard the afterburner runs. With a Warthog, be sure you *don't* have the inverted checkbox marked with an x, and you should only be adjusting the X Saturation and Deadzone settings on the spreadsheet from their defaults (100 and 0 respectively) if you also adjust those settings inside DCS (which I don't believe a Warthog should need).

Thank you for the compliments, Bucic! This is starting to get a bit out of my wheelhouse as I'm no hardware guy, but it ultimately depends on how the hardware is designed to report the range. I can at least describe how DCS interacts with the hardware I am familiar with and go from there. To compare it to throttles on the market, you can set it up the "Warthog" way, or set it up the "Virpil" way (credit to Virpil, newer software lets you customize even this, but for sake of discussion we'll stick with it). The Warthog has a fixed idle detent that reports at 0% once you're resting against it, and as you lift up over that detent and travel backwards to the OFF range (which reports as a button when fully in the OFF position), the axis simply remains at 0%. I believe this is the ideal way to manage a detent since in-game "0%" typically just translates to "Idle, waiting for cutoff command". The downside is that this is less customizable so if a module were to show that OFF range accurately, you wouldn't be able to model it appropriately. The "Virpil" method, prior to software allowing you to set axis-buttons based on hardware position, meant that you had to use a range of the throttle as an axis button to fire the DCS OFF command. You don't want to be pressing toward idle and accidentally fire the command to shut down engines, so the typical setup for a Virpil throttle with an idle detent that rests at 5% of the range would be to set a virtual button in the 0-3% range, then in-game set a deadzone to match your idle detent location of 5%. This method certainly allows for more customization, but it's just more complicated as there's more items needing to be adjusted to make it all work properly - particularly with a split throttle arrangement. Once you get the hang of it though, it's perfectly suitable. Now, for the DCS calculator portion. With the "Warthog" method, you have no in-game deadzone to adjust as 0% on the hardware is 0% in-game, and you just have cosmetic travel range in the real world - for the calculator you wouldn't need to touch the deadzone from the default. With the "Virpil" method, you would enter the deadzone in DCS as 18 (as 18% is where you are at 16 degrees and idle, so it's your new "zero") and the DCS calculator would need that 18 deadzone that matches your axis-tune window. Cool project, and good luck with it! (As an aside, the new Virpil method which I use allows for it to mimic that Warthog style - where you can make the idle-detent your actual 0% of the throttle range and still assign virtual buttons at axis ranges below the detent using the hardware reporting values. Makes swapping to something like MSFS which doesn't easily handle the deadzone method much easier.)

Thanks for the kind words @GK61! As Trigati notes, the spreadsheet has some updated values with the most recent release. Every time I've dabbled in computer code I end up as confused and broken as the results I make The app version won't be wrong per se; it has the initial values I used which were when the engine actually was in afterburner. However, there was some confusion that this location was sometimes visually past a detent in-game despite not being in afterburner, so the newest version in the spreadsheets align the calculated detent location with the in-game detents.

Hello all. I recognize that the overall behavior for the paddle switch with our model of Tomcat is correct (that paddle depress moves the SAS Pitch/Roll switches to OFF), but from reading the manual it notes that on the AFCS panel all switches are held by a solenoid, and springloaded to return to the OFF position otherwise. The current behavior in DCS is that the STAB AUG Pitch, Roll, and Yaw as well as the AP Engage switch can all be placed to ON while cold and dark. Also while cold and dark, pressing the Emergency Disconnect Paddle still switches the Pitch, Roll, and AP Engage to OFF. See the below GIF, taken in a cold and dark jet with no power source, with switches remaining ON from initial click and then flipping OFF when paddle is pressed. From this I have two questions: 1) Is it accurate that these switches are able to remain ON when the jet is unpowered? 2) If (1) is accurate, is it also accurate that the disconnect paddle is linked to these switches in a way that allows them to be flipped OFF when in an unpowered state? This may ultimately not be a bug, but after someone brought it to my attention I've been very curious what the actual switch mechanisms are that would permit that behavior. Any insight provided would be fantastic. Thank you!