Bankler

TL;DR version For Hornets (and maybe now even working with Tomcats?), spawn the first 5-6 aircraft normally. For the following ones, select a slot and go back and forth between that slot and “back to spectators” until you spawn cold on a cat. If you started on a cat, startup and move from the spawn point to the sixpack to allow additional Hornets to spawn. In the end of the article, there are funky tricks on how to avoid deck sliding. Background The carrier spawning is very limited, especially in multiplayer, only allowing you to spawn 5-6 aircraft. There is a fallback system that lets you spawn additional cold aircraft on the catapults. Unfortunately it’s bugged, making it unintuitive how to use it. Why would you like to spawn cold? Well, it’s bad ass to see a whole package of 16-ish jets getting ready on the deck, hearing the engines starting etc. It’s simply a great way to kick off the squadron mission night. Detailed instruction Let’s say we are 12 Hornets in three flights (Alpha11-14, Bravo21-24 and Charlie31-34) that want to start cold. Follow this procedure: Assign a spawn coordinator. In this example, you are the coordinator. Keep everyone in the same voice channel for now. You will need to tell them what to do and when. Unpause the server. Tell Alpha11 to spawn. He’ll spawn on elevator 2 (starboard side). When Alpha 11 is in, tell Alpha12 to spawn, then 13 and 14. Elevator 2 (starboard side) and 4 (port side) are now filled. Spawn in Bravo21. He’ll come in on elevator 3 (starboard side, behind the tower). Spawn in Bravo22. Now things are getting interesting... Sometimes he’ll end up on elevator 3. Sometimes he gets “Your flight is delayed”. If he’s okay, the next aircraft (Bravo23) will most definitely get “delayed” though. It doesn’t matter much. From now on, all players will always get “Your flight is delayed”. They should then press Back to spectators, then try the same exact slot again (do not attempt switching to another flight). Usually they spawn in on attempt 2, sometimes a few more attempts are needed. Continue spawning one aircraft at a time until all four cats are occupied. The guys spawning on the cats should not do the full startup. Just have them start the engines, and then asap in an orderly fashion taxi from the cat and park on the “sixpack” (that’s the parking slots behind Cat 2) and complete their setups over there. After the cats have been vacated, spawn in four more aircraft. Same thing here, “Flight is delayed”, always, but just keep go Back to spectators and pick the same slot again. It will work. Taxi them to the sixpack. Rinse and repeat. Notes Why taxi to the sixpack? To be honest, technically it doesn’t matter where you go, as long as you get out of the way. For us, it’s a convenient way of doing it, because that way people always know where to go without having to be directed. It’s relatively easy to communicate this procedure to new players in your group. If you prefer, feel free to use all the other cool places on the deck. Tomcats Maybe this is fixed by now (see below). But last time I tried this in an actual multiplayer mission, Tomcats required special care. A bug caused a CTD if you pressed Back to spectator, which obviously is not good in this scenario. Another issue is the size of the aircraft. Many times, I have seen the Tomcats spawn in only 1 bird on each elevator. These two problems together means you can only count on spawning in 3 Tomcats. The only way of getting more in there was to add an extra carrier for the extra ones. This is what we did (don’t forget to disable TCN on the extra carrier if you go this route). When writing this, I quickly tested again (but not on a crowded deck), and the F-14 did not CTD when pressing Back to spectators after Flight Delayed. So maybe, just maybe, the above method now works equally well for both Hornets and Tomcats. I know that Heatblur has been made aware of the problem, so maybe they’ve solved it? Great news in that case! Deck sliding, what is it? Is it bad? Deck sliding is caused by network lag and how the aircraft inherits (or not inherits) the movement of the carrier they are standing on. Even with minimal lag, the sliding can be very noticable. It’s common that aircraft suddenly slide into each other, cutting a wing off and being put on fire. It seems to get worse when the carrier is moving fast. But, it’s not a good solution to simply have a slow moving boat. You want ~25 knots or so over the deck, and if there’s no wind, you need the carrier to move at this speed to create that wind. Maybe you’ll be okay with having 15 kts speed and 10 kts headwind, but in the end, as long as the carrier is moving at all, you will risk deck sliding. With 20 people spawning, you might not want to risk this. How to avoid deck sliding (.miz included, yay!) The solution we came up with (kudos to Mauritz, who managed to figure out how to accomplish this technically) was to have the carrier standing still when the mission starts, and then tell it to start moving through a radio menu F10 command. You simply press this when everyone has launched and the boat starts moving. Best of both worlds really. No deck sliding, but correct wind over deck when time comes for recovery. And no, there’s no problem cat launching the aircraft without headwind. The only downside really is that it requires some mission editor setup. You’ll need to use the Mist lua file, call a script function, and setup some trigger stuff in the ME. I have attached an example miz of how to do it. Basically, it works like this: The carrier has no route, so it’s standing still. Instead, a deactivated speedboat unit has the carrier’s route waypoints. When you activate the trigger through the radio menu, the route is copied to the carrier, so it starts moving. Maybe there’s an easier solution, but so far, I haven’t found any. In the attached mission you have a main carrier setup like this. You also have a stationary backup carrier that you can despawn with F10 radio, Hornet and Tomcat flights (with synched preset lists), and a rescue helo using the same trick to start moving on command as the carrier. Feel free to use it as a template for your own carrier ops missions. Just don't forget to add tankers and AWACS. Final notes ED, I know you aren’t going to look into improving the current carrier before you have released the super carrier. Fair enough. I realize you need to prioritize certain stuff (the stuff that brings food to the table). If however, you perform any steps towards improving it, unless you have a fully working solution for a package-size multiplayer group, please at least don’t make this workaround impossible. We have spent countless evenings working out how to get this working, and it would feel horrible having to start from square 0 again. Currently, with this workaround, we are finally enjoying large-scale carrier ops and are having a blast with it! :) DCSCarrierTrick.miz mist_4_3_74.lua

