tae.

Oh, interesting. Thanks for helping confirm and the extra testing!

I figured it out - at least what has been affecting me. In the 5 years I have been playing, I have never been gaslit by a bug so hard seems that a few of the missions and multiplayer servers have Unrestricted SATNAV enforced off, and it somehow affects even BLUFOR JF-17s. I had this enabled in some but not all of the missions I had locally, and I'm sure I've flown on multiplayer servers with it both enforced and not. Which explains why I have had such trouble figuring out what it was, and why it seemed to rear its head at complete random. Hopefully I am correct in viewing this as a bug? It seems to me that it is.

Hello, After many, many (way too many) hours of trying to figure out why it felt like the JF-17 GPS guided weapons seemed to break at complete random in my sorties, I have finally found the issue. Summary The "Unrestricted SATNAV" option does not work as intended for the JF-17. As I understand it, the intended functionality for the "Unrestricted SATNAV" option for missions is supposed to deny REDFOR the capability to use GPS, limiting it to BLUFOR coalition aircraft only. Unfortunately it seems that in the current patch, if "Unrestricted SATNAV" is false, ie. no GPS for REDFOR, this will actually also affect all JF-17s on BLUFOR too. I have tried many countries within BLUFOR and none seem to provide the JF-17 with GPS functionality, not even USA, unless "Unrestricted SATNAV" is enabled and enforced. If this is intended then obviously this report can be discarded, but I don't think it is intentional based on how this mission option is supposed to work, and how it works with other aircraft in DCS. How to Reproduce / Check 1. Edit the "Unrestricted SATNAV" option of any mission to False and make sure it is enforced by the mission. Alternatively, head to Settings>Gameplay and untick "Unrestricted SATNAV", and play a mission where "Unrestricted SATNAV" is not enforced to true. 2. Create/spawn/play as a BLUFOR JF-17 in the mission as a hot or air start (HNS set to INS+GPS automatically). Alternatively cold start but ensure HNS is turned on during start (set to INS+GPS). 3. GPS will be unavailable - JF-17 seems to INS drift and GPS guided munition drops will be inaccurate (observing LS6 weapon drops is a quick way to test). Workaround / Comments The issue can be easily worked around by ensuring that "Unrestricted SATNAV" is enforced to true in any mission featuring BLUFOR JF-17s. However, this is not an ideal situation for missions where REDFOR should have the restriction, but BLUFOR should not. Additionally, it is possibly enforced off for many online servers, missions and end users accidentally, leading to ambiguous issues with weapons that aren't immediately clear - I personally spent many hours unable to reproduce this issue (everything working fine), and an equal amount puzzled as to why I suddenly missed everything I dropped following the same procedures, due to flying many different missions and servers in my DCS playtime - some presumably having the option enforced off, and others having it enforced on. Track Files Please see attached track files, and short description of each one below: jf17_USA_unrestricted_satnav_off: BLUFOR/USA JF-17 dropping 2xLS6-500 and 4xLS6-250 on 6x BTR-80s, in TOO mode via. WMD-7 point tracks. All 6 weapons are inaccurate/miss indicating limited/no GPS and/or INS drift. jf17_USA_unrestricted_satnav_on: BLUFOR/USA JF-17 dropping 2xLS6-500 and 4xLS6-250 on 6x BTR-80s, in TOO mode via. WMD-7 point tracks. All 6 weapons are pinpoint accurate indicating GPS is available. Cheers jf17_USA_unrestricted_satnav_off.trk jf17_USA_unrestricted_satnav_on.trk

Interesting. I did end up testing dynamic slots yesterday and, frustratingly, they also work fine. It seems to me that whatever was causing the issue for me was inadvertently fixed in one of the last few hotfixes maybe. I went from completely missing every GPS guided weapon (by huge margins, like two blocks over) to now hitting everything with pinpoint accuracy, without changing anything that I did. As per previous replies, if I find anything else out I'll be back with more info but for now I have spent a lot of time trying to "break" the JF-17 again and I somehow can't anymore, the HNS seems to work perfectly again for me even on a FAST align.

