Floydii

I'd suggest it would be the missile running out of energy (and therefore lift) before the 20nm mark.

Im not sure this is correct. The main issue here is that the AGM-122 can currently reach 100% further (at least) than the stated range (at speed and altitude) of 9nm. Can any of the L-M model AIM-9s in DCS go 20 NM and stay controllable?

There is a bit of chit chat about the WinWing setup - disregard that and pay attention to the bit where he establishes the black and white zone to tell reshade to brighten the screens that MFDs are on.

You may not be able to, but I believe you can use Reshade to brighten certain parts of your screen/s. Do that over the top of MFDs and it may help.

Okay, I'm in 2D. Does the workaround work for you in either ST or MT?

I have a fix for multiplayer using the Singlethread exe. The key is to force the game to render the area you are going to spawn into immediately before you jump into an F15E from slot selection. I think the issue is to do with preloading textures and objects (including the F15E itself) when slotting in to an aircraft. What I have found sounds like what Recluse is seeing in that if you don't force the game to render out the airfield you are going to spawn at, it will crash upon you slotting into the F15 at that airfield. I have forced it to render by going to the airfield in the Spectator mod Map then going ctrl-F11 in order to get all the textures loaded in the immediate area. After that I jump in the F15 and its fine. Try to spawn in another F15E somewhere else - game hangs (unless you first go to spectator and preload the area again). I'm yet to test it, but I suggest if you are going to join as a WSO, first F2 view the jet while in spectator, and then jump in. Again, Single player works fine, and Multithread works fine if you can deal with random hitching and 5-10 second pauses, So I don't know what is peculiar to the F15E on Multiplayer in Singlethread.

I am having a similar problem, when loading into a MP server (using single thread) and selecting an F15E. About 75% of the time it loads an untextured cockpit, no scenery and freezes. In singleplayer, no issues. Multithread multiplayer F15E loads fine, but then becomes unplayable due to random freezes etc (all modules). I will try: - running without mods - doing a slow repair - deleting fxo/metashaders2 From everything I'm reading, I'm pretty confident is a bad mod interaction. *Due to Multithread having really bad stuttering

Are Air Defence units prioritised above other ground vehicles in line with the Priority Schemes - Ie, if the scheme prioritised static ground vehicles, then the first static ground vehicle selected is an Air Defence one (should it be present). I recall this behaviour from enough earlier Longbow sims to form the view that it's likely a thing.

