J20Stronk

Waypoints in A/G mode do not drift in relation to NAV mode. They will always be in the exact coordinates as if there were no drift. This is mostly noticeable when you use FAST Align and do not enable HNS, but this happens regardless of Alignment mode used during startup. If you wish to see this for yourself you can: Place a JF-17 with bombs or any INS/GPS weapon Perform a cold start and align using FAST or GC (GC will take much longer to drift, but the bug will still be present with that alignment) Do not enable HNS so that the INS can drift Select a waypoint and a bomb in AUTO mode/ IAM in TOO mode Switch between A/G and NAV mode, watch as the Waypoint shifts between its true (A/G) and INS (NAV) position.

Really? With a modded loadout, spacing seems to be a non-issue. Is that only when you use Dual Racks on both pylons of one wing? If that's the case, can you guys make it so that you can carry Dual Racks on the inner pylon, but only if you don't have Dual weapons on the outer pylon on the same wing.

You don't need the IN RANGE cue to fire the BRM. They have a range of about 7.2-7.5nm when fired @ ~290kts, 9000ft. If anything, the IN RANGE cue seems to be the thing that is broken because the rocket definitely has more range than what the cue is showing As far as that WMD7 lasing bug goes, I think it has to do with the 3D model being messed up. If you haven't noticed, the 3D model of the pod doesn't follow the direction you are looking inside the cockpit. In fact if you cage it, it looks straight ahead instead of closing backwards to protect the lens. And when you overfly the point your are looking at, the TGP model will snap to look up, which I think is the root of the problem.

That is the INS/SHARS drift.

It's a limitation due to how the DIS engineers coded it. https://forums.eagle.ru/showpost.php?p=4134973&postcount=3 The gunsight from what I gather should not jitter this badly in the real plane. Nor should it have such a large delay between target and reticle position, giving you taget solutions that are WAY off. Modules like the F14 or even the MiG 21 have much better target pos. predication radar sights and they don't jitter like it does on the JF-17. IMO the gunsights need an overhaul.

The TGP 3D model does not properly rotate and will snap upwards when you overfly the target. Could these two issues be related?

Did you plug the suit too?

Deka pls?

This started happening right after the SLAM was put on the Hornet. As you said, the AKG reneder worked perfectly before. GJ ED, please keep breaking more stuff that ain't yours.

I like the new changes. Trade in around 2% kinematic performance so that it's even closer to the real thing, but with a much better CCM and Notching resistance? Heck yes. Just, please revert the battery to 100. I'd love you all long time if it gets in the hotfix later this week.

Title. Edit: ok, let me be a bit more clear. in my testing, The SD-10 now has the exact same kinematic performance as the AIM-120C. It does have a slight acceleration bonus over the AMRAAM in a straight line, but nowhere near as good as before. Energy retention appear to be the exact same as the 120; the old SD-10 retained energy better. The PL-12 still has the old FM, which is the exact same as the old SD-10 so I was able to test the "old SD-10" with the new one this patch. The new SD-10 also "dies" 20 seconds sooner than the older one, which matches up with the AIM-120 battery life. This is .acmi of a straight line test, a long range shot test against a maneuvering and a long shot non-maneuvering target. I will say, the SD-10 is much less susceptible to notching and chaff, which is appreciated. But I believe we should have its old kinematic and battery life performance. EDIT 2: Ok, kinematics-wise it's only slightly worse than before. I'm sure the new AP guidance had something to do with it since it does seem to want to make it pitch down a bit making it fly into denser air in a straight line; Old FM kept its nose high. When actually engaging targets, it's not too far behind the old SD-10. Still, Bat. Life/Op. time should be back to 100 sec. Tacview.rar

Hopefully the AGR-20 scheme, once implemented will fix this issue

Pro tip for dogfighters: the optimal AoA appears to be around 10° to 11°. With no external stores, full CMBT afterburner I was able to keep a horizontal full aft stick turn at 8Gs while maintaining 405kts airspeed and 20.8 deg/s turn rate, so long as AoA was around that region. While I don't have EM charts to confirm this, it would appear that this is the point in the graph where Drag and Lift meet; giving you the most optimal turn. AoA higher than 11° just exponentially increases drag without granting much lift, so your best bet would be to keep the AoA below 12° at all times when dogfighting. There is no "best turn speed" with this plane (or with any plane, really). Depending on your loadout and flight conditions it can range from 400kts to 480kts. Much like landing, fly with AoA and match the speed with it.

