Working with Clients Instead of Groups

Hello,

I'm still having all kinds of trouble making groups work the way I want. I started looking at clients as a possible solution, since all the groups I'm working with are client slots anyway. What I'm trying to do it outlined below. Does anyone have any idea how to begin approaching this? I just keep thinking there has to be a simple solution, but every time I dig in, it gets ridiculous complicated in a hurry and ends up not working anyway.

1) Client enters a Polygon Zone A

2) Menu items appear (for that client only) and I don't care if they're from the main menu or not

3) Menu items are options to spawn adversaries from a list of late activated enemy groups AND will turn off the client's invisibility (on by default)

That's really it. I'm just trying to make an en engagement zone where I can fly in, select the type of aircraft I want to fly against and spawn it. I want this to be a piece of a larger training mission and I have tankers in the vicinity so I need to toggle the invisibility to make sure the enemies I spawn only see me, not other players on ground attack missions or the tankers.

Every approach I take ends in disaster and a lot of wasted energy. Does anyone have any head start to coding something, anything, like this that actually works? Trying to understand this concept.

Thanks for any help!

Menu (F10) generation is possible for group or coalition only. You will not have an option to add this for a single unit. The workaround would be to add all clients in their dedicated group. But that's another discussion. For your issue above (and bear in mind that I only use MIST and SSE) here's how would I approach it:

1) Client enters Polygon Zone A : you will use the function mist.flagFunc.units_in_polygon, let's say flag 101 will be set true.

2) You will need to schedule a function which is going to check for flag 101 and if this one is true then it will add an F10 menu command to spawn enemies (you will use addCommandForGroup function from SSE). If flag 101 is false then either you remove that command (you will use removeItemForGroup function from SSE) or you simply don't create the menu.

3) Here you will use function trigger.action.activateGroup (or dynAdd from MIST) to activate the group. Advantage of using dynAdd is that you can infinitely spawn the same group hence you will not have to add multiple late activated groups.

It is not easy, but is perfectly doable and it is indeed a very nice project. Imagine when you will have this one ready and fully enjoying it with your flying mates.

Menu (F10) generation is possible for group or coalition only. You will not have an option to add this for a single unit. The workaround would be to add all clients in their dedicated group. But that's another discussion.

Great to know! They're already structured this way, so no trouble there.

(and bear in mind that I only use MIST and SSE)

Here comes a dumb question: What is SSE? If it wasn't clear by now, I definitely qualify as a beginner with script. Does SSE have any documentation?

Client enters Polygon Zone A : you will use the function mist.flagFunc.units_in_polygon, let's say flag 101 will be set true.

I only know how to define a polygon zone in Moose. Is it difficult with MIST?

It is not easy, but is perfectly doable and it is indeed a very nice project. Imagine when you will have this one ready and fully enjoying it with your flying mates.

Way ahead of you. I can image the crap out this mission. I just haven't been able to get reasonably past that stage, :smilewink:

Thanks for your help. I'm not 100% sure how to accomplish all of these steps, but at least it gives me new things to research and test. I had pretty much hit a wall.

SSE : Simulator Scripting Engine. This is used by both MOOSE and MIST. If there is one thing you can't do in SSE then you won't be able to do it in MIST or MOOSE either. Documentation here :

https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation

I imagine defining polygons in MOOSE is similar to MIST (or maybe not). Basically you should create a point table and pass it to the function e.g.

local poly = {{x=11,y=12},{x=101,y=112},{x=113,y=122},{x=118,y=212}}

Then you would call this function

mist.flagFunc.units_in_polygon{ units = {'[blue][aircraft]'}, zone = poly , flag = 101 }

What that does is checking every second if a blue coalition aircraft is in the zone defined by poly and set the flag 101 to true. Obviously, there are many variation to this function as it is extremely powerful (you can thank Grimes and Speed for taking time to take SSE and make it very usable for mission creators) but that's a different topic. I would strongly suggest to check the Hoggit Wiki here and particularly SSE and MIST documentation :

