IvanK

Trying ACLS on the Stennis , set the mission up as per the ME instructions for ACLS mission building. boxing ACLS goes through the test and I get ACL 1 on the link 4 display. Then on final all I get T/C mode (Didnt think I was meant to see this in the non Supercarrier version). Flew final on the ICLS and never ever got to see the Tadpole. So to my eye ACLS is not working. Mission file attached. Note DL Freq is 306 F18__20cu_CV_testACLS.miz

And Bingo charts give a Descent Flight Path angle of 4.5degrees for a clean jet.

I have been having similar crashes. As suggested by Flappie raised a support ticket. Support was great. I tried tried everything suggested in the end the only thing that got me back to stable DCS was running my card in NVIDIA Debug mode. NVIDA Contol Panel -> Help-> then tick debug mode. My understanding is this removes all Overclocking including "factory" overclocking and sets your card to its stock speeds. This issue only started on my system with the introduction of the last OB. Mine is an old system and I think the last OB has just pushed my system to its limit. There does seem to be a spate of similar crashes from multiple users recently.

Looking at the relevant DOC for the FA18C Max range descent Idle thrust at 35,000lbs from 30,000ft gives descent dist of 60nm

Warning Thread Drift :). Before the days of FPAS 2 numbers were in every Hornet pilots brain. Max range 4.2Alpha Max Endurance 5.6 Alpha. When on on the bones in a Bingo profile you flew 4.2Alpha. When the home base was in sight you flew a 4.2 degree descent profile at Idle thrust. So in fact waited till home base was at -4 degrees in the HUD then select Idle and descend at -4 degrees Flight Path angle. Not very sophisticated and didnt allow for winds but worked.

He started the pull at 1.1M according to his recall in the interview. So riding the limiter through the transonic range. Looking at an early version Flight manual circa 1986. is the following comment. "Before 8.3PROM there is an over-G potential associated with abrupt longitudinal stick inputs at high subsonic speed where transient G overshoot of 1g or 2G may occur ........CAUTION Before 8.3PROM above 400Knots, avoid abrupt longitudinal stick movement which can cause large G overshoot" 8.3PROM came in around 1985, G limiter as I recall came in with 8.3PROM

In the "A" in general terms in Subsonic flight the g limiter was pretty good. A random snatch to full backstick might result in a minor overstress to say 8G (setting a 811 code for maintenance) but you could rely on the limiter to protect you, pulling to the limit was pretty normal. In the transonic region it was still meant to protect with the "G Bucket" incorporated in the loop. In earlier fighters "Transonic Tuck" was a huge player. In simple terms the instant you come subsonic the C of P moves rapidly forward so with the surfaces deflected you get an instant increase in moment arm and Bang overstress.

In one crash I got a Blue screen that referenced nvlddmkm.sys. So Off on the Google merry go round for this. Google told me should find it in C:\windows\System32 Alas its not there I do find a copy in C:\Windows\system32\DriverStore\FileRepository\nv_dispi.inf_amd64_1c83a5d7cffd7bf I am running Windows 10 on Intel chipset with GTX970 Everything is up to date on my system

The crashes are back. Log file attached dcs.log-20220412-012736.zip

Perhaps add an ATC function where the Pilot can Request Runway lights on from the tower at any time of day

Update. Removed Display adapter and all files by way of device manager. Then Rebooted PC. Re installed latest Drivers by way of GeForce experience. Re booted PC. So far no further crashes (Fingers crossed).

You can also designate with the Bomb weapon release button. This is the preferred method when designating in a dive delivery the so called "Point Blank" method. Push and hold the weapon release button, Fly the ASL or Pull up the ASL for a dive Toss delivery through the Release cue.

Thanks Bignewy. All drivers up to date. A single Windows update just done. No overclocking. Will test again.

Getting almost 100% crashes with FA18 module. Crash log attached. (tried to use the Auto crash upload but got error message) Seems graphic related as this string is always in the log: 2022-04-03 05:29:55.512 INFO EDCORE: C:\WINDOWS\SYSTEM32\d3d11.dll 2022-04-03 05:29:55.512 INFO EDCORE: # C0000005 ACCESS_VIOLATION at 792098A0 00:00000000 Updated Nvidia drivers same issue. Open Beta Ver 2.7.11.22041 dcs.log-20220403-052955.zip

If the R530(EM version)mechanization in the F1 is the same as in the MIRIII then trying to employ the Boresight radar mode in anything other than a tail chase situation would be nigh on impossible. No issue for R550/AIM9 though. R530 employment in a Manoeuvering engagement is a complete waste of time.... PK= 0

If its the same as in Mir III then all Gun emergency mode does is select Boresight with Auto lock on. All you need to do is put a fixed refrence in the sight over the target and hold the Gun Emergency mode button depressed until lock on is achieved. If you release the button before lock the radar returns to the previously selected search mode. So after lock you get tracking data. Missile Firing (R550/AIM9) is independent of this requirement so always available. Not quite so simple for the R530 as there were a bunch of relatively complicated process between the Missile and the radar that occur after lock on to get the missile to launch status. In the Mir III this could take anywhere between 1-4seconds to actually occur. This was so limiting that in the front sector head on there were defined Minimum Lock ranges based on closure.... not helped by limiting range of the radar ! In many cases these Minimum Lock ranges were very limiting. A reasonable amount of dexterity was also required to manipulate the strobe (Azimuth range and antenna elev all at the same time... all with range rapidly reducing :). (R530 was as useless as tits on a bull btw

Here is the Radar control Stick from the Mirage IIIO with its functions. Physically stick looks the same. Looking at the Spanish diagram, functions seem similar The term "Strobe" means effectively the TDC. Rotational movement moves the Strobe in range. Vertical left Right movement moves the strobe in Azimuth. The Strobe was a single horizontal line the Right hand edge being the exact point positioned by the stick under the return , lock on then being initiated. Below is Mirage III display in the lock on process, Lock on being commanded on the return second down from the top of the display. Real stick

There are detailed investigations into this bug. Its been reported a while ago. https://forums.eagle.ru/topic/278340-ins-only-ccip-in-the-hornet/#comment-4736066

Well the A-D versions I know for sure that had VOR/DME/ILS options are RAAF,RCAF,Blue Angeles,Swiss,Spanish,Finnish

RAAF FA18A from the last century circa 1985 VOR/ILS/DME options down the Left hand side of the HI

My experience was all land based. For us we actually used power as the primary control of AOA down final rather than the NAVY method of using pitch. As such our everyday technique in manual thrust was the same as is required in ATC mode.. Pitch for flight path and power for AOA. How many times was ATC used in approach mode ? A personal thing as nothing was mandated based on recovery conditions. In my case probably on about 25% of instrument approaches ...ILS/GCA/TAC/VOR. Having said that if I was shooting an approach to no shit minimas I would not hesitate using ATC. Used correctly ATC approach mode was smooth and very accurate. The typical pitch corrections you make on an instrument final were easily handled by the ATC. Another snippet ATC cruise mode actually refrences TAS not IAS at time of selection.

I have posted/reported in the Beta areas.

Based on Real life experience. Yes backdriven ... just slightly but not a reduction of 13% N2 followed by gross overswings.

I agree 100% with Pieterras comment on ATC implementation.