fargo007

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.

Yes. The UN isn't a country.

I look at it from the perspective of the Ka-50 being developed as an all-encompassing platform at the time of its existence. It had such a short service life if any, that it never reached its full and intended potential before the Ka-52 took over. We're really not dealing with a platform that was produced in great numbers and deployed very widely. Was the KA-50 intended to have Iglas and these other systems at some point? I believe the answer would be yes.

I don't understand why people are so emotional about this. The updates are for sale. If you don't want them, don't buy them. If you do want them but want to deploy the Ka-50 in a historically correct way for a certain time period, task or mission, you can still do so. Everyone still has a chance to be happy here.

Anyone else notice the quality of the shkval image deteriorated a lot in 2.7?

Breathtaking. At this point I wonder why Molevich doesn't just make it a flyable Mi-24 on its own.

Not sure about "Unit.", but if you add MOOSE to the build path it certainly does work this way with the MOOSE objects. e.g. GROUP: would produce a drop down with all the methods. Same with all the other MOOSE classes.

In the light of common sense, I agree with you on the third seat in the cockpit. The juice isn't worth the squeeze.

This is how it's done IRL. Just setting it to nighttime isn't remotely the same.

The bag is a series of opaque panels that attach via velcro in the back seat, and block the view of the outside world, forcing instrument-only flying. The hardest evolution to pass in the AH-64 training pipleline. Seems like it would be easy to do, a good challenge and useful training tool.

LMFAO It's funny because it's true....

Yup, BTDT. All the iterator functions have to be called in essentially a scheduler.

Thanks Kappa! The overarching issue I had was fundamentally misunderstanding that the ForEachGroup(func()) doesn't fire each time a new group gets added to the set. It has to be called via a scheduler or DO SCRIPT from the ME. What I would like to have is a callback function similar to :OnSpawnGroup(), where any time a new member joins a set, that function runs with the group object as its arg.

In for the interest. I know for sure you could (at least 2.5.6) spawn static objects on stationary ships, but not moving ones. I did this with cargos. Also pointing out - not everything that the ME offers has an accompanying facility in the scripting engine.

I agree, you have to expect some hiccups with a big version bump. And it's helpful to remind ourselves that we choose to fly the openbeta.

I tried and no go.

I agree, there are numerous improvements in there that I consider to be very substantial.