Bankler

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.

When copying a group using ctrl-c, everything seems to get carried over EXCEPT the sidenumber and the Unit Name. When pasting, these fields get other, generated values. When copy-pasting large numbers of groups from one mission to another, this is very frustrating, since you will manually have to recreate all these settings (which can take hours if it's a large mission that you're converting from one theatre to another). I realize the reason is to retain unique numbers. And for Unit names this (almost) makes sense. But only if that unit name is already taken (which is typically not the case if you copy the group into another mission). In short, my suggestion is, when pasting a group: Retain the original sidenumber, unless it is already occupied by another unit in the mission you're pasting to. Retain the original Unit Name, unless it is already occupied by another unit in the mission you're pasting to.

@NealiusThanks for the input. I'll do some digging!

When recovering aircraft IRL, the carrier typically turns into the wind, with a certain angle to generate around 25 kts over the deck, and as little cross wind as possible. The Alt-F9 camera shows the WoD and the cross wind, which is excellent. However, this requires a lot of trial and error, and the camera is not available for mission designers who don't own the SC module. The result is that the community builds a lot of missions with really weird recovery conditions. My suggestion is that you should see the optimal HDG and Speed for the carrier in the Mission Editor (this obviously changes if you change the mission's wind settings). So it's easy for the mission designer to adjust it accordingly. Don't know that the best UX would be. But maybe just a small text overlay, with the optimal setting, and a little warning sign on a leg if that leg's course deviates from what's normal (more than like 3-4 kts crosswind from stern, or more than 0 kts crosswind from port, or WoD that is less than 20 or more than 30, something like that). The math around this is not that trivial. Luckily, Mags and Bambi in the Master Arms community have already written a web based tool for it, and the code is open for you to use as reference if needed. Here's the tool: https://magwo.github.io/carrier-cruise/ https://github.com/magwo/carrier-cruise

In most cases when this happens, you can get unstuck by turning the nosewhel left and right (and repeat until unstuck).

Sorry for the late reply. It shouldn't break anything. Feel free to head into the Mission Editor and dress the deck as you wish! @markturner1960 @captain_dalan @Ala12Rv-Tundra @Nate Kott Thanks for the kind words! @conRAD9055 Yeah, I'm not sure if it's feasible putting this into a mission that's already using Airboss. Airboss use some of my code (refactored and tweaked be Franky to fit their needs), and, just like you say, it feels like there could be conflicts using both.

Great post! Then the pattern is both in place and tested already!

Fair enough, good stuff!

This is a great suggestion. The pattern is already in there (with Realistic TDC Depress). It's clear, customizable, and should be a straight forward implementation. Tucked away under "Special", it won't clutter up the controls page nor require additional bindings. Each screen should simply multiply the slewing speed by whatever the user has set in there. As neither the community nor ED (and to be honest probably not even 99% of real life Hornet pilots) know the relation in speed between different screens in the real aircraft, and we all have different hardware, it makes a lot of sense to leave it to the player to fine tune it. @BIGNEWY@NineLine

Thanks for the warm words. That's not a bad idea, and it's cool that you implemented it yourself. However, I feel that since pattern mode is a global setting (affecting all players) it would only make sense in SP. And having an option like that sort of breaks the pattern (no pun intended) of only having options that are MP compatible. My suggestion would be to simply enable pattern mode from the get-go, and fly a normal break anyway. It will still work (just having a max score of 63 instead of 75).