Set the TGP to SLAVE with MFD U3. It'll slave to the SPI or WP if there is no lock.

As it turns out, if you detect something in RWS or VS and use S2Left to switch to TWS, you will see the hit in that mode and be able to lock onto it without the radar scanning for it. That is a different problem though, since a raw RWS hit, or unranged VS hit should not be inter-usable between modes Back on topic; in my experience with other modules with TWS, all unbugged targets always moved in real time as if you were locking them in SAM or STT. Hi-fi modules with half decent modeling would of course receive updates every time the radar picked the target back up again. The JF-17 is the only plane in which TWS basically acts as an RWS, but with the added benefit of knowing where the target is heading. Unbugged contacts never move on the display, they always appear on the position where the radar spotted them/ re-scanned them.

DMAP is not affected by MFCD Day night switch and will be at full brightness at default MFCD BRT value in Night Mode. If you were to fully turn down MFCD brightness using the BRT rocker on the bottom left of display, MFCD will still be too bright and desaturated to be of any use. Turning contrast up even one notch with the CONT rocker makes the map hard to read and blurs the MFCD symbology. Pics for ref included for: - Default MAP brightness in Night Mode. Default BRT/CONT/SYM - Lowest BRT setting, Default SYM/CONT - "Best" settings I have found in this scenario. -10 BRT, +1 CONT, Max SYM. Note the map has lost fine detail and MFCD SYMbology 'blurs' and bleeds into the map texture.

No no, I'm talking about when you have no bugged targets while in TWS. I believe every detected contact should move in real-time just as they do now if you were to bug them as HPT/SPT, minus the aiming cues and HPT info, without the need to do so. At least, that's how TWS works in all other aircraft. As it is right now, without any bugged contacts, TWS just displays trackfiles as if they were hits in RWS with the addition of a heading vector of the target. It's not "Tracking While Scaning", just "Scaning" really.

It's crazy how much people haven't talked about this. TWS in the JF-17 for the moment displays un-bugged contacts as hits similar to RWS but with a heading vector, rather than an actual moving trackfile. Now, I don't know if it actually is like that in the real aircraft, but this isn't really "tracking while scanning". I imagine every contact in TWS being displayed as if they were bugged as HPT/SPT, minus the aiming symbology. Targets would move around the scope in real time and update position and vector as the radar sweeps over them. And as you make maneuvers, the radar should shift the position of contacts based on your movements without the need to re-scan them to find their next relative position on the scope. That is how TWS mode works in the F-teen modules, even in the FC3 planes, albeit with perfect accuracy due to their lo-fi nature. Is this correct behavior, or is TWS mode not fully implemented yet?

There's your problem chief. You need to activate jamming by hitting the CM switch depress, default bind is "E". It should say JAM when it is ready to jam, and JAMMING when it is actually doing so to an emitter.

That seems to be it. No more point lighting from the MFCDs, Warning/Advisory and panel lights. I assume the floodlights will be baked light maps too, which means you probably won't be able to move them.

So in the changelog, the SD-10 now uses the AIM-120 scheme. Could you elaborate what this changes besides preventing the F-16/18 RWR from receiving TWS launches? Does this make it behave like the current 120 in regards to losing lock? notching, spoofing with chaff, etc. Does it affect its loft profile? Does it affect its kinematics and booster performance?

Can we get an ETA for when the remaining cockpit textures will completed? what is textured looks pretty darn good, but the stuff that isn't done stands out so much, especially with Dark Cockpit retextures.

It still skips the BIT if I attach the pod when re-arming. If the Pod was not pre-attached in the ME and I load it before performing a cold start, the BIT will be skipped If the pod was equipped in the ME, it runs the BIT normally.

Even with ccm_k0 set to 0, the missile still refuses to guide properly... SD-10 notch with Chaff invulnerability.zip

Just for shiz and giggles I modded the SD-10 to have ccm_k0 = 0, and the missile still refuses to track properly in pitbull. I tested these against a pretty large target, the J-11 and it seems that the main issue isn't so much that the missile is too vulnerable to chaff. Rather, i believe it's too vulnerable to notching. Here are some .acmi of these tests, as you can see the missile either overcorrects or decides to fly directly to the last known location, in which there is no chaff, once it is notched. Again for a pretty big target, the J-11 had little difficulty evading this missile via notching with virtually useless chaff. (remember, ccm_k0 is set to 0, meaning complete immunity to chaff.) The SD-10 is VERY EASY to notch, chaff is not needed to spoof it. SD-10 notch with Chaff invulnerability.zip