https://wiki.hoggitworld.com/view/Hoggit_DCS_World_Wiki

https://wiki.hoggitworld.com/view/Mission_Scripting_Tools_Documentation

Wiki it is not complete at this point but it offers a great insight into DCS. I wonder sometimes if ED would like the community to be involved in expanding the wiki (assuming it is their project, obviously). I would happily volunteer.

SSE : Simulator Scripting Engine. This is used by both MOOSE and MIST. If there is one thing you can't do in SSE then you won't be able to do it in MIST or MOOSE either. Documentation here :

https://wiki.hoggitworld.com/view/Simulator_Scripting_Engine_Documentation

Thanks. This seems like the place most people should start, rather than a framework, since all the frameworks are just shortcuts using this.

I've actually wondered that too and I recently touched on the issue of incomplete or ambiguous entries in Wiki's and other documentation. It's really difficult to learn this (without a programming background) when the documentation is thin or difficult to understand in critical areas, especially considering it's rare to use one piece of code alone and most of the time multiple pieces are involved and have to reference each other etc.

One last question, because I can already see it coming: Is there an easy way in the SSE (or even Lua, I guess) to take a few dynamically spawned groups and add them to a table to iterate over in a function? I tried to do this with Moose and came up short. I used its "onSpawnGroup" and was able to declare a global variable outside of the function then assign it with that method, but I could never get it to push to table.

What programming knowledge I do have is in Javascript, and I push new objects to arrays all the time. Haven't been able to figure out a comparable way to do this in DCS. Just a big time saver, since I'd likely use that same table to check those groups for multiple conditions.

Any thoughts? Have you ever done something like this?

Thanks again for all your help! I'm off tomorrow and I plan to dig into this then.

Is there an easy way in the SSE (or even Lua, I guess) to take a few dynamically spawned groups and add them to a table to iterate over in a function? I tried to do this with Moose and came up short. I used its "onSpawnGroup" and was able to declare a global variable outside of the function then assign it with that method, but I could never get it to push to table.

OnSpawnGroup comes in handy when you only need to handle one or two groups.

Any more than that, I'd use SETs and iterators instead. (More on this below.)

1) Client enters a Polygon Zone A

2) Menu items appear (for that client only) and I don't care if they're from the main menu or not

3) Menu items are options to spawn adversaries from a list of late activated enemy groups AND will turn off the client's invisibility (on by default)

 

That's really it. I'm just trying to make an en engagement zone where I can fly in, select the type of aircraft I want to fly against and spawn it.

1) & 2) I'd create a new SET_GROUP containing all the relevant clients in your mission. (Note that these must be groups composed of just a single client aircraft).

Then I'd run ":AnyCompletelyInZone()" SET_GROUP iterator inside a scheduler, in order to regularly check for the presence of clients within the zone specified in ME (and then run the function(s) you're interested in for each of the groups in the SET_GROUP)

With that, you can create the group menu commands responsible for spawning the AI bandits when your specified clients are in zone.

