[Suggestion] Medical/Radios - Add 'Automatic' parameter.

[Sniperhid]

The basic idea here is make better the default paramters better for the lazy amongst us (cough myself). This applies only to parameters that are designed for mods. The simple idea is that if a mod is loaded, we run the code for that mod, if it isn't we don't. So why don't we just remove the parameter completely? Well it is possible that due to updates to the mod the component will no longer work and the off option would be a safe bet. It also might happen that some people simply don't want run certain things like e.g SWS.

Here is what I invision: Medical: What Automatic would do:- If running ACE - use ACE medical, if running AGM use AGM medical otherwise use SWS. Available parameters: Off, Simple wounding system (SWS), ACE3, AGM, Automatic

Radios What automatic would do: - If running ACRE2 - use ACRE2, if running TFR - use TFR Available parameters: Off, ACRE2, TFR, Automatic

Would other people be in favour of this? If nobody else likes the idea I'll keep this to the 1Tac fork.

The how: Mods can easily be checked if they are loaded by looking them up in CfgPatches

isClass(configFile >> "CfgPatches" >> "agm_medical") // returns true if the AGM medical module is loaded

[Wolfenswan]

Ah, now I get what you meant. It wasn't that clear from our convo on IRC.

Yeah I like that. It should be done with a single switch statement for each, right?

[ferstaberinde]

With the automatic option, what happens if there is a difference between mods loaded on the client and server - or is this a non-issue because we assume a client cannot even connect under such circumstances?

[Sniperhid]

That is a good question and not something I had considered. It is quite dependant on the how the server is setup. As far as I am aware ACE/ACRE/TFR/AGM are all designed to be run on both server and client and not optional. So typically any community running any of these will be running them on both server and client.

However if the server doesn't do any signature/modding checking it is possible to load the mods while the server hasn't loaded them, and conversely if the server has them loaded their is no guarantee that the mod will be loaded. However this can be seen as oversight by the server admin as this is quite unsafe and a security issue for the server, there are far worse things that can be happen if this ignored.

I believe we can overlook this and justify it as a server/community issue if people are loading mods they shouldn't be for any given server.

[NickvdLee]

Also, @ferstaberinde, how do you see mission makers approach the different module settings - Do you want F3 to support the most important / common ones by script to increase cross-compatibility between people with different mod sets or is this up to the mission maker himself?

[ferstaberinde]

@cptnnick - It's been a really long time since I touched a mod like ACE, so I'd like to understand a little more about the modules: what kind of variation is possible? What would a mission maker do if he wasn't using F3? Stepping back, my gut feel is for F3 to support only a 'standard' implementation of ACE3 features - and leave more exotic tailoring to mission makers / their community admins. The obvious follow-up question is then: what constitutes 'standard' for ACE3?

Per the discussion in #616 - are you planning to put all the code for the ACE3 in a separate sub-folder (like other components)? I'm almost minded to have a parameter called 'ACE3 Support' that - when switched to ON or AUTO (and ACE3 is detected) - tells our existing Gear and Medical Systems components to exit without doing anything, regardless of their parameters, and leave the work to scripts in an /ace3 sub-folder. An advantage of that would be that non-ACE3 communities could simply remove the sub-folder (and vice versa).

NB In such a scenario, the suggested AUTO value for params would be the default for Medical System, Radio System and ACE3 Support (new). Thoughts?

[NickvdLee]

@ferstaberinde - It's not fully out yet, so I'm hesitant to give a full scope prediction. It might be best to ask Nou. From what I read in their documentation so far they expect users to have all modules installed and for mission makers to configure settings by editor-placed modules, but a lot of components can be changed script wise as well.

If not using F3, a mission maker would thus place modules and include some script functions if he wanted to change some less accessible functionality. However, using the module removes cross-platformability somewhat (is this something F3 wants to support?) And for how much do we expect communities and their mission makers to set up their own personalized fork of F3?

I have done some digging, and so far it seems possible to influence ACE components by script, making it possible for common / basic settings to be set and changed within F3 instead of via module. The question is, is mission makers placing mod-specific modules something we want to avoid? And if he would always place the same modules with the same settings, wouldn't that be a good candidate for inclusion into F3?

Following #616, we only implemented the medical system for AGM, and left other items in the scope up to mission makers themselves. This is a bit confusing, in my experience a lot of mission makers expected the medical stuff to be handled in the assignGear component as well (which sounds logical). In that, I agree with having a greater ACE component seperate from the medical (which would constitute the switch between {off / SWS / (AGM legacy?)}.

I'm not sure how to divide the functionalities of that component (settings vs gear distribution) but that's a discussion for #616.

[ferstaberinde]

Thanks for that. If ACE3's design philosophy is to use placed modules, then we (you?) should probably have a chat with Nou and get a feel for how that team would like F3 to support their work in an ideal scenario. Remember that many (most?) communities take F3 and create their own templates - and in that context I wouldn't want our team to expend lots of energy dreaming up fancy scripted solutions to problems that communities might solve via their templates. As one possible example: if a mission maker is investing heavily in ACE3 functionality and units for his mission, how important is it really going to be to make it possible for a vanilla version to be produced?

[ferstaberinde]

PS An alternative - and I don't want to jump to this - is maintaining a second build of F3 that is focused on ACE3, with pre-placed units, modules etc etc.

[nicolasbadano]

From what I read in their documentation so far they expect users to have all modules installed and for mission makers to configure settings by editor-placed modules,

@cptnnick, no, that's not entirely accurate. You can configure most of the important things via modules, but the same things can be changed or overriden by entries on the server userconfig or on description.ext. I feel this last option may make more sense for F3, as it wouldn't interfere if e.g. ACE is not used. Besides that, we expect larger communities to just define all community wide settings on the server and force them for all missions, which would override anything defined at the mission level.

Feel free to jump on our public slack to discuss these things further if you want to.

Cheers

[NickvdLee]

@esteldunedain - Thanks for your response! I did know about the server userconfig for larger community, but I didn't think of the description.ext for individual mission makers. Setting up some entries in description.ext seems like the best choice then.

I'll be sure to jump on the slack if I run into things or have questions.