+1 Having the exact same problem with my MFD exports.

Update: Workaround: By setting an extreme curvature, I managed to get is usable at least. This way I can make full movements on the stick when using the radar cursor, and ever so slightly movements when using the HUD, and get reasonable precision on both. My current axis settings (delta sim WH modification TDC stick): Deadzone: 10, Sat X: 100, Sat Y: 75, Curvature 40. Feedback: As for the HUD, it feels like the coefficient which the sensitivity is multiplied with is WAY too high (like around 5 times more sensitive than it should be). Without a curvature it's impossible to get any precision. Imho, this stuff should be in the ballpark when you're using the default settings (100/100 and no curves), and then you can use curves to tweak it to your liking. If you make large inputs, the cursor moves extremely fast in an erratic and jumpy way, which just doesn't look nor feels right. Note: The Viper HUD marker also suffers from lack of small-movement precision, but at least doesn't do the crazy jumping when getting larger inputs. Maybe the Hornet and the Viper team can put their heads together on this for a smooth solution?

Hi Brun! Have you found any alternative square buttons? I'm looking for something to replace the PS1023ABLK buttons with, since I don't like how much pressure the need to activate and that there's no distinct feedback when you click them.

When using AUTO bomb mode, I find it extremely difficult to move the marker in the HUD with any precision. I have pulled the sensitivity down on the axis as low as it's reasonable to still be able to move the cursor in the radar screen and SA page. But the HUD is super hard to control. It got slightly better after changing the default TMWH ministick to the delta sim PS4 style control, but it's still very hard. Is there a setting somewhere? Anyone else having this problem?

Only tested in SP so far.

Similar results here. For me, goes from 92-100 ish FPS to 60 fps when turning the SA page on. There is no difference if there is only 1 or 20 enemies being tracked or what scale the page is at.

Thanks a lot for the input! Much appreciated. It indeed seems that there is some weird behavior related to the LTWS and NCTR. In a situation with no other donors: * If I "sensor sw right" auto lock a target with LTWS enabled (i.e boxed under data), NCTR does not identify the target. * If I "sensor sw right" auto lock a target with LTWS disabled, NCTR does identify the target. * However, if I lock the target with the TDC, NCTR does identify the target, regardless of LTWS setting. To me this seems strange. IIRC AACQ is just a way of locking someone up. The STT lock it results in should be the same as when manually locked with the TDC, right? Another question: Am I supposed to get any feedback when IFF interrogatiing if there isn't already another source (donor or NCTR) verifying it? To me, the button seems completely non functional in this case. * If an AWACS has identified my contact, and I lock it up and press SCS depress it gets verified as hostile right away (even at long range like 50 nm). * However, if I don't have an AWACS, nothing happens when pressing SCS depress at long range. If the target later gets identified by NCTR at short range, I need to press SCS depress *again* to verify it. To me, it seems a little odd that the order of the two "steps" is relevant (donor/nctr first, IFF last). Of course, I wouldn't know how the real life bird behaves, but technically it doesn't really make much sense to me. Btw, I would love to get NineLine's input on this. (Regarding the blue/red Hornets etc, I think it's fine tbh. I have a feeling that 99% of the times we use Hornets on red side, it's for training, or as a replacement for the lack of really good Russian jets. Not for recreating a USA-Finland conflict). :)

Two more things: 1) If I lock the target with Sensor Switch Right (having the radar in the right MFD) for auto acq, I find no way to interrogate the target. Am I missing something? (Edit: If I unbox LTWS it works) 2) If I LTWS lock a target at 30 nm, it will get auto-interrogated at 24 nm. But if I STT lock the target at 30 nm, I need to manually interrogate when it gets in range. It seems a little weird to me, is it correct?