I don't think the devs know, I am still doing a ton of testing trying to locate and be able to reliably reproduce the issue. I believe it may be something to do with JF-17s spawned via the new dynamic spawn system, but I am not sure yet. It just so happens when I saw this thread and wrote my initial messages in here, that I was flying the JF-17 almost entirely on an MP server using dynamic slots, which led me to make many incorrect assumptions and jump to conclusions. I have tested just about every other combination of parameters and can no longer reproduce the bug (singleplayer cold start, hot start, air start, and MP static slots). I have had perfect success employing JF-17 weapons in all of these tests - in fact, the weapons are actually too accurate! In total I have probably tried reproducing this bug for about 20-30 hours with no success. I have only had issues with this when flying from dynamic slots in MP, so that is what I will test more next. I should have time to test further either today or next week, but can you remember if you flew from dynamic slots in MP? It would be very helpful.

Another update after further testing. I tried in both singleplayer and multiplayer doing an air-start - it is impossible to reproduce the bug that way (and at this point I am nearly certain that it is a bug!). So, HNS works fine with air-start but NOT cold start. I am currently unsure about hot starts, needs tested. I even tried to force heavy drift situations by pulling lots of G for 30 minutes straight. I did this with the HNS off (INS only) as a "control" and then with it on, on an air-started aircraft. With HNS off it gave results I would expect with a cold-started plane having the issue - in other words, it sort of confirms that HNS doesn't work from a cold start. Meanwhile, leaving the HNS on meant that after 30 minutes of pulling G, then dropping weapons, they are still pinpoint accurate. Pinpoint accuracy is what I would expect with cold and hot started aircraft, but at least for cold starts, there is some kind of issue that results in drift even when GPS is available and turned on, rendering most of the weapons inaccurate or useless almost immediately on FAST align, and after a slightly longer time on GC align (30+ min of flying maybe several metres of error, 60+ min you can expect completely unusable accuracy). Additionally, I would like to supply a track file or something helpful like that, but as I understand it, cold-start requires ground crew menu in JF-17 which will immediately desync/break the track. Furthermore, the bug takes a minimum of 30-60 minutes to reproduce, I feel like even if track file worked it would be impractical. If there is anything I can provide that is not too cumbersome that would help in fixing this then would be happy to try. Edit: tested hot starts too (HNS already enabled, just like in air-start) and cannot reproduce the bug. For whatever reason, HNS is inoperative specifically on cold started JF-17. Should also add that so far, I have only been able to reproduce the issue in multiplayer, have not tested cold-start in singleplayer. Edit Edit: After way more testing I am having trouble reproducing even in multiplayer where it was happening fairly frequently. I am not doing anything different but I am trying to figure out how to reproduce, currently everything is back to working fine for me, which is quite puzzling. If I figure out what was causing my issues previously I'll post a separate bug report. Right now everything is working again even with FAST align.

After some further testing it really does seem to me that INS drift is not corrected whatsoever by HNS/GPS for GPS guided weapons and potentially all weapons in the current patch. Doing a GC ALIGN seems to *help* to circumvent the issue (as INS drift is slowed down), but the core problem is still there. I tried dropping a few different weapons after multiple flights in the same aircraft, on one GC ALIGN and with HNS ON set to INS+GPS - the accuracy gets progressively worse and worse each flight, to the point of the weapons missing by huge margins by the 4th-5th flight.. Would appreciate if others could test too and report if they are having the same issue, just to make sure it's not me doing something wrong although I can't imagine what that might be. Otherwise if somebody could explain how this could still be classed as correct behaviour that would also be nice, but right now it seems to me that it is a bug. Just to clarify - doing a GC ALIGN and heading straight to targets appears to work well, but accruing any INS drift, whether on FAST or GC ALIGN, doesn't seem to be corrected by the HNS at all when employing weapons. If I have time, I will try to test more and see if I can figure out just how much is affected, because maybe it is more than just the weapons that are affected. Edit: After reading some other recent bug reports on here, it seems it may also be several issues compounding on top of one another, I don't really have the time to test all of these combined (point track causing inaccuracy, PP points being several metres off for some reason). No matter what, something is very messed up with the weapon accuracy unless you do a GC ALIGN and go straight to your target with zero messing about - even then seems to be questionable sometimes. Would be great if more people can test this out.

