PetRock

Your link won't load on the airport wifi, so I won't be able to reference it. The behavior of the Man In the Loop (MIL) TDC commands should be that after the link becomes live, moving the TDC should move the small center cross and then return to center after no more input from TDC. This is how you adjust the course of the missile until you get the center cross hair on the target, and then designate for it to lock onto the object. At detection of first input from TDC, it has un-commanded down and left and I have to use "up" and "right" to override it to keep the missile flying approximately in same direction. It is completely possible it is unique to my install, but I have no idea why. Once my net is restored, I will also be doing a local file verification via Steam and try again. I have a NXT Premium and TWCS throttle in a powered USB hub. I checked in Windows after this stream just to double check there was no phantom inputs coming from TWCS that just wasn't showing in game. On a complete "gut-hunch," I wonder if it has something to do with the TDC sensitivity adjustment in the module special settings menu. Additionally, I have used this weapon before without issue, but since the patch in July with the other 802AK and AKG bugs, I haven't tried using them since.

I will update with track files after my net gets repaired.

FYI, I checked the inputs and there were no issues with the TDC axis's. If you watched the rest of the stream, you will see I did check them. After the first missile, there was clearly some sort of issue that I could not duplicate that might be related, but it cleared itself for reasons unknown. Insofar as TDC inputs, it is only the MIL that seems to have an issue - TDC use for radar or hud designation = no problems at all and I even checked the bindings. The input you see in the video clip is the "un-commanded" down and left response I mentioned in my second post. It occurred with every launch even after the first binding check seemed to self resolve. Link to the whole stream: https://www.twitch.tv/videos/1185417537

@uboats I just wanted to update you, here is my twitch stream highlight from when I tried using the 802AKG last week, but I won't be able to upload the trk files until I get my internet repaired after my landlord accidentally cut my cable while trimming a tree... . The 802 had a PP1 in the f10 map, and was launched from there. This happened every other time except the first launch if you want to watch the rest of the stream replay. For this highlighted clip, as soon as I touched the TDC, it would try to dive to the left and I had to fight it via TDC commands, so even when it looks like its roughly flying ahead, its me "driving it" to keep it there. After I got it to lock onto an object, it flew ok from there. Hope this is something to work with until I can upload the track. https://www.twitch.tv/videos/1188937271

Hello, Its late and I will upload a track tomorrow, but I tried to use the MIL 802AKG and there was one major bug and one other odd thing. First, this is per the Chuck manual, but MIL handoff is supposed to happen ~20nm? it happened at 10. Second, the minute I touched the MIL designator with the TDC, it seems like the autopilot stops trying to maintain altitude/attitude and the missile goes ballistic and nose dives into the ground. I will upload my trk file tomorrow and links to my twitch stream showing what happened.

Hello, In open beta patch 2.7.6.12852, known bug: Known issue: C802AK cannot acquire targets (working with ED on the fix) Has this been fixed? Thank you and keep up the good work.

@Vibora Hoping to hear some more news this week after your teaser 2 weeks ago! Looking forward to more tidbits!

Looking forward to seeing this kind of re-evaluation across all cluster weapons - they need it badly.

When they say weight, I think it has more to do with heavier fighter aircraft requiring higher landing speeds and cat shots, where as the heavier, but also larger aircraft with slower flying speeds were not as big an issue.

Hello @Vibora, Looking forward to hearing more about the road to EA. Maybe more info early next month? Hope everyone is having a good end of spring and summer!

@BIGNEWY @NineLine @Wags Any hope that this may get looked at someday? Maybe as part of fleshing out the F-16 RWR?

Bump... @uboats any rough timeline you can share about bringing more options to the weapons list? Thanks again!

I am aware, hence why I asked at end of March if there was anything new to share since the January post on Aerges's FB. (follow the quote post history) If there is something new, great! If not, oh well, but anything new would be nice to hear.

Hello @Vibora, Any news from Aerges? Hope all is well and looking forward to the new module!

@NineLine@BIGNEWY This would be an excellent path forward in re: to how modding can be kept viable going forward. Is there is a way to properly support the Saved Games folder route with more control to input data over core game files?

