Bankler

Yes, but accuracy has nothing to do with this bug. The bombs sometimes drop as you start to hold down the weapon release button, instead of when the timer reaches zero. And it happens to LGBs (maybe to other bombs as well, I don't know). It is probably a new thing, because I have never seen this before the last patch.

I just flew a multiplayer mission with GBU-12. The bombs were released the instant we pressed the weapon release button, instead of waiting for the countdown to reach 0, the auto laser didn't engage. Tried to reproduce the bug in SP to provide a track, but then everything worked fine. Will let you know if I find anything else.

I acknowledge the bug, it's indeed broken. Good news is that I have found a way to fix it. Terribly sorry it took me this long to get around to it (damn you real life). A new version will be out soon. Feel free to pm me if anyone would like to help out testing it before release.

Hi Pochi. This is not really related to the mission. I suggest you contribute with findings in the bug thread in the Supercarrier section in the forum. I'm 99% it's already reported, but if you have a way of consistently reproducing the bug, I'm sure ED would appreciate the input. Hi Vikbell. I'm not planning to to a Marianas version. To be perfectly honest I don't really see the purpose. But I think there was someone in this thread who made a version in which he moved it over to that map, so you can search for it and see where that went.

This is a copy-paste reply from a Reddit post on the subject, which I believe is accurate. ----------------- Inside your DCS installation folder, there is a file: DCS World\Scripts\MissionScripting.lua Open this file, and at the bottom you will see several lines: sanitizeModule('os') sanitizeModule('io') sanitizeModule('lfs') require = nil loadlib = nil Simply put a comment (which is -- in lua) in front of the modules you wish to 'unsantize'. For example, if you wanted to give the lua environment access to the io and lfs modules: --sanitizeModule('os') --sanitizeModule('io') --sanitizeModule('lfs') require = nil loadlib = nil note that you will need to restart DCS for the changes to take effect. And each time that DCS is updated you will need to re-comment out those lines, as the file will go back to the default after each update.

@BIGNEWY @Yoda967 Great news that you're looking into the lighting. Awesome! However, as unproportionally much as the lighting bugs me, just like Yoda suggests, the way the AI aircraft depart, ignoring CASE 1 departures, is probably the more important issue as it's causing midair collision risks, if players are doing what they're supposed to be doing in a CASE 1 recovery. Have a great weekend gents!

@BIGNEWYSorry to ping you. But would like to know if this has been picked up and verified, since it has no label. Cheers!

BUG This is how AI aircraft currently take off from the boat during CASE 1: When spooling up, they turn the beacon on. When launching, the turn the beacon off. When airborne, they turn the formation lights on. Then they immediately start climbing to at least 1200'. SOLUTION This is what carrier based AI aircraft should be doing: Do not use any external lights at all (especially on and around the boat, but in general no lights during the whole flight). When launching, fly 300 kts IAS and climb to 500'. Continue along the BRC in this manner until 7 nm away from the boat. Then start following waypoints. REPRO Put a 4-ship Hornets on the Supercarrier, mid day, clear weather, with a waypoint somewhere on the map. Observe them in Spectator mode. REMARKS The bug is somewhat serious, since it stop players from using carrier based aircraft while performing realistic CASE 1 recovery procedures with human players. The AI aircraft will climb too high and risk collision with recovering aircraft. The unrealistic external lights handling kills some immersion by looking a little silly. They actually do turn off the lights before the landing, which is nice. Well done there! Even if providing the AI flights with waypoints trying to get them to hold speed and altitude, they will ignore them during the departure. This makes sense because they're in a departure AI state, but also stops us from working around the bug. Lights should generally stay off daytime even during CASE 3 with low clouds, for both departure and recovery. In fact, except for nighttime, they rarely come on at all. REFERENCES Track and miz attached. Hornet_AI_Case1_Bug.trk CASE1_Bug.miz

@BIGNEWY This one seems to be incorrectly marked as "correct as is". While it's no big deal (just like the OP states), the pilot saying the true bearing instead of magnetic is most certainly a bug (albeit a low prio one), and not "correct as is".

(and @MARLAN_, just fyi ) Not that it's a big deal, and I don't have any experience with the AI Marshal, but from an IRL perspective, you seem to be doing it the "correct" way in your gang, @Thomas_LOLW. The offset is common and enables them to more easily adjust approaches if they need to. Zero degrees is uncommon/rare, and 30 degrees is common from what I have learned, but it's not always 30 (nothing wrong with using that as a standard in DCS though). I also believe left is more common than right, but don't quote me on that one.

I think you are correct. But we already have on/off settings, allowing players (server owners) to choose, so in a sense we are already there. Now, I completely agree that having one (1) single (or default) value that is realistic would be ideal! But starting that debate with ED... I just don't know. I have had 3+ Hornet pilots witness that the Tpod laser code can be set on the ground, but ED chooses to ignore that and mark the bug report as "no evidence". That one is a completely objective simple fact, but it's still like talking to a wall. Wake turbulence is a much more complicated subject, and I don't have the slightest idea what kind of proof would be good enough for them. So in that sense, a slider would be a great solution. ED wouldn't have to admit they were wrong about anything (they can sell it as a "beginner friendly option" to lower wake turbulence to X%), and more importantly they wouldn't have to spend more valuable time researching it. They must have already spent huge resources on the implementation (super impressive engineering work, nearly nailing it, except for the exaggerated effect). Leaving it to the players might be the most pragmatic solution, I think.

Correct!

It seems the scenery remove objects zone action is again broken in MP. Back in the days, it only worked in SP, then it was fixed. And now it's back to only working in SP again it seems. Is this verified and being worked on?

Saw it for the first time yesterday and I agree, it looks so much nicer now! Great work!

Yes. I don't have any way of reading the throttle setting. It's just based on vertical velocity when crossing the ramp. If the VV is dramatic, it will assume that you have pulled the throttle back and give you "Settled -10". I know that the same thing will happen if you force a Tomcat down with DLC. I don't know anything about it really, but if I would guess, I'd say that using DLC to push the aircraft downwards the last few seconds is just as bad practice as cutting the throttle? So I've felt comfy with deducting 10 points for this, even though maybe "Settled" isn't the correct term in that case. No, I had absolutely no idea that was happening.

No, I think this checks out. I just assumed that the burble effect sucking you down would be on regardless of the tick box. As it's quite a different thing from aircraft wake turbulence, I thought this was completely separated. I thought I felt that down draft, in a nice way, after the burble was implemented, but I guess it was placebo then. --- As a sidenote, I never fly with wake turbulence on because of the unpolished state of it. In DCS a fighter can flip another fighter of equal size over if #2 flies through #1's air 20 seconds later, making an ordinary 4-ship overhead break with 5 second break intervals about the most dangerous things you can do in the game, which is not representable of real-life aircraft of fighter jet size. It's a shame, because certain aspects of the wake turbulence feel great! The tech is absolutely impressive, but would need massive tweaking. A nice quick and non-controversial solution (to avoid the debate), would be to change the setting from an on/off tickbox, to a 0.0-1.0 slider, setting the intensity of the turbulence. Ideally a similar one to scale how long the wake turb hangs around before it fades out. But I guess this is something for the DCS wishlist section.

Thanks for the quick reply! Does that mean that the burble effect is completely disabled if the wake turbulence tick box option is off?

@BIGNEWY Is the optional Wake Turb setting supposed to affect the carrier landings at all? Like control strength or presence of burble or similar? Or is the Wake Turb setting ONLY supposed to enable wake turb caused by other aircraft?

Make sure you don't have a SEQ boxed. Select any free wypt using the arrows. Press DATA, press UFC, press POSITION. Typ N (i.e "2") then 6 digits, ENT, then E (i.e "6") then 6 more digits. Then press ENT again. If you want, press ELEVATION, select FEET and input amount of feet. Press ENT.

Thank you, @Harker!

Yeah, I figured. And I of course I didn't mean to sound rude/patronizing/ignorant. Just noted that since you were new, there could potentially have been a binding problem. I remember there are some confusing details with the speedbrake bindings (something with an "OFF" binding and another "RETRACT" and so on), so it's not always obvious how to set it up even if you know how it should work. Anyway, I read your last message with the test you did and that everything seemed fine in the end, so happy to hear that!

Thanks for the reply. Yes, just like I already stated: "The only workaround is to add a significant deadzone to the TDC axis or (what I've done) use a completely different HOTAS button for the TDC Depress action, than the actual TDC Depress button." (to be fair, I made a typo and wrote DCS instead of TDC in one place, sorry if this caused any confusion, this is fixed now) It doesn't technically matter if you use the TDC depress hardware button (like in the real jet) or something else. If you move the slew before pressing, it bugs out, that's it. The only difference, is that if you use the TDC depress hardware button, it's almost impossible to accomplish a "clean" depress without any slew input, while if you as a workaround use a completely different hardware button, you'll be okay, as long as you don't forget and accidently try to slew before pressing (like in @Minsky's example). Sidenote: The "best evidence" that this implementation is claimed to be based upon, what is that evidence exactly? Just like @Swift. suggests, in this case, it's not really an accuracy discussion anyway, but just an obvious input bug in the game. Still, it would still some of the frustration knowing what source is referenced, and it could also help clearing misunderstandings.