VERSION 7.2.0 You can now download version 7.2.0 in the Original Post! Celebrating 20,000 downloads! Thank you so much for all the love I received through different channels through the years. It means a lot. As of today, the mission, in its different versions, have been downloaded 22,218 times. I would never have thought that the interest in landing pixel planes on pixel boats in the most difficult of ways while getting nitpick feedback from a script would be this popular. But you guys proved me wrong. Pattern Mode As you know, Pattern Mode was broken in the last version. This is now fixed and available through the comms menu. Pattern Mode enables you to skip the break, and instead turn directly into the downwind after the cat launch, much like how CQ is performed IRL. This is a good way to get quick reps, especially if flown with hook up. <profanity> Hot Breaks I have been quite ambivalent regarding adding this feature. The whole point of the mission has always been to help people flying safe, consistent passes. Experimenting with SHBs sort of distracts from that. However, I got this feeling that "now is the time". While <profanity> Hot Breaks look really cool, they also serve a purpose. Coming in as a division (4 aircraft) actually requires the lead to break over the ship, in order to not have #4 break 4 nm or more past the ship, while respecting proper break intervals. So it makes sense to practice this. However, I also think it makes sense to start with the ordinary breaks, and do at least a hundred or so of those before even looking at SHBs. To initiate a SHB, all you need to do is to break really early. The script will identify the maneuver, and give you automatic perfect score on all the first parts (regardless of how you pull off the break). Then it will start the normal tracking as you pass over the wake. If you extend the downwind during a SHB you will get a -20 penalty (compared to -10 during normal breaks). The SHB support can be seen as an experimental feature. The scoring isn't necessarily perfectly fair, and should probably not really be compared to ordinary breaks. Speed and Wind I have always had the wind at zero. The reason is that I wanted the boat to have correct wind over deck even as it turns around and steams south. The cost of this has been small crosswind that is generated by the angled deck. For this version, I changed it so that there is a light wind, and the carrier steams a little slower. This will reduce the sidewind. As the boat turns south, it will not longer be perfect. I figured that 99% of the users mainly run this in SP and air start anyway, so that it's worth it. If you're running the mission on a 24/7 server, it might make sense to set the wind back to zero and the boat speed to ~25 again. Just go ahead and change it in the ME if you prefer that. Have a nice spring everybody! //Bankler CHANGE LOG 7.2.0 * Fixed Pattern Mode. * Implemented support for <profanity> Hot Break. * Carrier is now slightly slower on its north leg, and there is a little natural wind. * Added minor turbulence. * Added ice halo. * Increased number of flares in Hornets from 30 to 60. Enjoy!

Thank you, @Blackfyre! I had totally missed that thread.

Interesting. Could you elaborate a little on this? It's confusing that an anti-radar missile wouldn't be able target a giant hostile high-value target radar.

(There are a couple of other threads about this, but the headers were possibly a little vague and they missed .trk so I decided to start a new one) Version OB 2.8.4.38947 MT Bug In AUTO mode, various bombs sometimes drop the moment you press down Weapon Release, instead of waiting until the countdown reaches zero. Repro rate ~60% Repro Add a client Hornet with various bombs, and with a grounded WP somewhere Start the mission Select a bomb and configure it (fuze, codes etc) Select WP 1 and press WPDSG Start holding weapon release at 2-5 seconds countdown First bomb will drop as the countdown reaches zero Change to another bomb and reattack Start holding weapon release Observe that this bomb drops instantly Rinse and repeat from step 7 Remarks It can happen to several types of bombs: Mk82, Mk83, GBU-12, GBU-16 and Mk20 confirmed. In my test, I carry one bomb of each of the ones stated above. In all my tests so far, the first bomb works, every time. Subsequent bombs sometimes work, sometimes fails. It's consistent in that when it fails, the bomb always drops instantly. I have never seen a case where you're holding the button and it drops after a while but too early. Either instantly (failed), or it works as intended. It can both fail and work, regardless of feet wet/dry. I have seen it fail on pressing the weapon release on short times such as 2 seconds, but also very early such as at 15 seconds. Regarding the first bomb always working, despite my 100% consistency in these test, I'm not sure of it. In a multiplayer session the other day, my first GBU-12 failed in this exacy fashion. We had fired HARM and GBU-32 before though. (In my tests, it looks like lower altitudes often fails, and higher altitudes often works. But the pattern isn't perfect. Maybe irrelevant.) Track In the track, drop 1 and 2 (GBU-12 and GBU-16) works fine, the drop 3, 4 and 5 fails (Mk82, Mk83, Mk20). As stated above, I have seen all these types failed though, so the bug isn't tied to the dump bombs. Hornet_AUTO_Bug_Multiple_2sec_Failed.trk

Version OB 2.8.4.38947 MT Bug HARM cannot see nor fire at some/any(?) EWR units. Repro Add a client Hornet with a HARM missile and an EWR unit in the editor (1L13 or 55G6) Start the mission Observe that the search radar shows up in the RWR as S Observe that the radar is not visible in the HARM TOO page Observe that you cannot select the target in HARM SP mode Remarks HARM can still see other Search radars, such as the P-19 Flat Face in the SA-2 sam site template. Hornet_HARM_CannotSeeSearch_Bug.trk

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.