Bankler

Representing Master Arms DCS community. I can verify these issues. We are typically around 10-14 client Hornets on a missions. No AI planes on the carrier. Almost every single time, there's an issue with the ground crew not reacting when someone approaches the catapult, and the "Request launch" command does nothing. It's sometimes resolved when another jet that is already hooked up takes off. Example: Cat 3 doesn't react. Aircraft on Cat 1 takes off, and suddenly Cat 3 dudes start waving you forward. As it appears in mp with lots of players, it requires lots of organization to record a trk, that is also small enough. Also, I haven't found an exact pattern when it happens. However, it's so easy to reproduce, that you should easily be able to do it internally, as long as you have around 10+ players available. Just spawn everybody, cold start, decide on a time when to start taxiing and take off, use various cats, and see what happens. If you already know what you need, that's awesome. But if a trk would be of actual use, I could try to organize a session and record it. If that's the case, do you want the server or a client trk file? @NineLine

Hmm. I had a look, and to me it looks like it's the CVN-74, which I imagine is the legacy carrier? Maybe I'm missing something (early morning here), but can you please take a look just to make sure you didn't download the SC / T-45 version or something? Just there, in this case. I think in other missions, they have positioned the ship as reference points. Imho this isn't a great way of getting a feel for the break, as you will make yourself dependent on where those are. So think of them as decoration, nothing else. Except from the one at the carrier's 6 o'clock. That is a reference point to where to fly over to start the script.

With the Sinai map out, it would be nice with the quite unique looking Egypt liverie for the Viper. Just like we got the nice IAF ones when the Syria map came out, I think this would make a lot of sense. I realize it's available as a user file download, which I appreciate. This request is to have an official one, not requiring extra downloads (which is quite a hassle for big communities).

Already located in the top of this thread.

Ok, good, then we are on the same page. As described in the bug report above, and as showcased in the tracks I provided, that's not how it currently works.

If you do that, in DCS (currently), your first bomb will hit vehicle 3. Is that correct or not?

I'm not sure then what you mean by "group"? Are you referring to the group of bombs? Let's say you set QTY to 3, and interval to 500. You put the CCIP reticle on a tank and hold pickle. Should bomb #1 or bomb #2 hit the tank?

Ok, nice research! Then that means it's currently bugged (at least for CCIP), unless I'm mistaken.

