Frederf

"WARNING-WARNING, WARNING-WARNING" VMS is automatically activated 1.5 seconds after illumination of any warning light on the glareshield which would include the TO/LDG CONFIG warning light.

There should be documented statements to the effect that marks aren't recorded until the FCR/TGP are tracking and until then TMS commands are applied to the sensor as normal. E.g. with non tracking FCR in mark mode first TMS forward commands FCR track and second records mark.

It certainly makes the most sense for the calibration marks initialized position to be at assumed zero regardless of HMCS LOS at mode entry.

According to the literal text it would be bearing and in a crosswind with nose left of track the tick mark would be rotated CW. However it could easily be inexact wording as so much of nav steering is track based. HUD tapes showing the tick orientation while FPM and GC are on opposite sides of the steerpoint should determine which.

OK, your secondary monitor is to the right of your first, great. First you want to have a "screen" size of 5760x2160 to have a "canvas" that covers both monitors. Make sure you have fullscreen option turned off (your card isn't going to let you create a 5760x2160 fullscreen frame onto a 3840x2160 monitor). This goes in the "Resolution" part of DCS Options>System. If it's not part of the drop down menu, don't worry, you can just highlight the text and type it in manually. We can start nudging the views around in screen space but that's not going to be productive until the canvas is the right size. If the canvas was big enough and the left started in the correct position the entire 5760x2160 rectangle would be either black or filled in with game views. I don't know if calling that one viewport "Center" is causing a centering action or not. Clearly the left edge isn't where it should be. You could try changing the center x position to x = 3840/2 to nudge things over to the right. But the numbers given in the .lua above should be correct. x = 0 should be the left edge of your main monitor. I would focus on ensuring you're fullscreen-off and the correct resolution first. Here's a diagram of what's going on in screenspace:

That's normal. With nVidia surround you're creating one logical display out of three monitors. To DCS those three screens are only one. The program is completely unaware of the hardware. Surround is the only way (that I know) to use multiple monitors and fullscreen at the same time. The 5:4 aspect ratio might be contributing. Personally, unless you really like nVidia surround for other reasons I wouldn't use it for DCS. Instead I'd just run DCS windowed (not fullscreen) and make a slightly altered 3camera MonitorSetup for bezel correction. It looks like you have additional screens so you could extend the canvas by a few more pixels (256 or 512) laterally and get your MFD slices out of that.

Hmm, there are a few things wrong with this. There are two VIP DED subpages, the page for setting VIP-TO-TGT and another page for VIP-TO-PUP with a SEQ between them. The second line which has VIP * #*↕ on each page should always be tied together in value. Currently it's possible to set them to different numbers with very weird results. The active steerpoint is shown on the CNI page. It should be the case that VIP behavior is only displayed when active steerpoint = VIP steerpoint as selected. Currently the PUP is only shown when active steerpoint is 1 regardless of the VIP selection on either VIP DED subpage. The PUP is only showing when the current active steer is 1 but it's showing relative to the steer chosen on the PUP DED page. Similarly the TGT is shown correctly offset from where the assigned IP is only if active steer is 1. The diamond showing the IP only shows correctly when the IP DED page point selection is also 1. It's terribly broken and wrong but you can get VIP attacks on your desired steerpoint by doing the following: Current steerpoint 1 VIP-TO-TGT VIP 1↕ VIP-TO-PUP VIP #↕ Where # is the particular steerpoint you want to reference for the attack. This applies regardless of whether you use PUP or not.

The weather might be slightly different? I don't know exactly what the auto start script does. I can put a cold start track in PG and look for difficulties with the radar. Is the 5 (ish?) minute standby warm up time being observed?

That's the thing, you make a new file in the \DCS World\Config\MonitorSetup\ folder and it becomes a new option in the drop down menu in game. Your particular hardware and desires are going to be specific to you. If you list the screen sizes, arrangements, and desired display someone will write you a lua file in short order.

MiG-21 is one of the few modules that simulates fragility in the electrical system. Turn stuff on in the order listed in the manual or risk failures.

Anything should be possible writing your own MonitorSetup .lua. It's not that complicated of a file to the point I might be able to guess on the first try. _ = function(p) return p; end; name = _('Camera+MFCD Vertical Stack'); Description = 'Camera on left monitor, Left MFCD above Right MFCD on right monitor' Viewports = { Center = { x = 0; y = 0; width = screen.width / 2; height = screen.height; viewDx = 0; viewDy = 0; aspect = screen.aspect / 2; } } LEFT_MFCD = { x = screen.width / 2; y = screen.width / 2; width = screen.width / 2; height = screen.height / 2; } RIGHT_MFCD = { x = screen.width / 2; y = 0; width = screen.width / 2; height = screen.height / 2; } UIMainView = Viewports.Center GU_MAIN_VIEWPORT = Viewports.Center

The INS steering should use the roll channel to null the track error. It looks at the subtraction of the INS track and course to destination and tries to make that zero. Heading has nothing to do with it.

Depends on the terminal speed, impact angle, and the post-impact slowdown. 590 knots is 1000 fps which is 1' per ms. I did a test and got about 1500 fps with a GBU-31v3 which is about 1.5' per ms. For terminal angle divide by the sine of the angle from horizontal, e.g. +15% for 60° +40% for 45°. Slowdown is the most nuanced. A thin, soft building won't reduce speed as much as something hard. If you knew the burying depth for a given impact (e.g. 20' at 1000fps) then you could assume it was losing 50fps per foot of hard material. Maybe think a commercial high rise is 3' worth of hard surface every floor so 6' total. Take the average of the initial impact speed, final speed 1000+900/2 = 950. Tin shack practically nothing, concrete bunker much more. So you want to go 25' (one and a half floors) through say 6' of hard material at 1300fps average on a 60 degree impact angle. T = 25/1300 * 1/sin(60) = 22ms. That seems quite a small delay. I think 60-180ms is more common historically but that might be against hardened targets which would bring down the average velocity a bunch. 5ms per floor sounds too short as it would have to be covering an average of 2000fps of height change. And of course this all depends what FMU is on the bomb. If it's -152 then you can program it on the fly. If it's -148 then your SMS settings don't change anything.