@NineLine, while I understand you are in the difficult position of trying to justify something you can't go into details about, nor one that you have much decision making authority on, it is abundantly clear that ED needs to engage with the modding community about what they intend to make available in the game and to the community going forward. I highly suggest ED take the initiative and start a conversation with noted community members about what they will be losing in the new design and find real and tangible solutions. As a Community Manager, I am sure you also recognize the damage that the unannounced changes in 2.7 has done to community good will and how that needs to be conveyed to the ED management. I wish you luck in explaining that to them. I will also try and organize some sort of group to start a new thread on the forums here to specifically address this new issue since the original thrust of this thread has blown up into a much larger problem. Having said that, I still need answers to these two questions: Is this something you can investigate and find out or direct the knowledgeable dev to this thread to answer? Thanks, PetRock

Hello @NineLine, While I am a complete amateur at proper modding in the DCS community, I know I have seen the other more serious modders/coders/testers ask for things like some sort of API system or approved limited SDK to play with in the past without much being provided in that direction in recent years. I know @Grimes has been tirelessly advocating for API features for the Mission Editor. Some previously requested tools/features for ME alone that I can think of off the top of my head right now: https://old.reddit.com/r/hoggit/comments/jgz9ub/so_you_want_better_multiplayer_missions/ https://old.reddit.com/r/hoggit/comments/hiw52u/scripting_usage_request_for_info/fwk41h1/ https://pastebin.com/Drh8ugS2 There was TREMENDOUS progress made on APIs and the like in the past when a dev was assigned to core engine/ME QOL fixes, but I understand he has moved on and no one has really stepped up to replace him. This is something tangible that could be done now or soon that would really show that ED wants to extend the olive branch and work with instead of around the user community. A serious discussion with specifics and rough timelines or roadmaps with the more serious modders should be a priority with the changes that have been implemented with 2.7 to find ways to protect the game in the new design while still providing tools for them to experiment and create content with. Also, still looking for answers to my 2 questions posted earlier: A lot of the tools/features/quality of life fixes have been requested for YEARS on these very forums and the people asking for them are known in the community. A lot of low hanging fruit could be had if ED would commit resources to interfacing and working with your already engaged community members.

This would match many other EWAR pods in that they generate a LOT of heat and need cooling.

Didn't you also post that there is a problem with the F-5 gunsight lead calculation as well? Is there a bug that has been introduced in 2.7?

Hello 9L, Well I can't say that this news isn't incredibly disappointing. I know cheating is an arms race and getting into the nitty gritty of what vector the cheating was using could reveal more options/openings for other attacks. However, as others have pointed out, modifying these files already triggered an Integrity Check failure which for the general user base should be what catches people trying to unfairly adjust stuff. I can't speak to how DCS works inside the already encrypted side, but to me, the clearly better solution would be making the existing Integrity Check system more advanced/effective, especially for the mod community, rather than blanket encrypting/obfuscating more of the code. I am not being hyperbolic when I say this approach is going to kill the mod community in DCS - full stop. This approach is far and away one of the most restrictive stances compared to the rest of the industry, even in our niche of flight sims. The A-4E Community Mod could not have been created under the 2.7 encryption scope. The F-5 RWR would still be broken, even if you wanted to play single player and were willing to take the IC bust. The list of things that would be completely broken without the user community being able to even implement their own fixes while awaiting an official fix would be too long to list here. I don't enjoy saying this at all, but the de-facto stance now is that ED does not support modding and will only accept bug fixes that can be submitted via trackfiles. Regardless, I still have 2 questions that need to be answered: 1: is the numerical value in this line of code in the warheads.lua supposed to be TNT in lbs? (underlined/bolded) If not, what does it stand for and how was it derived? warheads["Mk_81"] = simple_warhead(90.0); -- Explosive 45 kg + fragments bonus 2: are these values still present in 2.7 and will there be a review of these values if they are in fact TNT in lbs?

Thank you. I know this isn't going to be super high on the list of things that need to be done right now, especially with the 2.7 roll out, but if there is anything more we can provide or explain, we would be happy to help as able.