This was also reported here: @BIGNEWY The current implementation, cannot possibly be correct. I think there's just a misunderstanding here. 1) If you are using an actual TDC mini stick when pressing the "TDC depress" command, it's not practically possible to press this button without also causing a slight amount of axis input. This small input will make the depress input malfunction (like Minsky explains in example 2). The only workaround is to add a significant deadzone to the TDC axis or (what I've done) use a completely different HOTAS button for the TDC Depress action, than the actual DCS Depress button. 2) I would be curious what documentation/information says (or even points towards) that moving the TDC when in WPSDG mode should "Have no immediate effect, but instead cause an alternative behavior to any future TDC depress input". To be honest I don't think there is any documentation indicating that, but instead, the team has just not understood the bug report and/or has not been able to reproduce it. As for the correct implementation there are two reasonable different options (I don't know which one would be correct): A) TDC axis input doesn't do anything at all (sounds like the easiest fix, and what the current implementation is TRYING to do, but it's bugged). B) TDC axis input causes an "automatic" TDC depress input, going into ground stabilization and enabling slewing (convenient, logical, but just speculation) @Mo410 Do you have any additional input?

@ManoloI'm sorry if I'm stating the obvious here. But just want to make sure that you are aware that you need to hold the speed brake extend button for approx 3 seconds for it to fully extend. I don't have DCS available atm to verify, but the numbers you present indeed sound very weak. This in combination with cofcorpse numbers made me think maybe you're not using the speed brakes correctly (please verify in F2 view that it fully extends).

Thanks! No, sorry, I don't have any evidence nor testimony. My report/thoughts are just based on what "seems" reasonable/consistent and nothing else. Not being able to fire gun without re-aligning unless carrying other weapons can not reasonably be a feature in the real jet, as it makes no sense. But it could arguably be a system flaw that was accepted by the manufacturer. I.e the functionality was allowed to limited/dictated by how the JDAM MFD page looks (all buttons already in use), and no one cared to solve it since they didn't expect a Hornet to need a JDAM within 2 minutes of a strafing run anyway. Sounds a little strange, but not completely unreasonable I guess.