norman99

Ahh, that explains it. Thanks. Still, it’s a shame it couldn’t be released as a static model first, until the relevant tech allows for more. Combined with some nice placeable berms/revetment models (desperately needed in my opinion), you’d really be able to fill out a fixed SAM site nicely with this.

One of my interests is recreating realistic SAM sites, and in my browsing I stumbled across some photos of a DCS SA-2 missile transporter model. This was from an Aprill 2018 newsletter. https://www.digitalcombatsimulator.com/en/newsletters/newsletter20042018-db94994c1740e9d799ea62b7f07e4d1a.html I went looking for the model, initially in the mission editor, and then just digging around the DCS files, but couldn't find it. Seems it never made it to release. My question is why? Obviously someone put a lot of time and effort into the model, as it looks fantastic, and it seems sad for that to go to waste. Being a simple transporter, I don't imaging there's really any additional functionality required of it either. (I'm thinking as a static/AI only model, not any Combined Arms functionality.) Obviously not a high priority in any way shape or form, but the images made me curious non the less.

Sounds correct . If spawning the player/client at mission start, they will always get the six pack positions 1-4. After mission start, even by 1 second, the six pack is no longer available for player or AI aircraft. Positions 5-12 are all on the elevators, and will be used next. Unless I’m miss understanding and you are saying it fills the forward elevator first, 11 & 12, instead of the second elevator in front of the island, 5-6?

Does anyone know if the new weather system will allow independent sea state/swell control, rather than being solely tied to wind strength? Even if not initially with 2.7, maybe planned in a subsequent update?

The Supercarrier manual shows you exactly the position aircraft are spawned to and in what order, both for the F/A-18 and the F-14. What it doesn’t show is which catapult each spawn position uses, which is where the image below, may help. This page explains the spawning rules and behaviours. https://wiki.hoggitworld.com/view/DCS_editor_carrier_spawns

Haha, sorry, we can get a bit passionate about this whole DCS thing at times

Thank you. I gave it a try and it works much better now. Seems I wasn’t waiting for the second conformation “beep”, such as after the “go to tanker” phrase. So even though it recognised the phrase, it didn’t connect it to the prior “two” call, and direct it to the correct recipient.

This may or may not be related, but I also experienced extremely slow transfer rates for wingman 2 on the right hose. Myself, wingman 3 & 4 were all able to take on 11k of fuel each from the left, in the same time wingman 2 took to take the same amount once. Track attached. EDIT: Interestingly, I did the above test again, and again number 2 on the right hose received fuel at a glacial speed. Only this time I called him off early with a join command. After disconnecting, his fuel level remained steady, and did not continue increasing like described above. I then waited for the left hose to become free, and sent wingman 2 back to the tanker, where he started receiving fuel at normal speed. Again, I called him off early, before becoming full, and this time his fuel level continued increasing after disconnecting. So it would seem these two issues are probably part of the same bug. AAR Bug-2.trk

I'm having issues sending commands to individual wigmen. It always send the command to the entire flight. I'm sure it's either a setup problem or user error, but if anyone could help it would be greatly appreciated. Basically what I do is say "two", wait for the small beep, then say the command, such as "go to tanker". The "two" call is recognized, and VA shows waiting for "additional input". Then the "go to tanker" command is sent to the entire flight, not the individual wingman. You can see the log below. (Ignore the "no flight recipients", I didn't have a mission running when I generated these, it was just for demonstration purposes).

Well, turns out calling wingmen to rejoin doesn't work at all, because they magically continue receiving fuel even after disconnecting from the tanker. Oh well...

Pretty simple, AI continue to magically receive fuel until full, even after disconnecting from the tanker. In the track attached, I called wingman 2 back to re-join when he had approximately 8-9K. His fuel quantity continued to increase to 14.8K even after he left the tanker. Attached is the track, and the test mission with a fuel check script used to observe the bug. (F10 menu operated) About to disconect, with 8.2K. After issuing a "rejoin" command (and the aircraft warping back at light speed, another issue) with 9.2K. And a few moments later after regaining position, with 12.8K AAR Bug.trk - MN - AAR Test.miz

As you guys are probably aware, the file USS_Nimitz_RunwaysAndRoutes.lua defines the CATs, spawn/parking positions and taxi routes on the Supercarrier. As some of us have discovered, modifying this file can produce significantly improved deck movements for different situations. It’s possible to disable CATs for launch, change spawn/parking points etc. You can see some of the work being done here. Unfortunately, this file is only loaded on DCS startup, so any modification or change applied remains applied for the entire session. To make the most of the endless possibilities available, what we really need is the ability to force this file to be refreshed/reloaded via a trigger, mid game. Users could then setup a number of different “templates” so to speak, and activate them as required. This one change alone (allowing the reloading of the .lua) would enable a number of often requested features, such as disabling CATs, realistic Cyclic Ops etc. Users could tie the triggers to custom F10 menus to have complete control of the deck.

Well, the pictures in the newsletter look nice, I’ll give ED that. Unfortunately as a single play user, most of what was discussed is completely superfluous to our needs. It’s not like I’m going to operate my own cut lights, or tell myself to start engines or recovery ops on the 5MC. ED keep saying that single players are by far their greatest number of user, and yet the improvements needed to enhance the single player experience alway seem to be the least important. There was not a single sentence in the update that answered my original questions re AI & ATC for the Supercarrier. Seems we’ll have to put up with the fact AI aircraft have little to no awareness of the players aircraft and how to sequence efficiently around them. Also no mention of light wands, plane directors for launch/parking, proper departure & bolter procedures/comms(for all cases), ACLS(which was supposed to be released early this year), or any of the other highly requested and promised features. I guess we just have to hope the “many other improvements” statement incorporates some of these. I’m trying not to be negative, I really am, as I know a lot of work has and is going into this module, a lot of which has never been attempted before, but I’m just surprised at where the focus is being directed at the moment. Again, the update had nice looking pictures, but maybe that’s the point. Nice shots of ready rooms and PriFly probably help sell the product, whereas it’s just not as easy to generate excitement over AI and comm improvements where pictures don’t tell the story as well.