3) Not sure about the invisibility thing (since I've never used it like that), but those late activated enemy groups can be included in another SET_GROUP (which you can filter as you like), and spawned/handled according to your needs.

Important note regarding late activated group names in MOOSE:

If you're interested in script/mission examples of this, just let me know.

I should be able to set up a demo mission for you (it would be good practice for me too :thumbup:)

 

Keep in mind, though, that MOOSE uses ME group names AS A PREFIX when spawning late activated groups (MOOSE noobs like myself learn this the hard way :megalol:).

 

So, basically, in order for MOOSE to find those late activated groups (after they've been spawned), you'll probably need to add "#001" at the end of their actual group name in ME.

 

Example:

Name of the late activated group in ME -------------------------------------------->"Group1"

Name given by MOOSE to that same late activated group (at spawn) ----------->"Group1#001"

 

So, if you've ever spent hours wondering why GROUP:FindByName("Group1") doesn't work after that late activated group has been spawned via MOOSE, this is why :doh:

 

Also, if the same prefix is used several times, I'm guessing MOOSE will add "#002", "#003", etc., instead (not sure, though).

So, in order to avoid dozens of hours of confusion and despair, use "SET_GROUP:Flush()".

This will tell MOOSE to log (in dcs.log) the actual names of the groups within a given SET_GROUP.

 

dcs.log flush example:

2018-09-05 21:24:35.736 INFO SCRIPTING: 11954( 120)/I: SET_GROUP01083.Flush({[1]=Objects in Set:,[2]=AnapaCASFleet_Haikou#001, AnapaCASFleet_Haikou, AnapaCASFleet_Moskva, AnapaCASFleet_Moskva#001, ,})

Thanks Hardcard. That spoiler is HUGE. It needs to be written in big, bold letters across the top of every Moose document everywhere. That's likely at least part of my issue working with groups. Could NOT figure out why I was unable to locate them beyond a certain point.

I'd still like to see what the SSE and MIST have, because ultimately, I think I'm going to have to take an all-of-the-above approach in my missions, but this definitely helps me sort out some of the confusion.

Thanks for the reply!

That spoiler is HUGE. It needs to be written in big, bold letters across the top of every Moose document everywhere. That's likely at least part of my issue working with groups. Could NOT figure out why I was unable to locate them beyond a certain point.

Yup, that's kind of "buried" within the MOOSE documentation.

It's actually explained (sort of) here ...in a pretty loose and indirect way :cry:

SPAWN:New("WhateverMEGroupName") simply defines a late activated group in ME to be used as a TEMPLATE.

SPAWN:Spawn() spawns a COPY of said template on the map (hence the "#001" after the ME group name).

I agree that this should be clearly explained in the MOOSE documentation, since this is the sort of thing that can potentially drive people away from MOOSE.

EDIT: Tbh, it's explained at the start of the page I linked above. Problem is that we lowly noobs have trouble connecting the dots sometimes... :doh:

In any case, just remember that I'm using variations of the method I described above in the mission I'm working on, so I should be able to provide practical examples.

Good luck!

I agree that this should be clearly explained in the MOOSE documentation, since this is the sort of thing that can potentially drive people away from MOOSE.

 

EDIT: Tbh, it's explained at the start of the page I linked above. Problem is that we lowly noobs have trouble connecting the dots sometimes... :doh:

Preachin' to the choir, man. I feel I'd be a lot further along if I was a better dot-connector.

I tried to map out how I would use the Group Sets for this and I realized I've actually done that once before with a different purpose, but I ran into the same thing I keep running into: When a member of that set does enter a zone, I don't know how to single out that specific group to run a function on it. So for instance, if I set up all my groups of playable units and I enter one and fly it into this engagement zone, I would want to do something, let's say send a message to me through my group only. How do I do that dynamically? How do I figure out which group in that set has actually crossed into the zone?

This is what I was talking about up top—the only way I can think of is to loop an if statement through a table containing all the groups in that set. Does Moose have a shortcut for this or do you know a different way to accomplish this task?

What that does is checking every second if a blue coalition aircraft is in the zone defined by poly and set the flag 101 to true.

This, and the Group Sets from Moose are both perfectly plausible ways to detect if a member of a coalition or set has entered the zone. It's that next part I can't sort out: How to figure out which group specifically has entered the zone and run a function on it and only it (without having to set up a separate scheduler with an if statement for every single group separately, which would be way too much code and horribly inefficient).

One last question, because I can already see it coming: Is there an easy way in the SSE (or even Lua, I guess) to take a few dynamically spawned groups and add them to a table to iterate over in a function? I tried to do this with Moose and came up short. I used its "onSpawnGroup" and was able to declare a global variable outside of the function then assign it with that method, but I could never get it to push to table.

Not sure if you can call it easy way but here is how I'd do it anyway. Spawning a group is done using addGroup function. I would use a function in which I call addGroup. Once addGroup is called I would insert the spwaned group name in a table. I can use that table to iterate over spawned groups. However, it must be said that such a feature already exists in MIST and is called mist.DBs.dynGroupsAdded so basically

I am spared to create such function for my missions.

such a feature already exists in MIST and is called mist.DBs.dynGroupsAdded so basically I am spared to create such function for my missions.

Thanks. I'm going to look at this from all angles and today, I'll head off to the MIST machine to read about mist.DBs.dynGroupsAdded. Thanks, also for explaining the steps. I think no matter what framework I use or if I just use SSE, it's going to help to understand what I'm actually doing. I'm trying to learn a lot of different, new things on parallel tracks and it gets a little messy.

It's that next part I can't sort out: How to figure out which group specifically has entered the zone and run a function on it and only it (without having to set up a separate scheduler with an if statement for every single group separately, which would be way too much code and horribly inefficient).

:D The problem is that you want group menus/menu commands, this makes things tricky (based on what I've seen).

Group menus are a pain in the butt, since they'll stop working as soon as you switch clients.

Maybe it's just that I don't know how to set them up properly, but the thing is that I asked around the MOOSE Discord channel about this a few months back and, based on the replies I got, it seems like a genuinely tricky issue (a DCS Group bug seems to be involved).

The only solution I've found so far is precisely what you mentioned: writing a separate script for each client group.

Sure, it's not elegant, but gets the job done, which is what matters in the end (you can crash, respawn and switch clients as much as you want, the group menus always seem to work that way).

Is your mission meant for SP or MP?

I mean, if you are going to use it for SP only, why not simply use coalition menus/menu commands?

No need to target individual groups then, which makes it all a whole lot easier.

Thanks Hardcard. It's nice to know I'm not totally on an island with this issue. It's just one of those that seems like it should be pretty simple, but it keeps popping up as really tough to solve.

I am making a multiplayer mission, so yes, I'd need to write one for each if I can't find some workaround. It's the dynamically-added-groups-in-a-table part that is holding up everything. Sounds like there might be some hope on the MIST front, but I know nothing about it and it's more confusing that Moose to learn, at least for me. The SSE isn't too simple either.

I'll keep fiddling with it and if I ever do find a way to make an efficient version of this, I'll post it here.

Thanks for all your help. Maybe I'll poke around in the Discord channel and see if I can pick up on some leads there too.

For the last two days I've been "investigating" different ways of targeting individual client groups when in zone.

First, I tried using a client SET_GROUP and iterators in order to handle group menus (it's definitely a nicer method), problem is that only the first client group detected in the zone would get the group menus... (I was probably missing something)

Then I tried to mix coalition and group menus in the same script file, but DCS didn't seem to like it.

Finally, I reverted back to the good old "one script file per client group" method, this finally worked as intended.

I'll post a simple demo mission tomorrow (it was a lot of fun to create).

It allows for specific client group detection when in zone and provides several functionalities via group menus/menu commands specific to each client group (combat group engage/disengage, smoke, remove combat groups from map, fleet bombardment, etc.).

Truth is that once you get group menus/menu commands working for each client group reliably, you can pretty much do anything.

While creating this demo mission I learned some handy new methods that I didn't know before, also, I've managed to get SET_GROUP iterators to handle some stuff successfully (SET_GROUP engage/disengage/remove from map).

Next step is figuring out how to use those same iterators to handle group menus :thumbup:

For the last two days I've been "investigating" different ways of targeting individual client groups when in zone.

 

First, I tried using a client SET_GROUP and iterators in order to handle group menus (it's definitely a nicer method), problem is that only the first client group detected in the zone would get the group menus... (I was probably missing something)

 

Then I tried to mix coalition and group menus in the same script file, but DCS didn't seem to like it.

 

Finally, I reverted back to the good old "one script file per client group" method, this finally worked as intended.

I'll post a simple demo mission tomorrow (it was a lot of fun to create).

It allows for specific client group detection when in zone and provides several functionalities via group menus/menu commands specific to each client group (combat group engage/disengage, smoke, remove combat groups from map, fleet bombardment, etc.).

 

Truth is that once you get group menus/menu commands working for each client group reliably, you can pretty much do anything.

 

While creating this demo mission I learned some handy new methods that I didn't know before, also, I've managed to get SET_GROUP iterators to handle some stuff successfully (SET_GROUP engage/disengage/remove from map).

Next step is figuring out how to use those same iterators to handle group menus :thumbup:

Oh my gosh, yes, this stuff ^^^. PLEASE post that when you have a minute. Your day sounds dauntingly familiar. I've spent entire weekends trying to work out one, little piece of a puzzle. It's through that trial and error that I've learned a lot of what I regularly employ now. We should share notes, :thumbup:.

Thanks again!

Hi there!

After a few days of expanding, testing and debugging the demo mission, I think it's finally ready for prime time! :thumbup:

As I said earlier, I haven't been able to use SET_GROUP iterators to handle client group menus, I've had to use separate scripts for each client group instead (7 client aircraft for each coalition, 14 total).

All client aircraft are basically from FC3 (Su27, Su33, MiG29S, J11A, Su25, Su25T, A10A, F15C), but I guess any flyable aircraft could be added, as long as it's fully functional within the DCS scripting engine.

Adding new clients is actually not that much work once you nail down the "generic script" for each coalition.

Just make a copy of that "generic script" for each new client in the coalition, then simply replace the client group name within the script as required, it'll work.

(Can't be grateful enough to the person who created the "Replace All" functionality in text editors :smilewink:)

Each active client group in zone should get its own group menu/menu commands, which enable several kinds of functionalities:

Client zone menu:

-Active client group identification

-Smoke ground units

-Ground units open fire

-Ground units hold fire

-Remove alive ground units

-Call in helicopter strike

-Call in bomber strike

-Call in fleet

Fleet menu:

-Request naval support (fleet weapons free + attack enemy ground target area for 2 minutes RED and 1 minute BLUE. Fleet AI is switched off after that, to avoid unwanted engagements)

-Switch fleet AI on (Added)

-Switch fleet AI off (Added)

-Remove alive vessels

Everything runs on a client group zone "detector" scheduler, which needs to be activated manually.

I've set it up like this because, otherwise, the scheduler would run all the time, consuming resources pointlessly.

Once the scheduler detects the relevant active client in zone, it'll enable the client group menu tree and stop (all functionalities within the group menu will still work, don't worry).

In order to get a "fresh" group menu tree, just rerun the scheduler (select "Load test!" menu command) and get back inside the zone (if you aren't in it already).

I've done quite a lot of testing and everything seems to work pretty much as intended.

Might've missed some stuff, though, if the mission gives you trouble, just let me know!

I'd be specially interested in knowing if this actually runs on MP...

I've put some spawn restrictions in place (to prevent undesirable "multispawning"), but I have no way of testing it in MP... it would be great if someone could test it for me.

NOTE: I foresee menu inconsistencies in MP, after other players decide to spawn/remove AI units, due to the lack of permanent menu refresh schedulers in the script.

For instance, if another client (aka player) decides to remove the allied fleet from the map after you've called it, you'll be left with a useless fleet menu... this could be avoided with permanent schedulers, but I'm not a fan of those.

Hope you find it useful!

PS: I guess I could also create a commented version of the "generic script" of each coalition, explaining exactly what every line/function/method does. Let me know if you're interested in such a thing.

EDIT: I discovered a couple of problems in the script logic, so I had to fix them. Also added some additional functionality for fleet management. Attached test mission updated!!!!

Zone Client Detection Demo v1.miz

Thank you!

Thanks! I'm so excited to go through this. It's like Christmas, having a working version of my issue just dropped in my lap! So helpful.

How can I find the lua file that has your MOOSE script to review? I don't see it when I unpack the miz file. I've never done this before.

Thanks again!

 

How can I find the lua file that has your MOOSE script to review? I don't see it when I unpack the miz file.

Tomorrow I'll start working on a commented version of the "generic script" for this mission.

I'll post it here once everything is checked and tested.

In the meantime, the 14 relevant Lua scripts are located in "Zone Client Detection Demo v1.miz\l10n\DEFAULT"

(Unpack them with WinZip/WinRAR/7Zip or whatever.)

Keep in mind that all these are simply copies of 2 "generic scripts" (BLUE and RED), just take one of each and you'll have the full script structure, so to speak.

I'm attaching the BLUE and RED "generic scripts", which, in this case, target the respective Su25T client groups in each coalition.

It's 360 lines each, so take it easy :book:

As I said, tomorrow I'll start preparing truly generic coalition scripts, with comments for each function/method. Much easier to understand what I did that way :thumbup:

Client Zone Detection Test Su25T BLUE.lua

Client Zone Detection Test Su25T RED.lua

Perfect, Hardcard. Thanks. These 360 lines are going to save me (and perhaps others in the same spot) weeks of trial and error! Can't thank you enough!

Hi again!

After several hours I've managed to comment the whole script with a fair amount of detail.

In the end I've decided that there's no need to comment the script for the BLUE coalition, since both scripts are very similar, there are no fundamental changes between the two.

Also, this Su25T RED script can be used for the rest of RED clients in the test mission (as long as ALL instances of "Su25T" in the script are replaced AND the client group name in line 36 matches the client group name in ME).

I hope you'll find this specially useful :book: :thumbup:

Client Zone Detection Test Su25T RED (commented).lua

I hope you'll find this specially useful :book: :thumbup:

VERY useful. You're aces! If there was a noob forum for ppl like me, this would have to be a sticky.

When/if I ever get my mission in a stable, working order, I'll shoot it your way for a peer review, :book:.

Thanks again!

Hi there again!

I've got great news!!!

Thanks to the nice people over the MOOSE Discord channel, I've finally learned one way of using SET_GROUP iterators to manage client group menus/menu commands!

Remember that my test mission had 14 scripts (one for each client)? Well, NO MORE!!!

I've managed to get the mission working properly with just 2 scripts (one per coalition)... actually, it might even work with just a single script, haven't tried merging the scripts yet, but it might work.

The good news is that the method I used in the script will allow you to do precisely what you wanted: target individual client groups without the need to use checks for each of them (or separate scripts for each client group).

I'm attaching the updated test mission and the 2 scripts that are used in it.

Haven't had time to comment it yet, but it's basically the same kind of script, with a few minor modifications.

NOTE: Now there's a permanent scheduler in place that refreshes/creates the basic loading menu for active clients every 5 seconds. If the F10 menu is missing after switching clients, simply wait for 5 seconds tops, it'll appear!

:thumbup:

Zone Client Detection with working SET_GROUPS for clients.miz

Client Zone Detection Test MooseClient RED.lua

Client Zone Detection Test MooseClient BLUE.lua

Thanks for posting that @Hardcard

The good news is that the method I used in the script will allow you to do precisely what you wanted: target individual client groups without the need to use checks for each of them (or separate scripts for each client group).

 

I'm attaching the updated test mission and the 2 scripts that are used in it.

Best news I've heard in weeks! This would unlock so much, not to mention cut out hundreds of lines of code in the mission I'm working on now. Thanks for posting this.

Yw, Delta!

The credit goes to Mechanist, for the most part, since I took the concept from his tanker script, which he posted on the MOOSE Discord channel and was kind enough to explain.

@rassy7

You bet it cuts out lines of code, my mission went from 5600 to 800 lines :D (not to mention the time savings)

Now if you want to create customized group menus for different client groups, all you have to do is include those in a separate SET_GROUP (which would target them specifically, via prefix filters, for instance),

then run the iterator for that SET_GROUP and pass on the client group value to the relevant functions. Easy peasy!

PS: I'm worried about MP functionality, though, I have only tested this in SP. I'm guessing that several modifications will be required in order to use this kind of thing in MP missions.