Thank you. This was very helpful and well explained. That means I can always press boresight acq quickly followed by sensor depress to lock and interrogate. That's awesome. Some small details I have noticed: "when you do hover the TDC over a radar contact for about .5s and LTWS is enabled, the contact is automatically interrogated" I don't get this to work. At least not in the way I parse your instruction. Maybe I'm doing something wrong? For me, if I LTWS-lock a target it's instantly interrogated. If I LTWS-lock it out of interrogation range (25 nm+), the target gets automatically interrogated when it's inside ~24.5 nm. There's no need to hover over it to start the interrogation. And if I hover over another in-range contact (not locked up) when I already have a LTWS target, they don't get interrogated. In fact, the only way I can interrogate another target is to select that one as the new LTWS target (requiring 2 x TDC depress on the new target (yeah, 3 for STT in this case). However. If I interrogate target #1, then TDC-depress two times on another target (target #2) making that the new LTWS target, and then hover over target #1 again, it indeed shines up red. I guess it has remembered the first interrogation. This matches your description. But note that (as far as I have experienced) you need to have already have interrogated a target once to get the hover-thing to work. Btw, not trying to nitpick. Just want to understand this stuff once for all. :) Your reply was super helpful regardless and pointed me in the right direction! :thumbup: Thanks a lot!

I fly head to head with a MiG-29S. My DL, IFF and NCTR are on. No AWACS available. If I use the right MFD in radar page to lock (STT or LTWS) the MiG-29 within a reasonable range (up to 24.5 nm or so), the target is immediately interrogated automatically. I don't need to press Sensor Switch Depress. However, if I instead lock the target with Boresight Acquisition, the target is not automatically interrogated but I need to hover over the target on the radar and manually press Sensor Switch Depress. Same result if I press Sensor Switch Right for Auto Acquisition. Is this the intended behaviour? If could wield my magic wand, I'd love the aircraft to automatically interrogate on boresight acq (that's when I'm usually in a hurry!). :pilotfly: (Tracks attached) SuccesfulIFF.trk NotSuccesfulIFF.trk NotSuccesfulIFF_2.trk

Hey IronMike! I've done some testing on my end. I couldn't reproduce it following Bearfoot's exact step (never got it to happen when switching from Hornet for instance), but the report was very helpful regardless. As far as I can tell, unless I'm making some very weird mistake (which has happened before...), it doesn't seem mission related. I created a new testing misison. Completely empty except two client slots; a cold start Tomcat and an air start Tomcat. Repro-steps: 1 Launch mission in SP. 2 Select cold start aircraft. 3 Hit ESC and press "Select role". 4 Select the air start slot. The CADC warning light will shine, and the wings won't move when you press AUTO, just like Bearfoot's description. I have attached the minimalistic test mission. :thumbup: Cheers! F-14_CADC_Test.miz

This looks like F-14 bugs to me. Can't tell for sure, but I've let HB know about it. Thanks for the report. EDIT: Saw that Ironmike replied before me. Thanks!

Hey Jar! I noticed that with a recent update (2.5.5.38140) the modified shader that you use to turn the platcam into full color stopped working. After a some hours of work I've managed to create a new one that works. Hook me up if you want it, so you don't have to go through all this stuff again.

Fair enough. Your statement is likely technically correct. You might be referring to a bug report that I haven't seen. The bug I have seen is this one: https://forums.eagle.ru/showthread.php?t=247311&highlight=weight It only brings up the symptom in the CHKLST page. The mission computer is not mentioned. In a reply Svend_Dellepude asks "Could I be right in assuming that the FCS G-limiter is also affected by this?". Bignewy says he IS NOT sure, but assumes it (i.e has not tested it). Now I have tested it and provided a track for it, so he can be sure. You're welcome.

The G limiter does not get the correct value. Instead of being based on the aircraft's actual weight, it's based on the weight displayed in the CHKLST page, which is not calculated correctly (this is confirmed by ED and is another bug, most likely related to this one). TEST: Two aircraft with similar weight: One is clean (with more fuel) and the other carries four missiles (with less fuel). A) [Clean], 55% fuel, 31914 lbs in ME (~31950 in the mission) 7.5G B) [2x9M, 2x120C], 42% fuel, 31844 lbs in ME (~36150 in the mission) 6.8G Aircraft A is limited to 7.5G which is correct. Aircraft B is limited to 6.8G, which is not correct. Note that 6.8G to matches the NATOPS chart for 36150 lbs (the wrongly calculated aircraft weight). To me, this confirms that the number is based in the weight indicated in the CHKLST, rather than the actual weight. The attached track demonstrates the bug. The effect this has is that we cannot pull the amount of G that the aircraft is capable of, without pulling the the paddle switch (which can give you more than 7.5G and, if you want to fly realistically, is generally not a good idea). WeightGLimitTest.trk