You have to be within 1% of minimum axis input. I set saturation Y 99% and couldn't get the clickable zone to pop up. There are two stages of advance (right click each stage) and two stage of retreat (left click each stage). I also notice it can get stuck between stages if you try to advance with throttle not near zero. This can be fixed by returning throttle near zero and doing the other command.

Here's a short track of HMCS aligning. Steps are: Ground power CONNECT Main power MAIN PWR MMC ON UFC ON HUD brightness INCREASE HMCS brightness INCREASE UFC LIST, MISC, HMCS (LIST, 0, RCL) DCS SEQ ICP 0 M-SEL Align helmet cross with HUD cross Enable PRESS ICP 0 M-SEL ICP 0 M-SEL Cursor slew to align top HMCS cross with HUD cross ICP 0 M-SEL ICP 0 M-SEL Cursor slew to align bottom HMCS cross with HUD vertical line ICP 0 M-SEL DCS RTN F16 HMCS Align.trk

VOR, DME, ILS can refer to the channel system or frequency. Although commonly frequency is referenced it is correct to call Batumi's RWY13 ILS as channel 40X. Channel 40X is a bundle of frequencies: 110.30MHz, 335.0MHz, 5037.6MHz, 1064MHz, 1001MHz. When tuning TACAN 40X you're only using a portion of that bundle of frequencies that make up that channel. When using ILS the localizer radio and glideslope radio are using two different parts of that bundle. And when the Space Shuttle tunes its microwave landing system to 40X it's using the 5037.6MHz frequency of that bundle. Mercifully and sensibly VORTACs use the same channel for the VOR and TACAN. E.g. MMM VORTAC in NTTR is 114.3 VOR (90X) and TACAN 90X. The TACAN and ILS at Nellis don't having TACAN 12X and ILS 28X. McCarran's VORTAC is 116X while its ILSs are 40X (even says it on the DCS editor, just that one oddly) and 54Y for 25R and 25L respectively. Channels 17-56,80-119 have "Z" and channels 18-56 have "W" in addition to "X" and "Y". As far as I can see Ws are Xs and Zs are Ys with the MLS frequency as the only thing different. --- Saying all that, the ICLS system on the F/A-18 is not the same as an ILS on a 737. They are entirely incompatible systems. There do exist ILS-equipped F/A-18Cs in the world, the Swiss Air Force and whatever special model the Blue Angels team uses, but that's not the airplane simulated.

