Best Way to Check if Group Doesn't Exist

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!

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

you might want to run a getLife() function: if returns less than 1 then is dead

Here, a quick and dirty function to return true if group is dead or false if it's still alive

[color=#d3af86][font=Consolas][color=#a57a4c]--Check if group can be discarded from the books. If sum(Units lives) less than 1 the group is dead for me[/color]
[color=#98676a]function[/color][color=#8ab1b0] groupIsDead[/color][color=#d3af86]([/color][color=#d3af86]inGroupName)[/color]
[color=#98676a]local[/color][color=#d3af86] groupHealth [/color][color=#d3af86]=[/color][color=#f79a32]0[/color]
[color=#98676a]local[/color][color=#d3af86] groupDead [/color][color=#d3af86]=[/color][color=#f79a32]false[/color]
[color=#98676a]for[/color][color=#d3af86] index, unitData [/color][color=#98676a]in[/color][color=#7e602c]pairs[/color][color=#d3af86](Group.[/color][color=#8ab1b0]getByName[/color][color=#d3af86](inGroupName):[/color][color=#8ab1b0]getUnits[/color][color=#d3af86]()) [/color][color=#98676a]do[/color]
[color=#d3af86]        groupHealth [/color][color=#d3af86]=[/color][color=#d3af86] groupHealth [/color][color=#d3af86]+[/color][color=#d3af86] unitData:[/color][color=#8ab1b0]getLife[/color][color=#d3af86]()[/color]
[color=#98676a]end[/color]
[color=#98676a]if[/color][color=#d3af86] groupHealth [/color][color=#d3af86]<[/color][color=#f79a32]1[/color][color=#98676a]then[/color]
[color=#d3af86]        groupDead [/color][color=#d3af86]=[/color][color=#f79a32]true[/color]
[color=#98676a]end[/color]
[color=#98676a]return[/color][color=#d3af86] groupDead[/color]
[color=#98676a]end[/color]
[/font][/color]

EDIT: btw, you can also try this (but most probably even if the group is dead it will return true, didn't tried it but you can give it a shot) :

Group.getByName('MyGroupName'):isExist()

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.

Here, a quick and dirty function to return true if group is dead or false if it's still alive

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

You have figured out that spawning the Group returns the object. You should be able to do an IsAlive() on that Group object

I'm afraid there's no function IsAlive() in the scripting engine. Funny stuff, I was convinced there's one but could not find it in the whole documentation.

As for the dynamically spawned groups, most probably you pass the function an invalid name because all my groups are spawned dynamically and function works perfectly. I am not sure how you pick the spawned group name to be fair though.

EDIT: by scripting engine I mean, of course, DCS scripting engine library. There are functions in MIST (mostly flag checking ones where a group health is evaluated). Not sure about other scripting tools though.

If, however, that group object is destroyed, it won't go back to returning that group object as null

trying to check this by an event dead ?

I'm afraid there's no function IsAlive() in the scripting engine. Funny stuff, I was convinced there's one but could not find it in the whole documentation.

As for the dynamically spawned groups, most probably you pass the function an invalid name because all my groups are spawned dynamically and function works perfectly. I am not sure how you pick the spawned group name to be fair though.

EDIT: by scripting engine I mean, of course, DCS scripting engine library. There are functions in MIST (mostly flag checking ones where a group health is evaluated). Not sure about other scripting tools though.

He uses MOOSE (see first post) and MOOSE has an IsAlive() for the group class.

trying to check this by an event dead ?

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.

You can also try with event dead but this will return which unit is dead (that's because Group class is not a child of Object) so you will still have to cycle through group units. The advantage, if there is one, is that you can get the group having that unit destroyed without any doubt. However, you will have to keep somewhere the information that one unit from that group was destroyed and make the calculations to see if other units are still alive or not. My little script (as long as you pass the correct group name) will tell you without a doubt if the group is dead or not. I can make you a mission to prove it but right now I try to install moose framework to give it a whirl, see how it goes.

right now I try to install moose framework

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.

Yeah, that's the problem with Moose, installing the framework is sometimes prone to little inconveniences. For example, once I created the initial project and added Moose Development as project path it gave me 5 Build module errors. Hope is nothing serious.

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.

(DCS)Tasks are described in the controllable section https://flightcontrol-master.github.io/MOOSE_DOCS_DEVELOP/Documentation/Wrapper.Controllable.html

You need to get the task first and than execute it. But best explained by an example I guess :)

-- Get helo group named Huey.
myhelo=GROUP:FindByName("Huey")

-- Define some place to land, e.g. 100 meters east of the current position.
Vec2=myhelo:GetCoordinate():Translate(100,90):GetVec2()

-- Get DCS Task to land and stay for 60 seconds.
MyDCSTask=myhelo:TaskLandAtVec2(Vec2, 60)

-- Set/execute the task.
myhelo:SetTask(MyDCSTask)

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.

IsPartlyInZone() actually checks exactly that, i.e. if a group is partly but not completely in a zone. So if the group consists of only one unit, it will never be true. You should use IsCompletelyInZone() in this case.

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.

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!

No problem. AI tasking is not very intuitive but only the first time. Have fun :)

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.

I don't think that will stop LDT running MOOSE, intellisense is working just fine. Played last night with framework config as per Youtube or documentation (btw, I believe MOOSE needs a refresh of the framework install and setup as there are couple of different ones, doc, youtube etc) and noticed that launching first example mission failed with error it could not find EVENT (basically first line) something did not loaded. I can of course continue but just realized how easier to work with MIST is.