Jump to content


  • Content Count

  • Joined

  • Last visited

About fargo007

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.)
  2. 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 p
  3. 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.
  4. 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()
  5. 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.
  6. 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().
  7. Happy to help.
  8. Yes. The UN isn't a country.
  9. 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.
  10. 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.
  11. Anyone else notice the quality of the shkval image deteriorated a lot in 2.7?
  12. Breathtaking. At this point I wonder why Molevich doesn't just make it a flyable Mi-24 on its own.
  13. 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.
  14. In the light of common sense, I agree with you on the third seat in the cockpit. The juice isn't worth the squeeze.
  15. fargo007

    The bag

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