Just to clarify. I don't think this is an AUTO exclusive issue, but goes for CCIP as well. But I'm certainly not sure by any means. It's just the way I remember it working after ED fixed/adjusted it last time. In some ways it's confusing how this is even possible to implement for CCIP. But I guess by extrapolating the currently calculated aimpoint by, ehm, (QTY setting * Intervall setting) / 2, in the direction you're flying, and drawing the reticle there, would get it right. Would be nice if a Hornet guy could chip in on how it works. Weapons questions are always tricky, but could very well be such a trivial thing that it's not a confidentiality issue. And then again, the way it works now (aimpoint always on the first bomb's estimated placement) is absolutely fine and makes just as much sense. Just not sure if it's correct compared to IRL Hornet. Have a nice weekend!

Okay, here goes! Three tracks, though all show the same results. CCIP, AUTO (explicitly set) and AUTO (automatically set by being in CCIP when pressing WPDSG). Note that I'm aiming on the middle building of the five. That's where the first bomb go. I'm not sure what's correct, but AFAIK it was like this when the Hornet came out. Then it was changed so that the bombs did bracket the aimpoint (i.e number 3 out of five bombs on the aimpoint, two before and two after), but now it's back to the original implementation, and I'm curious if that is intended or not? Hornet_Interval_Bug_CCIP_to_AUTO.trkHornet_Interval_Bug_CCIP.trkHornet_Interval_Bug_AUTO.trk

@BIGNEWY Do you happen to know anything about this? Cheers!

Yes. I can confirm, that at least around a year ago, and at least when dropping in CCIP (I'm quite certain it was the same for AUTO though, since it would make sense), if you dropped 5 bombs with a interval of say 500', it would put bomb number 3 on the aimpoint. Doing the exact same thing today, will put bomb number 1 on the aimpoint. I don't know what's correct. In my world both make sense and are just about equally functional. As long as you know what to expect. Not sure if this change was intended or not.

It is most likely (I'm speculating, but I'm approx 80% sure) because Wake turbulence is enabled in the missions where you're struggling. I suggest you disable it for now. While some aspects of the effect are really nice, there are a couple of massive problems with it. One is the thing you're experiencing. Another one is the extreme amount of time it takes to fade away, even making ordinary (multiple aircraft) overhead breaks dangerous. Hopefully ED solves the carrier issues, and implements two sliders for wake turbulence intensity and duration.

VERSION 7.3.0 You can now download version 7.3.0 in the Original Post! Fixing what's broken! Due to some DCS scripting changes, all missions using Moose stopped working a while back. The guys over at Moose were quick to find the problems and publish a new version. Thanks to them, and thanks to you who helped out testing the little test mission I posted in the thread, we are now back on track. Thank you so much! Happy landings! Have a nice holiday later this month! //Bankler CHANGE LOG 7.3.0 * Updated Moose, in order to get the mission working again after ED's scripting changes. * Changed overhead tanker TACAN band to Y. Enjoy!

Here's a very quick test version with updated Moose. I haven't tested it more than confirmed that the score starts tracking and I don't get any weird warnings in the log. Please test it if you have the time, and let me know if anything seems off. @zildac @captain_dalan @japagi @speed-of-heat @Richard Lim @Cobalt135 @Mad_Taz @Iriya @Cepheus76 @marcoy Thanks a lot for the reports. Much appreciated! TrapTraining_MP_SC_2_7_3_TEST.miz

I will try to find some time to look at it. I know that there was some problems with compatibility between 2.9.1 and Moose (which I'm using), so maybe it's related to that.

I haven't tried 2.9 much, so I'm not claiming you're wrong. However, since other people say they're not seeing this, I was thinking about a certain common issue when you mentioned that you can no longer trim to correct AOA: If you have used autopilot at any point during the flight, be sure to disconnect the AP using the Paddle Switch button on the stick. Simply pressing "BALT" (for instance) again will not take you out of autopilot, even though the : thingy disappears. You will instead go into CSS mode, and if that's what happened, it could potentially explain why you couldn't trim. Just tap the paddle switch and you will be alright. "The most basic mode of the AFCS is Control Stick Steering (CSS). CSS will attempt to maintain the pitch and roll of the aircraft without manual stick input. Roll input is dampened and pitch input is severely dampened. The trim switch is repurposed in CSS to command roll and pitch. Forward or aft stick deflection beyond a certain point will disengage CSS. CSS is engaged manually by pressing the UFC ON/OFF button in the A/P menu and also engages with all other autopilot modes." Again, not sure, if this is what caused your issue. So sorry if this doesn't help one bit. But it's a very common mistake.

Finally fixed in 2.9. Thank you! Fixed: FLIR Switch behaviour.

It works, but the only thing it really does is cutting out the first parts of grading, so you fly the CASE 3 approach (straight in) and it will grade you in the groove (max 33 points or so). It doesn't check anything else of the CASE 3 stuff (hold, push time, the way you descend and align with final bearing etc). It's more a "bonus feature" if you and your friends want to do a CASE 3 event, and still get some grading, for fun. No such plans. You're free to use the current versions and create on if you want though. It might be easy, but you may also run into problems depending on how different that boat happen to be in terms of height, lens position, wire positioning and so on. Might turn out to be a complete can of worms. I don't do versions for other maps. But I think someone in this thread made a version like that. Don't know if it uses the latest script version or not. For the thing you want to solve, you might be able to move things around in the mission editor so you're farther away from shore. One advice is to just double check that the wind is still within reasonable limits after you move things. Check L Alt + F9 cam. Wind should be around 20-30 kts over deck, with no cross wind, or a slight starboard crosswind (1-3 kts or so). If you simply move everything west on the map, and make sure the boat goes the same heading (magnetic 353 I think?) you should be all good.

Thanks! Fair enough. I can see that could be an issue if one wants exclusive sidenumber (and doesn't care much what those numbers are, which probably holds true for many users). I guess my point is that it would make more sense if the current exclusive-number-operation is applied when pasting, not when copying. So if you try to paste a unit and another unit already has that sidenumber and/or unit name, THEN it changes to what ever is available. With the current design, it sort of assumes that there will be a conflict down the road (which isn't true if you paste it into another mission, or delete the original), and "fixes" (aka breaks) it prematuerly. That's the reason I call this a bug. I see the purpose of the behavior, but I think it's implemented in the wrong way. For what it's worth, I don't personally mind the solution you're suggesting (having an option). Just not sure if ED would like the added complexity (but what do I know?), and would rather prefer a simpler (single) "catch all" solution. So that's why I argue the default behaviour should be the one I suggest (i.e apply exclusivity when pasting, not copying). That solution would cover your use case as well, as far as I can tell. In my original post I wrote "Always retain the original sidenumber, no matter what." Changing that to "Retain the original sidenumber, unless it's already used by another unit" following your feedback. Cheers!

Well, "that trivial" is very much open for interpretation. I'm not saying there is any magic to it. Yes, it's trigonometry. Given the fact that I know absolutely nothing about your understanding of boat ops or math, it's impossible for me to know if you are just relatively clever (smarter than a 14yo) or if you underestimate the problem. To find out, as a fun game (and also since it could help illustrate the problem to others) you have two minutes to solve this problem (you can use a calculator but not the tool): The wind comes from 045 at a strength of 7 kts. The angled deck is 9 degrees to the left of the bow (Nimitz style). For an aircraft to perceive zero cross wind in relation to the angled deck when in the groove, which bearing and which speed should the boat set? Present your calculations and the time it took you to solve it.

While your first sentence certainly holds true, if you're holding on to that in dogmatic way, it would mean a developer wouldn't be free to fix bugs and flaws. While I agree leaving options in there for the end user to customize behavior (liked you touched upon) can be great in certain cases, imho it doesn't make much sense to do so if one cannot present a user story where one of the options is at least sometimes valuable. That only results in bloated software. And for those decisions, best practice, imho, is to look at each case, rather than blindly applying a paradigm.

I think what you say makes sense. I guess I'm just not sure how it relates to the topic. I.e request for an aid in the ME in DCS (where the effect you're talking about isn't a factor) for a good heading and speed on the carrier given a certain wind setting. But yes, I humbly might be missing something.

@Nealius You are correct regarding the ME mag/true. Both wind and heading is in true, so the corresponding difference between those two also holds true in game (but expressed in mag). Just like in your example numbers. Tweetys comments about current is indeed interesting. I assume it's correct that a ship would head slightly into the wind to stay on course, just like an aircraft. But I think I agree that it's not modelled in DCS. I did a quick test, with 97 kts crosswind. The sea and deck pitch is crazy, but as far as I can tell, the boat still has its nose in the direction it's travelling, and its wake extends from its 6 o clock position straight out. So currents are probably not modelled, making it a no factor, like you suggested. --- Regarding the matter at hand (i.e whether the boat tries to compensate to eliminate cross wind or if it just puts the natural wind over the angled deck) it's a tough one. Ziplip (who wrote the carrier guide you linked to) scratched his head. The Navy pilots I have talked to about it seem like they haven't even thought of it. Which makes sense. In their world it probably doesn't matter, since even if the boat can (and tries to) eliminate cross wind completely, many times it can't. Sea lanes, proximity to territorial seas ( <- quoted by Yello) has to be respected. So regardless, they will have to land in small crosswinds. Exactly why that crosswind happens is probably of little interest for them. So from a pilot's point of view, the problem gets academic, and they don't care much (which, again, makes sense). For Mission Editor purposes, I (personally) think it's interesting. I would love to get in contact with someone who actually have worked with this (i.e deciding which way she's heading). Don't even know who's doing that. I asked Yello if he could refer me to someone, but haven't heard back on it. Yello's gest guess, was that (quote) a combination of the two are employed and compromises are likely. So most likely, the person (or computer) who decides/suggests the ship course probably has all this figured out, tries to eliminate some/all crosswind, but in the end, so many other factors are involved that it's almost insignificant.

In what way would it affect anyone negatively? A usecase would be helpful. The way I see it, what currently happens is a bug. If you copy something, that clone should be similar to the original. It's kind of the definition of a copy.