Py

The ellipse is pointing the radar to attempt a HMCS boresight lock, but the missile seeker is still caged and doesn't slew to the target until you get a radar lock (in slave mode, the default). Holding Radar Cursor/Enable temporarily swaps modes (to bore mode in this case) which slews the actual missile seeker, so you can fire a sidewinder immediately without a radar lock just by looking at the target. Sometimes it takes a few seconds to get a radar lock so this can be a lifesaver. Also the AIM-9X can be fired at a wider angle than the radar can slew, and they will get no radar lock warning.

By something active I mean when is the range update from AGR triggered? A) Any time the TGP points anywhere, AGR sweeps it and updates range B) When a position is area tracked? point tracked? Also must the AGR scan height be manually adjusted to cover the point targeted by TGP?

Few questions: 1. How does laser vs radar vs PP accuracy compare? 2. And is there something that needs to be actively done to range with ground radar, or is it automatic? 3. Is the precision maintained if lased/GRd points are saved as markpoints?

... at a certain USB polling rate. If you've ever used an extremely crappy mouse, it's actually quite noticable. Decent ones use a polling rate of 500 Hz or higher so it feels smooth regardless of the montor refresh rate. In regards to trackIR, if it's using raw position data then yes syncing it to the monitor refresh rate will eliminate inconsistant update timing due to aliasing, but personally I haven't noticed a difference using G-sync. If the trackIR software is doing things properly then it should be interpolating/extrapolating the instantaneous position at the frame time and this won't be an issue (but I have my doubts).

I also spent a lot of time trying to figure out why a simple export script was ruining my FPS, eventually I found the problem is some functions in the aircraft export files (that in my opinion should not be enabled by default). Check the export script for each aircraft you fly for a section like this: Eg for F-16 in Scripts/DCS-ExportScript/ExportsModules/F-16C_50.lua if LoIsObjectExportAllowed() then -- returns true if world objects data is available if LoIsOwnshipExportAllowed() then -- returns true if ownship data is available ExportScript.LoAircraftInfo(mainPanelDevice) -- Provides a lot of aircraft properties ExportScript.AirportInfo(mainPanelDevice) -- Provides info on the two closest airports ExportScript.WindsAloft(mainPanelDevice) -- Gets winds at the aircraft ExportScript.GroundRadar(mainPanelDevice) -- Reports 2 closest friendlies and 2 enemies (Use in Single Player) ExportScript.AirRadar(mainPanelDevice) -- Reports 2 closest friendlies and 2 enemies (Use in Single Player) ExportScript.IglaHunter(mainPanelDevice) -- Locates closest Igla (Use in Single Player) end end Disabling that section for me instantly increased FPS by a lot and stopped the horrible microstutter.

Could tables be precalculated and interpolated for a realtime approximation? There are many variables, but even a fairly coarse precalculated set of solutions might give significant improvements.

Yes the blue pill uses a STM32F103C8T6 which has 12-bit ADCs. FreeJoy is a really well done project - I've used it to add some 5-way buttons and sliders to my warthog throttle. The 5-way buttons use shift registers and can be daisy-chained, so any number of them only uses 3 pins on the bluepill (+2 for power).

Don't stress about the fuelling part - just practice flying in close formation first until you feel like you can control your position smoothly. Then the refuelling part is just choosing the right position (watch the fuselage/engines, don't focus on the boom). Good luck!

The 'in range' cue for all the GPS guided bombs (GBU-38/31 and CBU-103/105) is also incorrect a large fraction of the time, and bombs fall short. It may be related.

In terms of the pixellation/jagginess, it seems that none of the antialiasing/supersampling used for the main game graphics is applied to sensor images. Real FLIR images look much more smoothed and there is no pixellation (unless at digital zoom scales). Another thing to note - make sure your DCS setting for "cockpit displays" is set to 1024, and remember that unless you have one of the "every frame" options selected your PNVS/TADS etc will be at half your framerate which makes a huge difference when operating at night (unless you have great framerates).

It's set mechnically, in reality it can't be changed in the air (for paveway II -> GBU-12 etc) The newer ones with electrical interface probably can, but these have no electrical connection to the plane.

Keep the curve linear and no deadzone, it's more adjusting the force settings and force bias ("NASA sensibility" they call it) to your liking. Have a look at https://forums.eagle.ru/topic/258187-fssb-force-and-curves-settings/