Do you, or anyone else for that matter, know why we have to do a GC align for GPS guided munitions to work correctly though? Surely if we have the HNS active (INS+GPS) then we don't need to worry about INS drift, as the GPS will correct it for us. Yet it does seem that doing a FAST align can result in very bad accuracy with the GB6 and LS6 bombs. I don't know any better, so it feels like more of a bug without an adequate explanation, which I haven't been able to find yet.

I think so yeah, another good point.

Just because you are unaffected does not mean everybody in the community is unaffected. Many software rely on the correct date being set to function properly, including some important software on my PC that I just simply don't want to have to fix 5+ times a week when I want to fly the F-15E in DCS. There is also some stuff that is impacted badly enough that it is not working at all when it is needed to. Setting the date back and forth so often is not feasible solution for me at all, so I cannot do it. And I also just shouldn't have to do it.. it's not acceptable. Glad you can enjoy the Strike Eagle, but please at least understand that not everybody is in a situation where the workaround is feasible. I cannot play.

See my reply above yours for a temporary workaround!

I have learned of a workaround that allows you to set laser codes again in the F-15E as of the latest patch, it was actually somehow semi-fixed, and I thought some of you might want to know. All you have to do is set the codes one station at a time instead of with the "All" option. DO NOT use the "All" option on the menu when setting them - this is 100% still broken, it will set the first number to a "0" and if you press this YOU WILL have to rearm to set the codes back to 1688. Oh also, any time a rearm happens it seems to set the codes back to 1688 now, so you will need to set them individually on each station after every rearm. but it does work - tried and tested in MP dropping on 1518 on all stations tonight. Hope this helps someone until it's fixed.

I can confirm after some testing that I am seeing the same issue with JDAMs loaded on L1 and R1. They always behave very oddly, losing a lot of energy and falling short of target or exhibiting strange behaviours. Every other station works just fine.

Thank you so much for adding this much requested feature, this is a huge game changer. I can't wait to see what the community does with this new functionality.

Indeed. I should add that I raised a duplicate bug report for this issue on the official Discord, and it got a little bit more attention. The unit heat situation has improved a lot since then, but there are still some outstanding issues, in particular certain units still show completely cold, such as trucks. This is seemingly a texture issue which will hopefully be fixed over time as more vehicles are updated to the new FLIR.

Hello, I have been playing with the F-15E radar and its ability to detect, lock and burn-through jamming contacts, and after a little experimentation I believe that there is an issue (or perhaps several issues) when trying to burn-through jams. To preface, it is my understanding from the manual that a jamming contact can be locked, placing the radar into HOJ track mode. In this mode, only the contact position is known, while "the range, closure and altitude data will be constantly changing until the burn-through occurs". It is also my understanding that after a burn-through, the radar will transition to JAM track mode, meaning that jamming has been detected from the contact, and so the data provided may be inaccurate (range, closure, altitude). With that out of the way, I found some sort of strange and unexpected "delay" in the HOJ to JAM transition. I was able to find the true burn-through range using LR BST which will only lock once burn-through has happened, and then comparing that to if you hold a lock on the contact instead in HOJ, found that the transition to JAM always occurs at a substantially lower range. This is even worse in TWS, and although I would expect lower burn-through performance in TWS, it is seemingly impossible to use TWS to burn-through jamming in any practical sense with the way things are currently. On that note, I would like to make a comment that the radar performance related to jamming seems very over-modelled in general, especially if you compare it to other modules in DCS. Much less powerful radars are able to burn-through jams at equivalent or greater ranges, leaving the Strike Eagle in a pretty poor position to deal with jamming at all, especially with the issue mentioned above. I'd also be happy to listen to an explanation to why these issues exist is if there are valid reasons, as I'm not operating from an "all-knowing" position. I'd especially like to know why the HOJ to JAM transition is so delayed, if it is indeed not a bug. At any rate, please find the following track files attached, where I used a JF-17 with the jammer set to ALWAYS ON starting just over 40 nm away: F15E_LR_BST_BURNTHROUGH.trk - Attempted lock of JF-17 with LR BST. Burn-through and Lock in JAM track mode achieved at 20.2 nm. F15E_STT_BURNTHROUGH.trk - Locked JF-17 from RWS into STT/HOJ. Burn-through and transition to JAM track mode achieved at 15.0 nm. (Note: this was actually a fairly GOOD result, this can be as low as 9 nm) F15E_TWS_BURNTHROUGH.trk - Locked JF-17 from RWS into STT/HOJ, transitioning to 3HDT TWS. Burn-through and transition to JAM track mode achieved at 7.0 nm, although the track appears to be very unreliable. F15E_LR_BST_BURNTHROUGH.trk F15E_RWS_BURNTHROUGH.trk F15E_TWS_BURNTHROUGH.trk