If this is a limitation of the radar resolution (an excellent thing to simulate) then the resolution would be range and spacing dependent. Four groups of one or one group of four is irrelevant as long as the positional geometry is the same. With a test for best detection distance. The radar was able to resolve a group of 4xTu-22 at 83.6nm in the open abreast formation (2743x0m). This is an an angular separation in azimuth of about 1.0°. Repeating at close formation (1828x0m) detection at same initial range was only of two contacts, one which I think was #1 and then the other kept flipping back and forth between two other airplanes (I think #3 and #4). At 77.7nm there was a flicker of a fourth (I think #2) distinct contact. Four simultaneous distinct contacts was only achieved at 56.9nm (0.99°). Repeated at group close formation (39x0m) was difficult as the AI maneuvered to avoid collision and flew an approx 74m spacing. Regardless initial detection occurred at about 83nm. Four distinct contacts were seen almost immediately. Repeated at finger four open (116x97m). Same detection distance. Indications other than a single contact started at 55.6nm. Behavior changed in character and full resolution into four distinct contacts did not occur until 3.0nm (~1.2° in azimuth). Lastly I tested two groups of one each Tu-22 laterally spaced at 1.0nm but otherwise identical in speed, alt, and range. Full resolution occurred at 57.2nm. Conclusion is that against Tu-22 regardless of within a group of between two groups unambiguous resolution purely in the azimuth domain is 1.0-1.2° for F-16 radar.

I've generally used TWS after generating the picture in RWS first. Even though RWS isn't displaying tracks, the radar is still busy making them at all times. Usually 2 missiles at 2 targets is the most I'll shoot so DTT works well and having only two tracks makes it hard to step to the wrong target during the shooting part of the engagement. TWS is necessary for engagements of 3-6 simultaneous targets which the radar and AIM-120 can do if needed. TWS has value for monitoring vector info when keeping an eye on a situation if it matters. Before Link 16 you really didn't have as much situational awareness in plain RWS. Without flight members tracking stuff over IDM they were at best white dots with only a trend line. This two kinds of tracks (tanks, system) really throws a wrench in working with TWS as you have to blindly keep track of which are which type when L16 is obscuring that. I think technically tank tracks aren't supposed to DL correlate which (if true) would be a great change and make TWS easier to use. In short, don't go into TWS until you feel you have time and space and want that extra information layer. Oh, and use the smallest azimuth/bar settings you can in any mode. Spotlight scan is going to be super helpful when it gets introduced. That's my advice.

As far as I've heard there's only the PDLT not a multi-object situational awareness display.

Rudder authority decreases from 100% to 0% based on AOA (different CAT I/III). You can still do nose slices, just bunt forward to null your alpha first.

Pre-designate SP is airplane-fixed. Post-designate SP is centered on the created pseudosteerpoint. In pre-designate SP the SPI is your current real steerpoint. In SP post-designate the SPI is the pseudosteerpoint. Pre-designate SP is working fine with the radar being airplane-fixed except if you change the azimuth setting of the radar. If you change the azimuth setting while in pre-designate SP the radar scan stops being airplane-fixed and goes back to centered on the steerpoint. One should be able to change the azimuth setting in pre-designate SP freely while retaining the "look ahead" nature of the SP scan.