So just to begin, I started writing for this post in 2.5.6. With the release of 2.7, we have discovered that the warheads.lua file is now gone/hidden (and with a LOT of changes to the “Scripts” folder) and the values and formatting has been changed so drastically that we can no longer determine where or how the game engine gets the numerical data to crunch the values and make the explosions happen in 2.7 at this time. This may be a good thing if this is the beginning of the process to overhaul the legacy weapons data tables for the incoming new damage model from the WW2 side of the house. Where we are now concerned is that with how opaque the non-encrypted files are now, it is nigh impossible to see how the game engine works and/or what values change what. We fully understand that there have been serious concerns about piracy, but encrypting files just to obfuscate them is not something I can support - I really hope that is not the direction ED wants to go. Because we now can't see what's going on under the hood, I hope that the old 2.5.6 math values that prompted this post were not just carried over whole to 2.7 as I believe they do not take explosive weight vs. explosive power into effect. Recently there have been other inconsistencies brought to light in other parts of the data luas that are no longer visible: We are going to do some more testing of 2.5.6 vs. 2.7 to see what has been changed per the changelog notes of: “Weapons. Fixed Mk-81, Mk-82, GBU-27 and LUU-19 masses, fixed mass of numerous payloads with BRU-42 rack.” When I have more information, I will update this post with what is found in our testing. @NineLine @BIGNEWY @Chizh, any information you could provide would be greatly appreciated and I hope that a lot the changes in 2.7 are just the first part of the process of moving to the more advanced damage model being pioneered on the WW2 side of the house. If nothing else, good luck on this endeavor - it will bring a lot of new depth to the game and I am one of the few who loves bringing home a damaged bird through good systems knowledge. @Iron_physik since you expressed interest from the hoggit thread for when I posted this and also have better access to better primary sources on explosives. FYI I wanted to have more sources to support the values we were seeing for the Mk-80s but with 2.7 coming out, I need to publish this now while we can still go back to 2.5.6 as needed to show our work of what we are finding. Original post for 2.5.6 follows: Before you read any further, I want all to know that this is not an attempt to diminish the hard work of the Eagle Dynamics team – the following is an observation from members of the DCS Hoggit and Operation Enduring Odyssey community that want to bring their observations to the development team in good faith to help them improve the game we all love so much. Bugs and/or errors happen and we are all human. There must be untold thousands of lines of code for DCS and this error has been missed; hiding in the forest of other things that need to be done. During the development work for Hoggit: Syria at War (SAW), the devs noticed that there may be some significant inconsistencies, bugs, or typos in the warheads LUA file located at …DCSWorld/Scripts/Database/Weapons (in 2.5.6). I am bringing these findings to everyone’s attention because I believe it will be critical for the errors found here to be resolved during the development of the enhanced damage models that Eagle Dynamics is working on before it is rolled out to the rest of the sim. If not, due to how inconsistent some of the math/values or assumptions that are used, it may be difficult or impossible to get consistent weapons performance across all systems and platforms in a transparent and objective way in the new model. This was discovered in the process of some of our members building a script to deal with the anemic performance of many of the “dumb iron” bombs, which will be heavily utilized on SAW due to the 80s era theme. It has been commented by the user base for a long time that the “FAB bombs seem to perform better than their Mk 80s series counterparts, but both are underpowered,” so that is where I started looking. FAB Table: warheads["FAB_100"] = simple_warhead(100.0); -- Explosive 45 kg + fragments bonus warheads["FAB_250"] = simple_warhead(200.0); -- Explosive 100 kg + fragments bonus warheads["FAB_500"] = simple_warhead(500.0); -- Explosive 200 kg + fragments bonus warheads["FAB_1500"] = simple_warhead(1400.0); -- Explosive 700 kg + fragments bonus Mk 80s Table: warheads["Mk_81"] = simple_warhead(90.0); -- Explosive 45 kg + fragments bonus warheads["Mk_82"] = simple_warhead(180.0); -- Explosive 89 kg + fragments bonus warheads["Mk_83"] = simple_warhead(400.0); -- Explosive 202 kg + fragments bonus warheads["Mk_84"] = simple_warhead(850.0); -- Explosive 428 kg + fragments bonus From this field, we can see that most (if not all) of the general-purpose bombs use the “simple_warhead” script call for telling the DCS engine to “make this size explosion here” and from the “-- comments,” we can infer the meaning behind the #s value, which is the explosive content of the bomb in pounds. We know it’s the explosive content in pounds because various public documents support these approximate values as seen in the weapons.lua table. [1] [2] With almost all bombs, the total weight of the bomb does not reflect the actual explosive power of the bomb. It is instead the weight and composition of the explosive filler, hereafter referred to as Nominal Explosive Weight (NEW). Looking at the small section of the tables above, you will notice some math errors or incorrect values for NEW – the FAB-250/62 should have ~220lbs of NEW per sources which is not reflected in the data field – it’s short by about 20lbs[2]. Where this gets more complicated is that while most Russian sources list their bombs explosive power in equivalent TNT weight (it is much harder for a not Russian speaker like me to find data on their actual compounds and their relative potency in English language documents), US/NATO weapons are more accessible and they list the name and weight of the compound inside (NEW), so that that is where I continued my research into what the values were of what I was seeing in the warheads.lua table. A lot of the explosive fillers that we know are used in US/NATO weapons are significantly more powerful than TNT for equivalent weight, and while the values of the NEW in the warheads table in DCS are approximately accurate, without factoring in their actual explosive power and instead using just their weight, they are robbing a lot of the explosive impact that these weapons should have. Composition H6, which is the primary explosive filler for the Mk-80 weapons during the DCS timeframe setting has an equivalent explosivity to TNT of ~ 1:1.33 for weight. [3] This means that for the Mk80 series the math should be: warheads["Mk_82"] = simple_warhead((180.0*1.33)=239.4); Even using the values in the table instead of the public record values (197# NEW vs 180#) we are short ~ 60lbs of equivalent TNT weight for this bomb – a not insignificant amount (240 - 180 = 60). Now where this gets compounded and where I think a lot of the community noticed that the Mk 80 series bombs “feel a bit wimpy” compared to their Russian counterparts, is this one line near the top of the warheads.lua: local explosivePercent = 0.4 Yes that’s right – the explosive power of most “simple_warhead” explosion script calls are then multiplied by .4 (40%). Why this value is in the LUA is unknown to us; there are no comments associated with it, but it causes a significant compounding error when you factor in that the Mk-80s are undervalued on their explosive content twice vs. once for the FAB bombs as far as we can tell at this time. (180*0.4) = 72 instead of (240*0.4) = 96. That’s 31% less explosive than it should be, even with the unknown .4 multiplier reason (and there could be a very good reason for it), but because of the compounding math error, we are getting 40% of 69% of what should be there (27.6%) instead of 40% across the board. When we became aware of this error, some quick testing was done by some of the OEO group @instigator and @VMFA-169 | wheelyjoe by calling for a “simple_warhead” explosion in the Mission Editor of the correct size accounting for the .4 multiplier and proper explosive equivalent value and we saw much more realistic and expected effects on appropriate targets, all without any major changes or work around the existing damage modeling. That doesn’t mean that there isn’t still a lot of stuff missing in the DCS damage model, fragmentation and other effects are still missing. However, we believe that player satisfaction will be much better with these adjusted values because we will have much more believable effects on our targets. Bringing this all up to ED’s and now everyone else’s attention, it’s up to ED on what they want to do about it. We would be more than happy to explain in more detail what our observations are and how we came to the conclusions that we did and share our suggestions, but it is clear that a lot of the weapons tables, and warheads in particular, need a normalization and QC pass before it can undermine the new damage model that is being worked on for the rest of DCS. In closing I want to thank the advanced LUA code-fu experts from the Operation Enduring Odyssey community @instigator and @VMFA-169 | wheelyjoe, and from the Hoggit Discord @Amloris, @Froggy 2-2 | Leltch, and @Arctic Fox (Rose 1-2) for helping me wrap my non-coder brain around what I was seeing in the LUAs (when I should have been asleep) and frankly doing all the real heavy lifting on finding and confirming our suspicions through testing. My small part in this is just trying to put our findings into words that hopefully everyone can understand while they continue the hard work of building kickass missions for the multiplayer community of DCS. References: [1] "http://www.designation-systems.net/usmilav/asetds/u-b.html," 4th February 2007. [Online]. Available: https://web.archive.org/web/20070204002314/http://www.designation-systems.net/usmilav/asetds/u-b.html#_BLU. [Accessed 2021]. [2] "WeaponSystems.net," [Online]. Available: https://weaponsystems.net/system/870-FAB+M62. [Accessed 2021]. [3] Wikipedia, "TNT equivalent," [Online]. Available: https://en.wikipedia.org/wiki/TNT_equivalent. [Accessed 2021].

@Deka, thank you for adding this ability to turn these features on/off. The issue was not so much that these features are bad, but there was not enough feedback to the player that some of these effects would/are occurring - particularly the pilot freezing (no alert you are cold - just weird sound effect and head jerking, which was really jarring with head tracking), and some limitations on the ED atmo sim and whether there would be fogging, etc. Thank you for putting this kind of polish into the airframe, but it just needs better implementation.

Hello Vibora, Just wondering if there is any new content you can share about progress on the F1. Really excited and definitely a day 1 buy for me!

Has this been looked at with the new math/FM tweaks that were done for the A-10 II C? I recall they mentioned that they found some incorrect math for drag and high AoA/induced drag. The F-5 is of similar vintage and might be using some of the same underlying "old" math.