rassy7

Would certainly add even more value to the CA roles in a joint mission. Has this been added to the wishlist?

Hate to dig it up again, but does anyone know if it's possible yet to go from good weather to bad weather? Last I tried, the consensus was it was only possible to begin with bad weather that eventually stabilized. Also, I remember talk of dynamic weather not being synchronized in multiplayer. In other words, clouds for one player might be sky for another and vice versa. Any updates on these fronts, no pun intended—well, a little pun intended.

This makes so much sense Franky, thanks! Just opened up AI tasking, finally! I didn't even think to look there either. I had been primarily using this page for reference. VERY helpful! Zayets, I get those build module errors too and I know several others have reported them. I'm not sure exactly what they mean, but they haven't seemed to keep it from working so I just ignore them, for now.

Worth it, even if it's very frustrating at times to new coders like me. I wish some of the assumptions on which the framework was built were more explicit in the documentation, for instance when a method parameter is DCSTask and DCSTask is not explained anywhere and when I click on its link, it's essentially blank. I get the feeling smarter people know what that means, but for me, it renders every method using DCSTask useless. And things like how PartlyInZone(ZoneName) only seems to work when a group has more than one unit. I believe, in the ME, it will work regardless. That stuff I keep finding out the hard way. Of course it could always be idiot error when I'm employing it, but those seem to be solid. Anyway, the way my mission is structured, each group only has one unit so in this case especially, I think it will fit perfectly. Still need to test it though. This weekend. Thanks again.

This I need to try. Good idea! I was coming around to trying that, but was holding out belief there had to be an easier way with so many existential functions built into the framework. I think it has promise since each group only has one unit. For groups with several units, I think I'd have to spin through the entire group each time like Zayets function. I'll work on this again tonight. Thanks for all the help everyone.

Yep, this worked well, but not with a dynamically spawned group. It worked effectively the same as the GetLife() tests I ran and others. If I don't spawn the group dynamically and uncheck late activation box, it works flawlessly. I think it must have something to do with that late activated object in there. There is no way to kill it and I can't seem to get Moose not to see it, even though it's just sitting deactivated. Thanks anyway

Thanks. I have tried the GetLife(). I've also tried a combination of that and a null check. I am able to check if the group is dead appropriately, but I'm having trouble with it once that group is destroyed. It's like Moose doesn't want to recognize that the group died. I ran a simple GetLife() script and dynamically spawned, then kill, then spawned/killed etc. the same spawn object with the same group name over and over again through a couple schedulers and I could never get it to reset back to the same state as before the first spawn. Am I wrong or do these group objects cease to exist once the group object dies? I'll see if IsExist() gives me better luck tonight and also run that script, Zayets. Thanks again.

By the way, I tried nil--instead of null--first. This, with null, was just my latest attempt.

Using MOOSE Working on simple, helicopter spawn, base defense script. Idea is ultimately to look for vehicles from a group set in a zone, then check to see if the helicopter (InitLimit of 1, 0) assigned to that zone is spawned already. If not, spawn the helicopter and vector it to the vehicle with CAS task. If one is already spawned, then just vector with task. It's getting hung up on the "check if one is already spawned" part and I've narrowed it down to the script not recognizing that a group doesn't exist anymore. It will run through the first time, just fine. What I know: Spawn object created at script start Group object effectively returns null until I run the GroupName = SpawnObject:Spawn() At that point, it is not null If, however, that group object is destroyed, it won't go back to returning that group object as null This breaks my script and the scheduler stops working I've also tried to find it by checking if the GROUP:FindByName("GroupsNameinME"):IsAlive or not That doesn't work either Additionally, once I get this hammered, out, I'd like to work in a way to send the helicopter back to the FARP to land/despawn when the zone is clear and wait for another vehicle to enter the zone, but I can't find functionality for that. Is this part even possible? Should I keep looking? Thanks for help!

I've literally made zero changes to settings since last update. DCS ran just fine, smooth as glass when the F-18 was released. Now, again, with zero changes, DCS has this horrible stutter nearly always accompanied with a full crash. Just updated to the newest version (2.5.2.19273) and this stutter persists. It's been weeks now and at least one new update and nothing has changed. Can we go ahead and just undo whatever you did cause this already? Example: Computer specs in signature I have the latest Nvidia drivers Setting and log attached DCS Log.zip

Same here. Is this the kind of stuttering you're describing? I just pulled this tonight and haven't touched my settings since the Hornet was released. To your point, it was running fine then. If not, then I don't know what this is, but it's new as well.

This is true. These forums are torture. The waiting is the worst. Heck, I'd throw out $20 now for a half-modeled, primer gray helo that sounds like a Cessna. I can wait a year for that door to be totally finished or the pilot to have a face or whatever. I just want to fly the sucker.