The language is a little confusing because in for example A-10C everything is a waypoint and you pick a special waypoint to be your current, singular, special steerpoint (you know, for steering). F-16 is a little different because it kinda calls all points steerpoints even when those points aren't the one, the only, special singular point-for-steering steerpoint. Technically F-16 has something similar with "destinations" which are the points which could become the steerpoint but LIST/1 DEST is still WIP. When a mark point is recorded in one of the slots and you want to set it up as active, you just change your steerpoint to that numbered slot however you can. There are several ways: inc-dec arrows on any DED page which puts arrows around current steer, going to the STPT page and typing in the number then ENTR, pressing MSEL on the mark page (shortcut to make that particular displayed number active), or selecting a point with the HSD cursor. Cursor slews are zero'd with the CZ function. DCS Viper is a little confusing because the TGP was developed before the radar so some people think of snowplow and cursor zero as TGP functions. They aren't. "CZ" (and SP) is a whole airplane function which has shortcuts scattered around on various MFD formats. Whenever you see "CZ" or "SP" it's like having multiple copies of the same shortcut on your computer desktop. It doesn't matter which one you use as they're all shortcuts to the same airplane function. The "CZ" shortcut should show up on the FCR (even OFF) and TGP pages. In airplanes newer than the DCS variant they added it to the HSD format too.

The physical switch is half-spring loaded with three positions. Extend is the spring loaded half which will fall to center (hold) unless held. Close is not spring loaded and will stay in retract until moved back to center. The THROTTLE_SPEED_BRAKE command has values -1, 0, +1 for extend, hold, retract. The normal commands are: EXTEND down -1, up 0 OFF down 0 RETRACT down 1 The special command provides a substitute to use instead of the above RETRACT: RETRACT/OFF down 1, up 0 The down -1, up 0 gives the EXTEND command its "springiness" changing to a different state when released. I can't think of any reason why anyone would use anything else regardless of their joystick hardware. RETRACT (and OFF) being strictly setting state 1 (0) on down and nothing on up makes them "sticky" in that they stay in that state until commanded to a different state. Since the real switch will stay in the RETRACT position hands off that's good simulation of how the switch works. The idea of the special Retract/OFF is for people who have joysticks like Thrustmaster Warthog which have a switch will continuously hold down the button input even if the user removes their hands. It doesn't matter if Retract is "springy" because the user's hardware is holding it down. That way they can use two buttons (instead of 3) and still activate all three switch states. That's useful because the Warthog only assigns two buttons to that switch. And the reason it does that is because DirectX has a 32 button limit and the device has too many switch positions to be assigning a button to every one. --- But really I am guessing that slackpanda is simply flying in one of the auto-retract flight regimes, his switch in the center OFF position, and the F/A-18 is behaving normally.

For practice you can make an editor mission with tanker, you a few miles back and in a state that needs gas. The track file that results will be super small. During any rejoin visually (lacking TACAN or radar distance) you need to aim at a piece of sky to his side, maybe 500-3000' laterally. Rejoining straight up the tailpipe is a classic nugget move. You can only tell range by how big he is in the window and by the time you realize you should be slowing down it's too late. When you aim to miss you can tell distance by his angular position by parallax, plus it's much safer, plus if he's turning you get there much faster. When he's 30-45° off nose then you slide in diagonally. Also sliding around at or above his level are safety fails. Pretend wake turbulence is on and keep your step down until well in the box. Underneath you're plenty gentle but lots of wander in all three dimensions. Once you learn the sight picture for contact you'll do much better. The lights are nice aids but really you want to watch the whole tanker as an object. Motions of a fraction of walking pace are easily detectable by eye. When you move, zero motion by looking at tanker, then look at the lights for position guidance, then watch at the tanker as you enact that change. Repeat. F16 Demo AAR.trk

Speed brake automatically retracts with the SPD BRK switch in the center detent: Airborne, flaps AUTO, >6.0g or >28° AOA Airborne, flaps not AUTO, < 250 knots