tae.

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