fargo007

Simply: Yes. You need to check the MGTOW of the loadout you are putting on there. Four rocket pods, four Shturms and a full tank of gas will put you at 108% or so. In order to come down to 100% MGTOW, you will need to drop fuel to 50% with that loadout. You can still take off (e.g. rolling takeoff) and fly once you hit ETL, but at 108% you aren't going to be throwing her around like a go kart. This is also why people are complaining that they are out of right pedal authority when they pull power and it yaws left. You need not only enough torque to hold it straight, but in that situation you need enough to also overcome the existing yaw rate. At 108%, there's not enough torque remaining to do so.

Yes, expected behavior. The Mi-24's rotors are tilted forward several degrees, so it will hover in a "nose-up" attitude. This makes it far from optimal to deploy ATGM's from a hover. What you CAN do is slow way down as you come off your IP toward the target. This reduces your closure rate with the target, and allows you to get off a second shot if necessary.

Known issue I think. Have your front seater go back to spectators and rejoin and you will have them all operational. We also found an issue where it would let the front seater fire only four of the eight when going from station 1-8. Workaround: When fired from station 8 going down to 1, they all fired as they should.

Short tap is where it's at. What you guys want to do is fire from one side only. There's a left-center-right rocket switch. If you turn it to a side and touch it off smartly, you'll get two rockets. Great for checking impacts and adjusting accordingly. Then you can spam the ever lovin' stuffing out of em. I've fallen into alternating left/right sides outright on each pass or engagement.

While I agree it's needed for completeness sake, I still don't understand why people don't just bind the controls and use them. Every single control on the countermeasures panel can be bound. Off a cold start in a multiplayer server I have no problem setting up and using countermeasures. If someone is flying around with no CM active, they are doing so because they choose to.

Does anyone know which version(s) of the 9M120 ATAKA will be added to the Mi-24? Thank you.

You can bind all of those right now. What I use to see them is RCtrl-Rshft-keypad* to slide forward and look down and see how they are set. Or use voice attack to set them, e.g. "Petrovich - enable countermeasures!"

That's fine, I'd like them to be activated along with the weapons, but all of this does work in MP, and I use the technique as a work around all the time. Multiplayer servers cannot limit which keys you can bind, or where you adjust your cockpit view.

LOL - Oh yes, but you can't throw it around like a go-kart.

It's a team sport. This is where having an OH company flying a Gazelle M or a Kiowa doing recon for you and talking you on could really help.

It sounds like you have controls cross-bound to axes that shouldn't be. Double check them all. Frequently a new module will have every control bound to every axis and you have to remove them all. Easy test would be a hot start, and just sit there and move each control up and down and observe that no other controls react.

Yup, that would be better but won't work for VR folks tho.

If you are running out of pedal authority to the right, you're just overweight. Check your loadout & fuel in the ME. With full fuel, four Shturms & four rocket pods, you'll be 108-110% over MGTOW. You can still take off overweight with a very careful or rolling TO, but you're not gonna throw it around with pedals like you rented it with a gift card. You'd have to reduce your fuel to 50% to be 100% MGTOW.

You can still bind all the keys yourself to make them work. And to see the status of switches, bind RCtrl-Rshift-keypad / and * to a hat and you can slide your view forward and look downward to see how they are set. These are also handy binds for managing your pit position. I like my own stick to match the one in the sim for the most part.

How about those late-activation statics y'all asked about a ways back?

Put it there as "takeoff from ground" not ramp.

This thing excels at throwing rox. Now more than ever, the rockets in DCS at large need fragmentation damage added to the model.

Yes. I do this in MOOSE. Easy. 1 - Create a polygonal zone object that includes the areas of the rig you're concerned with. 2 - You can then declare your SPAWN object as usual, and use :SpawnInZone() to spawn it there. We also spawn statics there with similar techniques (e.g. cargo to be picked up, etc.)

I've climbed this mountain, and it's not easy. The methodology I used was based on Pikey's simple saving scripts for both groups and statics. They basically work by writing a serialized save file (lua table) consisting of every unit on the map in an interval. On restart, it creates a set of every unit/group/static and removes them. They are then replaced by the written file. I had to highly modify them, to ignore groups & units with certain names that I specifically didn't want to be persistent, or things that just didn't work well (like persistent cargo objects, moving vehicles, etc.). Many other entities need to be managed as one-offs as well - CSARs, CTLD fobs, FARPs, etc. But it absolutely can be done. And it truly does work fantastically. Our campaign server restarts every morning (reboots) and it comes up and loads the campaign mission. Everything is exactly how it was left the last time someone flew on it.

When you send a cruise missile (BGM-109 from the Ticonderoga class, for example) unless the target is on ultra flat ground as the missile approaches, it will go squirrely and overfly the target. It seems the missile should be lofting much earlier and much higher in order to avoid this. Easily reproduced using CA to fire at targets in even a moderately hilly area.

Clients are different objects, so to manage those best you'd want a different set (SET_CLIENT). And no, the sets do update dynamically (if configured to do so, e.g. :FilterStart()

NP, I'll add that the declaration of the SET_GROUP doesn't need to live in the scheduler, as you're declaring it newly every single time. More efficient to have it not be local, and be declared outside the scheduler, only once. Now that I've seen what you're after, you can also have a look at zone_capture_coalition, which sort of does what you are doing, right out of the box. e.g. I got lots of help when I started with all this, so I'm very happy to pass it forward.

A couple ideas..... 1 - Use the ME to set flags, then read the value of those flags in a scheduler in your script. 2 - In MOOSE entirely, create a SET_GROUP, and filter on coalition. Create a scheduler that has an appropriate SET iterator method in it that checks for the presence of filtered elements in the zone, e.g. SET_GROUP:ForEachGroupPartyInZone().

Happy to help.