I’ve found the relevant functions in the ME, but as mentioned further above, it’s not really a fix, just a bandaid. I still want to ‘relevant’ calls to be made. A contact all 200nm away is not relevant. Nor is the same call every second because the contact changes position by a fraction. It shouldn’t be all or nothing. Calls should be within normal radar identification range, and only one call per group. If the group ‘disappears’ maybe a realistic timer is started so it’s not immediately call again for a short ‘drop’. Maybe 30sec, or 1 min? Just something that keeps unnecessary calls to a minimum, but still provides tactical value.

Thanks. Exocet has helped me out with the script side of things when I asked in another post. Here’s his response for anyone interested. I didn’t think of using it in this case, but it’s a good idea. It should make timing the rejoin call much easier. I’ll have a think how best to implement it. Maybe I can get it to automatically display wingmen fuel quantity upon using the “go to tanker” command.

Often, when returning to the carrier from a mission, my wingmen are significantly lower on fuel than I am. Whilst I may be arriving back with 3000-5000lbs, they’ll have significantly less and need a refuel to avoid possibly ejecting in the arrival pattern. However, when refuelling prior to landing, AI always fill up the tanks completely, putting themselves way over max landing weight. Its possible to call them off the tanker with a "rejoin" call, but it's hit and miss how much fuel they have taken on. What we need is the AI wingman refuel radio command "Go to tanker", to offer two options, "Full fuel", and a "Fuel to land" option, which would only fuel the aircraft up to max landing weight. Having this function accessible within the mission editor and via lua script, would also be useful for those who would like to pre plan its use.

Thanks. I gave it a try, and they will disconnect as soon as the rejoin call is issued. Unfortunately the rate they seem to receive fuel seems considerably different to a player aircraft, so predicting when to call them off is extremely difficult. I might just make a wishlist item to split the refuel command into two, "Full fuel", and a "Fuel to land", option, which would fuel the aircraft up to max landing weight.

Thanks, I can’t wait

Flying the Hornet, is it possible to get my AI wingmen to take on a little gas, say 5000lbs, when instructed to AAR? Often, when returning to the carrier from a mission, my wingmen are significantly lower on fuel than I am. Whilst I may be arriving back with 3000-5000lbs, they’ll have less and need a refuel to avoid possibly ejecting in the arrival pattern. However, when refuelling prior to landing, AI always fill up the tanks completely, putting themselves way over max landing weight. Is there any way to limit how much fuel they take on?

Which function should I be looking for in the ME, to try and improve this? The missions I’m flying are part of MBots’s Dynamic Campaign, so I’m not sure exactly how they’re constructed, but I’d be happy to modify them slightly if it can fix this issue.

I completely agree with this. I’ve never understood the logic of using a transition layer in a combat environment. It’s not like I’m going to change my altimeter as I dive from 20k to 10k whilst dropping Mk83s. Keep it simple with one (or two if there’s a significant difference) theatre wide QNH. This is sufficient to provide air to air separation as everyone is on the same setting. Almost all combat aircraft have a rad alt, so terrain separation can be ensured that way, even if the theatre QNH is slightly different to the the actual, current location pressure. Local QNH around the airfield/carrier is the only other setting you need. Now, we just need the DCS AI to actually respect the current air pressure and change their altimeter settings, because this discussion is basically moot until they do, unless playing in a multiplayer, client only mission.

Thanks, I do fly the hornet and always forget about that feature. Unfortunately I’m fly a 90s campaign at the moment and D/L is disabled, oh well.

@Pieterras Does night time change anything re flying the acr on departure? A moonless night at see can be as bad as IMC.

Thanks for the reply Miguel. I realise you guys don't support MBot's original campaigns, and was just curious how it was currently handled. I'll have a closer look and see what I can do. Maybe I'll add the MOOSE Airboss script, as I have some experience with that already. Cheers.

I have a question re using the supercarrier in DCE missions. I've been playing MBot's F/A-18 Battle Group Delta campaign, and replacing the Stennis with the supercarrier. Generally it works well, but I have run into some problems, mostly around CASE III recoveries, but I guess any CASE could theoretically be affected too.. When checking in @50ish nm, I receive marshal instructions with radial, dme, alt final bearing, commence time, etc as expected. Unfortunately between receiving these instructions, and turning up in the groove 20-40min later, the carrier has often shifted directions completely, and my approach is completely porked. Looking deeper, there is a script that is run to turn the carrier into wind when launch or recovery ops are detected, but these are set to activate when aircraft are below 6,000ft or on the deck. Therefore the initial marshaling instructions become completely incorrect once the first recovering aircraft descends below 6,000 as the carrier shifts heading. Has anyone figured out an alternative way to trigger the carrier to turn into wind that works a little better, maybe related to the inbound call? Often there's a S-3 tanker at 6-8K overhead, so simply raising the trigger altitude wouldn't really work. Curious what others have done or how it's implemented in other DCE campaigns. Maybe MOOSE Airboss would be useful here, though it doesn't play with the suppercarrier perfectly yet either?