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

I was just able to reproduce this PURELY on the ground by doing the following: 1. Rearm with just three fuel tanks (wings+centerline) 2. Emergency Jettison 3. Repeat 4-5 times If you do it more than 5 times the flight model will break so badly that you will black out on the ground and the jet will explode and be catapulted many miles away. Will post track shortly.

I tried several alternative methods to reproduce this bug, including: - Turning on Unlimited Weapons and repeatedly dropping or jettisoning stores - Rearming and emergency jettisoning immediately on the ground repeatedly before flying Unfortunately these "shortcuts" do not reproduce it, and it seems to only happen after you do things the "real" way as seen in the tracks above: Takeoff with a loadout, drop/jettison it, land and rearm, then repeat. Each flight will gradually break the flight model more, until it eventually becomes unstable enough to cause over-G / pilot blackout / departures from flight etc. With an average loadout it will not take more than 5 flights before it becomes very noticeable.

Something is definitely causing more weight to be shaved off from the aircraft after weapons drops or something similar. Me and WSO did 3-4 sorties dropping GBU-24s, each one increased the airframe performance gradually and substantially. By the 5th takeoff, we could go 90 degrees nose up with 24,000 lbs of fuel and 3 GBU-24s onboard, and easily accelerate to Mach 1. In level flight we could get from 300 knots to 600 in just 2-3 seconds. Felt like we were in Ace Combat. We didn't last much longer because the flight model goes out the window, so we got into an uncontrollable pitch oscillation and I blacked out permanently, forcing the WSO to eject us. tl;dr, yes there is definitely something VERY messed up with the flight model right now. My initial thoughts are that dropping weapons is subtracting more weight than it should, but it needs more testing.

Can confirm, only nozzle position and afterburner show on other F-15Es, the multiplayer sync on the engines seems to have stopped working.

This happens to us whenever my WSO gets a lagspike and we are in any kind of maneuver. 2 G on my end will turn into 12 on his. We have "bent wings" on his end nearly every single flight, even when my maximum pulls are no more than 4 G for many of those sorties. WSO re-slotting back into the aircraft fixes it most of the time. The issue is when the WSOs "damage model" syncs back over to the pilots..then you're in trouble. That has also happened a few times.

Would like to make a correction, it seems that it is not directly related to the copy/paste function, and that placing aircraft normally can also cause a crash to desktop.

BUG Using the copy/paste function on aircraft units in the Mission Editor when around 100 to 110 aircraft are in the mission causes a crash to desktop. Placing aircraft normally does not cause a crash to desktop, only using the copy/paste function does. Upon further testing, I found that placing aircraft normally can also cause the crash. Tested across multiple mission files and even making brand new mission. Happens on both normal and multi-threading client. No apparent errors in dcs.log. HOW TO REPRODUCE Use the copy/paste function to create new aircraft in a mission with 100+ aircraft. EXAMPLES Existing mission: https://streamable.com/0ojgif Brand new mission: https://streamable.com/vd97oj Any more information or testing required please ask and I will be happy to assist.

I am experiencing exactly what the OP is experiencing in my Black Shark, and it was previously a bug in some of the other helos too, but was fixed there. It is 100% still present, and very easy to test and reproduce. I'll even happily create tracks of it, if needed, but I think some have already been supplied.

As far as I understand it, this has been raised as a bug a few times in the past, and has been confirmed as such, simply not fixed. In the older thread, we can even see BIGNEWY confirm it as a bug with no ETA for fix. So, from my understanding, unless someone can please correct me, this has been a bug for a while, is confirmed as such, and we are waiting on a fix for it. I would maybe have expected that to come with BS3, but for some reason that did not happen.

Thank you so much for this, I had just bought the JF-17 and was stuck unable to fly it in MP, now I can. Gonna pay forward some more knowledge for working around this bug while it's still a thing: 1. As long as you rearm first, your first flight the DTC will work just fine. 2. For subsequent flights, the DTC won't work, but you can manually load weapons and tanks on pylons via the LOAD subpage on the SMS page. Hope this helps somebody that wants to play their module.