There isn't just a single filter, and yes there will usually be one that filters relative 0 to the aircraft as well as the one you mentioned. All leakage from TX to RX, scattering from within the aircraft eg the radome, and reflections from the ground perpendicular to the aircraft (eg from sidelobes) will have no doppler shift.

You're probably entering degree/min/sec cordinates while the jet uses degree/min/decimal min format. Left Alt + Y to change formats in the F10 map screen. The correct formt should have a decimal point not a ' before the last set of digits.

60/120 FPS are US-centric framerates, in countries with 50 Hz power cameras should run at 50/100 FPS for consistent brightness when using mains-powered lighting. That doesn't apply to trackIR though, as it provides it's own IR lighting (with no flicker). It does seem likely that the asynchronous updates of camera position from trackIR vs frame render time are causing stuttering, as smooth head motion is being chopped up into uneven steps for display. Locking display refresh rate to 60/120 Hz *should* fix it, if that's the only cause, but it shouldn't be necessary and removes the benefit of g-sync etc. I can think of two ways to fix it properly, one by naturalpoint (doubt they will bother), and one by ED: 1. Change trackIR position reporting from a fixed rate set by the camera, to a request from the user (eg from DCS). The software already does motion smoothing so should be able to give interpolated/extrapolated position at the exact render time, eliminating uneven motion even if the frame rate is varying. 2. DCS could get the polled 120 Hz data and do it's own motion smoothing/estimation, then use the position estimated at the time of render. That would probably need to be done in a separate thread, but would be pretty simple to do. ED already has a huge TODO list, but if this feature can be added to the new multi-threaded engine they are working on it *should* solve the issue. I think this isn't a problem for VR because steamVR etc is already doing the motion smoothing and extrapolation of position data before providing it to DCS.

I can't comment on how it feels now, but have used both a MS FFB2 (force feedback) in the past and a FSSB-R3 Lighting (force sensing, like the real F-16) currently in DCS. It would be technically possible to emulate a force sensing stick with a FFB stick, but I don't think the MS FFB2 provides the needed data. It would need to always force the stick towards the centre, then report motor current instead of stick position to DCS. The FFB is also a bit wobbly around the centre which would kind of ruin the feel. So if the manufacturer of a more modern FFB stick makes the driving current available to DCS, it would be possible for ED to make it feel kind of like a force-sensing stick. But without that data, there isn't really anything they can do and it will have to act like a spring-centred stick with no feedback from the plane.

What doesn't make sense to me is only allowing a single GBU-12 on the inner pylons (in DCS). Is that a real limitation? 3xMK-82 or 3xCBU-87/97 fit, so why not 3xGBU-12?

I also had this problem, no track unfortunately but it was also in the Persian gulf on a Tarawa, moving at 15-20kts I think, light wind (DCS "stable"). I spawned in a Huey, and when trying to start up it began bouncing around even more wildly than usual, then sliding back, then seemed to flip back and hit the helicopter behind and exploded. I've spawned in the same spot many times previously, and before the last stable patch it was never this bad.

The changes have great potential to improve the realism when all missiles use the updated system, and will allow better ECM modelling in the future. So firstly well done to ED for implementing this. It's expected that things will be a bit buggy at first, but closed beta should really find major problems like this. Even then, it was reported in open beta and there is really no excuse for pushing it to stable. ED's improved testing procedures seem to be slipping back to the old ways, making the stable version pointless again. PLEASE ED, hold back stable releases until major issues like this are fixed in open beta.

Point/area track from a TGP or GMT radar lock are just used to direct the maverick seeker to look in the right place, the maverick must lock with it's own seeker before it can launch (based on image contrast except in force correlate mode), and then will follow the target by itself even if it moves. So you can fire several mavericks at different targets in one pass, even on a moving convoy. It's possible that the lock will flip to another nearby target in flight eg if your targeted tank drives close to another tank though.

It was a good idea to create that thread to stop the CONSTANT "when is the update" questions... But 90% of the time it just says "TBA" which kind of defeats the purpose!

Yes please!

You need to set each one separately, use the STEP button to switch between them.

Also try alt-enter to go fullscreen. I get a weird 1 sec chugging if I have alt-tabbed to check something else, but alt-enter fixes it.

Oh wow. <deleted angry rant> The current price is 24.99 which is the same as I paid for the preorder discount including the additional hornet discount. So at least for me it's not cheaper, but for those who bought it without the hornet, it would have been cheaper to not try and support ED by preordering. It is good of them to offer discounts...but think about things like this first! I wish ED great success, but every time their PR reminds me of the phrase "snatching defeat from the jaws of victory".