When you try to lock the target, I assume you hover over it with the TDC before pressing TDC depress, right? Just before you press, pay attention to if any information turns up just by hovering over the target (i.e altitude and such). If nothing pops up when hovering, the thing you see is not a radar contact (meaning you cannot lock it), but just a datalink contact. If you attempt TDC depress on a datalink target, it won't work (the radar will go into some sort of spotlight search, just like if you depress out in the nowhere). You need to slew the antenna to match the targets altitude (you can read the altitude by hovering over the DL contact in the SA page). I will say this though: Something is fishy with the radar. Many times my radar just won't pickup contacts (they only show up as DL contacts), even when it should. Sometimes, when I cycle weapons (select 9X then back to 120C), the contact suddenly shows up. I don't have a 100% repro rate on this, so I'm not sure if it's a bug or not, but you can always try it and see if something happens. This trick also worked when we got the infamous "cannot break lock even if you turn the radar off"-bug... cycle weapon and voila.

Confirmed. Same here for all the Hornets on yesterday’s mission, started cold from Stennis. Sorry if I’m a little salty (too many hours on deck), but this bug is quite obvious so it shouldn’t slip through the QA filter imho.

Thanks for the shout-out! Really happy that you’re enjoying it!

Thanks a lot for the feedback. Wonderful to hear that it helped you! Regarding "Clara low" (and "Clara high"). In this context it just means "So low that you wouldn't even see the ball from down there". In contrast to "Very low" where you're not doing great but at least the ball is still visible. In other words, it's not the same thing as calling Clara on the ball call (even though it would of course be a good idea to call clara on comms if you lost sight). Ball calls are not implemented in the script. My reasoning is that it makes little sense to call the ball by fiddling with radio menus. It's something you do on SRS or your choice of voice comms. (Though, of course, I guess it could be done with some Voice Attack magic in single palyer).

Depends on how you usually dress your christmas tree. The lights are very much visible at least when you're getting somewhat close. With the lights turned off in DCS, the runway is not visible like it is IRL.

You have two options: 1) Copy every asset (make sure the aircraft names are intact, or hack the script to account for it) and script in the mission to your new mission (you'll need to be careful, and know what you're doing with the ME and miz file structure. No support line available) :) 2) Start with my mission, and add whatever you need to it. In regards to Alerax's mission/script, I'm not sure. Last time I checked, he used obfuscation on his lua script so that you cannot change them (which I understand, even though I opted to keep my scripts open). On the other hand, maybe you don't need to change anything in them. I'm not too familiar with how it works, but maybe you can start with my mission and try to add Alerax stuff to it? If you distribute it in some way (other that sharing it with a friend or two), please leave the stuff in the briefing intact, for credits purposes. Check if there are any such terms/conditions in Alerax's mission as well. Final note: Please be aware that this mission is a living (free) product, meaning I sometimes come out with a new version containing improvements and bug fixes. As you understand, I have no possibility to help out with merging these fixes into your own home-cooked version. Good luck! Cheers!

Just tried some more. In my case: * SP: Had to hold. * MP (as host): Had to hold. * Mission Editor: Latched (toggled on/off each trigger press) Maybe it's different for everyone because we're all testing in different ways.

Indeed a game changer! Despite the current limited feature set, the stuff that's there works REALLY well! I had a blast shooting Laser Mavericks (didn't have to hold trigger btw, only pressed it once) and designating and dropping JDAMs on four groups of targets in rapid succession felt awesome. Great work!

ED: Here is a trk illustrating the issue. Mk82s in AUTO falls long almost every time. In one attempt out of eight, it was somewhere close to hitting the target. I used BALT autopilot and ATC to minimize the human factor. I chose this track, as it shows that it's not a 100% repro that it falls long. Out of 8 drops, bomb number #3 hit the target, bomb number #8 was short, all the other 6 ones fell long. It's consistently inaccurate compared to CCIP, which doesn't make sense. Especially now when we have the Tpod to verify we're aiming at the right spot. With all due respect ED, even if you don't prioritize this (which is fair enough, there are other more pressing issues) please remove the [CORRECT AS IS] label, because frankly it's almost an insult to the original poster and all the people who help you out with testing this stuff. The Red Kite video (12:00) posted above illustrates the issue quite well, and I guess he has some credibility considering you recommend his videos. (If it's impossible to reproduce the problem on some dev computer, maybe try another to make sure it's not a framerate dependent bug?) Mk82AutoMiss.trk Mk82AutoMissTacView.zip