allow end-user setting of SET_GROUP FilterTypes for use by Ops.CTLD and Ops.CSAR

[DarthZyll]

with the advent of Dynamic Slots, now we can't fully rely on prefix group names anymore. Since at its core, the functionality to transport gear or rescue personnel is specific to the airframe, we should be able to just specify UH-60L, UH-1H, MH-60R, etc. Let this be a table that we can control, something like:

Csar.csarTypes = {'UH-60L','UH-1H'}

[Applevangelist]

Well the type names are in the group name of dynamic spawns, so u can use the type name as filter, but replace the minuses with a dot, ie "UH.60L". They are spawned with <airbase name>_<type name>_<number>

Possibly it’s niftier to allow user defined filter functions.

[DarthZyll]

i do think its niftier to filter on airframe, but more importantly, I feel its the proper use-case for most mission makers. They just want all Blackhawks, Hueys, Hips to be able to rescue and deliver troops and gear. Some want the Hind to do one or both as well (hence the user-flexibility), but I feel mission makers don't care for certain client spawns to be capable while others are not (which is what the prefix group name allows). Also when you leave type name up to the guys to enter correctly on each static group in the ME, there are bound to be issues. I'd rather control it at the script level, where we have one lua that our team uses to setup CTLD or CSAR, which defines the types, rather than having a dependency on inputs from the Mission Editor.

That all being said, I do see one challenge: these two Ops classes are using SET_GROUP, which does not have a FilterTypes function, which I find odd on its own.

Thanks for listening.

[thebgpikester]

I feel that trying to second guess what people are wanting will lead to disappointment and a long chase. Usually the answer is - "I want to do all the things, know all the things and have the ability to change my mind". If each pilot subscribes to a service ad hoc, they opt-in. Opting into multiple services is way better from a usage perspective that opting out or being hard forced into a role. I get that slots are often designed with roles synonymously. We shouldnt need to do that.

Typically workflows all begin with nothing, then the player needs to ask for what they want. e.g. I'm a helicopter pilot, but today i want AWACS calls because I want to ambush Chinooks with my air to air stingers. Or, I'm a multirole Hornet. I want air to air, air to surface, air to space and air to submarine missions please because I can. I i wanna listen to the csar channel to escort or HAVCAP them too. So typically in a workflow you ask for tasks, missions, callouts, information first, no matter what you are flying.

So why not have some consolidation around the menus for each class like playertask, awacs, CTLD, CSAR etc and just make sure that each has a subscription "Checkin" moment, like AWACS does, that begins the messaging or tasking, no matter what you are flying? This drives the task from the menu and adds players into tables/SETs in an easy common sense way.

If there was time I would even prefer that unsubscribed classes all stemmed from one root F10 menu to limit the mess. This way, until you subscribe to anything, there are no multiple levels taking up space. Something like "Player services". Underneath that, the list of classes you have: AWACS, CSAR, CTLD, PLAYERTASK, RECCE, whatever. Then if you browse to CSAR and "Checkin" the menu lifts up to the root level and then populates normally and the user isnt confused by multiple levels.

[Applevangelist]

https://github.com/FlightControl-Master/MOOSE/commit/865042a843ebf3d32b8f013e4ac5f89882c227bd

[Applevangelist]

Done