Applying the mt.lua had no improvement to stuttering and hitching I've been having since at least the last OB patch. When panning the view, the game will consistently pause for 2-10 seconds the view is pivoted more than about 5 degrees. Hitching also noticeable when observing terrain passing by. I'm running an intel i5-7600 CPU (3.50ghz currently OC'd at 3.90ghz) - four cores, no virtual cores. Of note, hitching is not present in single core mode. I have also had some success progressively removing DCS' affinity for certain cores and then re-adding them, but it doesn't permanently solve the issue during a session.

I'm on an Intel quad core as well. ST works with no issues while MT stutters when looking around in cockpitand then will randomly freeze for 5-10 secs while flying. I've unparked all cores, but no perceptible difference. I'd run ST until this is fixed except the F15E doesn't like it.

I've had a similar instances as WSO in MP where the view starts shaking and the wings are badly bent up like they've overstressed. The pilot doesn't see any structural damage and if I rejoin the slot, the damage and shaking disappears. Best I can tell, desync between pilot on WSO caused warping on the WSO end which then is reported on that client as aerodynamically caused damage. I suggest a solution would be to ensure the WSO client derives all ownship damages from the pilot client. That, and the interpolation done to make pilot client manoeuvres look normal to the WSO is bounded by what the aircraft can actually do - ie, not accelerate downwards instantaneously at 70g.

If you're staring from scratch, that's a fair assumption, however the DCS DTC allows you to save the coord and other settings that can be reloaded and shared with a couple of mouse clicks.

100% this. Its silly that you can fully rearm the jet with GBUs with the engine running, but can't change the codes. Given the highly abstracted rearm/refuel/repair mechanic in DCS the inability to change GBU laser codes on the ground seems like an inconsistent limitation. Note that the JF17 has a correct ground-only LGB setting limitation, but you can do that with the engine running. As such, it doesn't look like a base DCS Coding limitation is causing this, rather an inconsistent design decision. I note the same thing effects the harrier APKWS (but not its LGBs oddly).

100% this is something needed for all modules and I unserstand that ED is working on it. Now, noting this thread started life in the F16C forum, the following tool will address your need for F10 waypoint entry (and a bunch of other cool configuration stuff for the Viper): https://github.com/the-paid-actor/dcs-dtc/releases If you like it, mercilessly encourage the Author to expand it for other aircraft.

My apologies, you didn't post a link initially so I must have gone to the old one. I like where its going though.

Cool, I'll give it a go. Noting the last guthub update was 2019, any idea if it'll be updated with newer Aircraft?

Currently, the JTAC optics (B key) are moved with the mouse, which is okay for lasing static larger vehicle targets at <4km, but makes it very difficult to place the crosshair on a smaller targets or targets further than ~4km away as the crosshair tends to 'skip' with even the smallest movement of the mouse (yes, even at high dpi). Is it possible to add five 'fine adjustment' keybinds (enable/disable, up, down, left, right) that can be used to very precisely wind the crosshair onto the target after coarse placement with the mouse and not have it shift due to inadvertent mouse bump. The precedent is that most ground based laser designators have the ability to be precisely hand cranked in azimuth and elevation for this very reason. The second, related, request is for another, higher, level of zoom for the JTAC Optics. I say optics because the implementation of the JTAC mode in CA is quite generic (which is fine), but should reflect the option for dedicated ground based observation systems such as the US Long-Range Advanced Scout Surveillance System which is mounted on both Stryker and Humvee and is cited as being able to provide a 10-digit MGRS grid at 20km. Right now we're lucky to get ten digit accuracy at 4km. these two improvements would go a long way towards making the JTAC/Forward-Observer mode far more useful in game.

That's nice about the real F16C - maybe you can give me a joyflight sometime. From the manual for the DCS F16C (page 301) • SEMI – The aircraft systems determine the program to be dispensed based on the threat. Consent to dispense must be given by positioning the CMS aft. • AUTO – The aircraft systems determine the program to be dispensed based on the threat. Countermeasures are dispensed automatically. This mode must also be enabled by positioning the CMS aft. It may be disabled by selecting CMS right. Now, the LUA explicitly identifies the auto programs by what type of threat they counter vs the manual programs which are very much random chaff/flare combos by default. The reason they are identified is the CMDS should match the threat to a to the correct auto program (hence my comment on a table that assigns threat radars to prompt the correct Auto program to be selected). The whole reason for the semi/auto mode is to prevent the pilot from having to select a program on the short time between being locked up and getting launched on. Setting program 1-4 is a deliberate pre-emptive decision.

okay, that doesn't answer the question and has factual errors. First, you don't need an MWS to tell you that an SA13 has illuminated you with its ranging radar shortly before it fires. What it does allow you to do is to react by banging out alot of flares, preferably before and during the SA13 firing. It's not a common combo (single target ranging radar paired with VSHORAD IR missile), but it does allow the aforementioned defeat mechanism to occur. Second, the DCS F16 has the following programs (per the CMDS_ALE47.lua): 1-4 on the PRGM knob MAN_1 = counter(), MAN_2 = counter(), MAN_3 = counter(), MAN_4 = counter(), PANIC MAN_5 = counter(), BYPASS on the Program Knob MAN_6 = counter(), Old generation SAM AUTO_1 = counter(), Current Generation SAM AUTO_2 = counter(), IR SAM AUTO_3 = counter(), These 3 are currently not listed as discrete programs and may be added later AUTO_4 = counter(), AUTO_5 = counter(), AUTO_6 = counter(), My count is 12 programs with 9 usable. As Steelfalcon helpfully points out AUTO 1-3 are the programs that Semi and Auto should currently choose from when responding to a given radar threat. Now, back to my previous question please.

Has anyone been able to get CMS semi or auto mode to dispense the "Current generation radar SAM" or "IR SAM" programs rather than the "Old generation radar SAM" program? You can program all 3 in the CMDS_ALE47.lua, but I only ever seem to get the old gen program regardless of which track radar has me (Tested SA2, SA15 and SA10 to get the oldest and newest gen SAMs in-game.). I'd expect there should be a table that stipulates which tells the CMDS which program to run for any given emitter. Example SA10 or SA11 track/launch would trigger the 'current' profile whilst SA2 or SA3 would trigger the 'old gen' profile and an SA13 (with its ranging radar) would trigger the IR program. I haven't found anything like this table and wonder if ED simple hasn't yet implemented the logic for it. Anyone else have any different or similar experiences.

Uh, unless I'm grossly misreading you here, post #4 of this thread details exactly how to get what you're after.

Any news on being able to export/import flight plans via a text string in the clipboard or similar? DCS DTC does it really well, but only for the F16. Makes multiplayer mission planning a breeze.

+1 for various placement options. If the skin being used is a US Army standard drab skin, then yeah it's probably only going to be a low vis tail number, but the ability for high vis ID numbers on the sides of the forward avionics bays would be great for MP particularly.

LMC is fine if you understand that you should be looking to cancel out drift on your target rather than use it to move onto a target. I'll usually use the normal slew or slave-to mode to get in the vicinity of the target and then click on LMC when it is on the target itself. Using a gamepad thumbstick for your slew helps (in general). What this game doesn't model at all is that changes in lighting or other objects entering the scene can screw with auto-track functions on TPODs. If that was modelled, everyone would be saying how rubbish auto-tracking was. LMC has the advantage of using the CPG's brain to keep the desired target centred, so things like smoke or bushes moving in front of a target won't break the track.

Problem: Currently in MP the pilot needs to approve the CPG's request to assume control via a dialogue on the screen that requires use of the mouse. This generally requires taking a hand off the cyclic which is not ideal, particularly at low level or in VR where wrangling the mouse cursor can be problematic. Proposed solution: make the pilot's 'request control' command ('C' by default) also approve any active request for control by the CPG. If the request is in error then the mouse can be used to deny it. Caveats: I am aware that the assumption of control behaviour can be changed per-airframe in the ME, so please do not raise this as a solution. This request is about streamlining the process when the pilot must still approve any request for control as per the editor setting.