If you added the external fuel tanks with a re-arm, their weight is not being calculated at all. This bug is not fixed yet and should be fixed in the next patch as Smiley mentions above. The current workaround is to have the external fuel tanks on the jet at the start of the mission. If that's not a possibility, then recommend to not use them at all. A fun little side note, is that after flying the jet for almost two weeks with this workaround now, I can pretty confidently say it has been a bug since release. The jet handles WAY differently with the workaround. A lot less "crazy" performance, and much more in line with the other aircraft in DCS.

Don't know what to suggest, have done what you are describing hundreds of times now without issue - maybe post some screenshots of what your ARMT A/G page looks like on your second sortie. The only thing I can think of is one of the following: - You are taxiing the jet before hearing "Rearm Complete" from the ground crew, this is known to cause issues in many modules. - You didn't set up the new ordnance to the program before trying to use it.

This is a funny one - I only get it when I am flying the jet solo. If I have a human WSO, then this bug never occurs for me. That would lead me towards the conclusion it is something to do with the new RWR sync code.

If you are using the same program, then try to deselect and reselect the pylons you wish to drop ordnance from. If that still doesn't work you may need to use prog2/3/4. There are some edge cases where it gets a bit grumpy about re-using the same program, at least from my experiences. Failing that I would make sure that you are in parameters for weapon release with CDIP. If you are out of parameters, pressing and/or holding the Weapon Release will transition you to AUTO until you are within parameters or release the button. It is similar in operation to CCIP in the Viper.

It's pretty normal. Only the "dumb" stores won't auto-ID. Note that your air to air missiles do for example, as they are "smart". In the future I think "smart" AG munitions will also auto-ID, but we don't have any of those yet. A dumb bomb has no way of telling the jet what it is.

Yes it is necessary. The jet cannot automatically ID the stores and must be told what they are.

It is an early access product. It was your choice to purchase it during the early access period. You have purchased an unfinished product. There are always going to be bugs and issues with any unfinished product. In the future I advise waiting several years and purchasing products when they are finished if you generally find bugs and problems to be a dealbreaker. Right now you bought a half-baked cake fully knowing it was a half-baked cake and are complaining that it tastes like a half-baked cake. The only thing I think is odd/needs changing here is that the product is not listed as Early Access on Steam. Which is a little misleading for anyone who does not take their time to properly research before purchasing. If that was the case with you, then your frustrations make sense. The reason it will take years to "fix" the module is because it is still in development. It still requires years of development, which is clear for anyone to see (again, after a little research) and they did not really attempt to hide this at all. Furthermore, it's clear that RAZBAM are working hard to fix any bugs and problems. This is abundantly clear to anyone who reads the patch notes or pays a little attention. Unfortunately as a third party developer they can't just sling out patches willy-nilly, they must adhere to a monthly patch schedule outside of extremely severe issues. Also, €60 is not the full price. That is a discounted early access price.

Ran into this a couple days ago with a human WSO. Not sure how to reproduce, or what caused it. However, if you turn the TPOD off and back on, it seems to resolve the issue.

Here is a track where the final jettison sent me forward at Mach 66.47, sending the jet approximately 27 nautical miles away. Note that the jettison prior tips the jet back onto the rear gear noticeably. 11:10am onwards in the log is where that flight began. dcs.log F15E_FM_weight_bug.trk