Even a Chinook could open up some cool gameplay, especially with the new water. https://goo.gl/images/dWjqiT https://youtu.be/XOkdZVY-0UY

For what it's worth, I was kind of hoping part of the RAZBAM surprise would be a heavy chopper, or a heavy anything for that matter, but a CH-53 would have been aces with the Tarawa (once it can handle choppers).

That's a good point. I'm a glasses-wearer and they are really uncomfortable with my headphones pinning them to my head.

Oh my gosh. You're right. I'm an idiot. The actual number is never changing. Ugh. Thanks!

Sorry to bring this back around, but I'm looking at VR too and this is a big concern for me. My budget for VR is pretty much fixed at $500 +tax/shipping so waiting for 2nd gen for me means, really, waiting for third gen to get the 2nd gen knocked down in price. So I can pull the trigger now, but this gauges issue bothers me. With VR, is there any way to sort of make leaning in easier or multiply that movement, like in a Track IR profile? Really, as long as I CAN read the gauges somehow as opposed to it being truly impossible, I could adjust, but no way could I go entirely without a HUD or the DDI in the F-18 or TGP in the A-10. That would be a game-killer.

This? ^^^

Working out a proof of concept, template mission, trying to make troops unboard a helicopter when it lands in a zone. Everything works except the speed and altitude conditions. For some reason, the game believes the helicopter is constantly flying slower and lower than it is and troops unboard while helicopter is still in the air. How have I messed this up? Thanks for your help! LUA and MIZ file are attached and code is here: DEBUG = GROUP:FindByName("DEBUG") -- Cargo Creation and Loading InfantryGroup = GROUP:FindByName("Assault Troops") InfantryCargo = CARGO_GROUP:New(InfantryGroup, "Assault Troops", "Assault Alpha", 2000) CargoCarrier = UNIT:FindByName("Assault Helo 1") InfantryCargo:Load(CargoCarrier) -- Zone Creation LZ = ZONE:New("LZ") -- Create Variables for Helo Speed and Altitude HeloSpeed = UNIT:FindByName("Assault Helo 1"):GetVelocityKMH() HeloAlt = UNIT:FindByName("Assault Helo 1"):GetAltitude() -- Zone, Speed and Altitude Checks ZoneCheck = SCHEDULER:New(nil, function() if GROUP:FindByName("Assault Helos"):IsCompletelyInZone(LZ) then DEBUG:MessageToAll("Helo in Zone", 5, "DEBUG") end end, {}, 1, 10) Gauges = SCHEDULER:New(nil, function() if (HeloSpeed < 2) then DEBUG:MessageToAll("Helo Slow Speed", 5, "DEBUG") end if (HeloSpeed > 2) then DEBUG:MessageToAll("Helo High Speed", 5, "DEBUG") end if (HeloAlt < 75) then DEBUG:MessageToAll("Helo Low Alt", 5, "DEBUG") end if (HeloAlt > 75) then DEBUG:MessageToAll("Helo High Alt", 5, "DEBUG") end if (HeloSpeed < 2) and (HeloAlt < 75) then DEBUG:MessageToAll("HELO LOW AND SLOW", 5, "DEBUG") end if (HeloSpeed > 2) and (HeloAlt > 75) then DEBUG:MessageToAll("HELO HIGH AND FAST", 5, "DEBUG") end end, {}, 1, 10) UnboardCheck = SCHEDULER:New(nil, function() if GROUP:FindByName("Assault Helos"):IsCompletelyInZone(LZ) and (HeloSpeed < 2) and (HeloAlt < 75) then -- This will Unboard the Cargo from the Carrier. InfantryCargo:UnBoard() DEBUG:MessageToAll("UNBOARD", 5, "DEBUG") UnboardCheck:Stop() DEBUG:MessageToAll("Schedule Stopped", 5, "DEBUG") end end, {}, 1, 10) Cargo Unboarding Helo.miz Cargo Unboarding Helo.lua

Is it possible to get the altitude of a positionable in AGL?

Ha ha ha, exactly!

Maybe we aren't thinking outside the box enough. Pilotable tanker? Walkable carrier/submarine? 1st or 3rd person, moveable pilot to walk around and enter/exit aircraft? FPS elements? Crew chiefs?

Ok, it's time for Razbam to jump in here with the announcement before we make it all the way to the Death Star.

I would welcome ANY heavy (helicopters too) but any variant of a C-130 would kick mission design wide open. It'd be pretty cool to see the stuff people come up with if that is the case. Fingers crossed! Additionally, regardless of the announcement, how long would it likely be before something would actually hit early access? End of year? 1-2 years?

This is a lifesaver! Thanks to everyone!