Towards better plug'n'play (...or configFile as an ontology)

[rübe 127]

Target state:

Download a mod, play your favorite mission that automatically offers you the option to play with that mod. Enjoy.

Current state:

Download a mod, oh... over there is the editor, I guess?

...and from a mission writer's perspective: oh look, cool new mod. Too bad I'd have to manually adapt/rewrite all my mission to support that very mod. I'll pass, I guess?

No matter if that mod is a new faction, a complete new side, an AI mod, or a new map. Clearly there is currently way too much work needed to combine any mod with any other mod. And we end up with mods nobody plays with (warning: hyperbole). In an ideal world, all these things would be plug'n'play.

And while we're stating the obvious: the players are not and will never be able to solve this problem. The key person to make this all happen is the mission writer (and to a lesser degree addon makers, simply by writing good configs): he needs to anticipate any mod out there, even stuff not even existing yet.

And some are indeed doing their best with current means/the current environment. In general, there are two ways to do so:

1. Manual labor: they manually integrate new mods (they deem worthy) by maintaining all kind of lists. Apparently we need to stop doing this. This shall no more be the workaround to such a common (and rather important) problem: it's super slow, error prone, and tedious and boring as hell. It's a clusterfuck and it doesn't really work. It can't.
   
2. configFile: Behold! The first ray of light! The mighty configFile! So you (as a mission writer) need to read out the available (system dependent) factions. Well, good news then: config.bin/CfgFactionClasses exists, parse it and you get a list of all factions, including several key attributes (displayName, priority, side, icon, flag). With the priority attribute you can easily filter out the "main"-factions (e.g. no FIA-fakes thingy; how did this hack even happen, instead of finally fixing the whole side/faction problem/restrictions... nevermind). Point being: retrieving available factions, instead of hardcoding them in some obscure lists, is by far the better option. The bad news is: the configFile only get's you so far...
   The configFile was never designed to solve the problem we're trying to solve here. The configFile - oversimplified - just strings all the things together. But to make plug'n'play happen (in a holistic sense, if you want), we need to ask questions the configFile just is not able to answer (not directly anyways). Because it's just that: a configuration file.
   

I think "fn_returnGroupComposition.sqf" from the official function library (it's from A3, but yeah, looks like dead code to me aswell...) illustrates the problem very nicely. It comments:

//TODO: better replace by a system based off CfgGroups?

...and then goes on to do what anyone else always ended up with. Writing some stupid lists down à la (hi Joris, ):

private ["_pool"];
_pool =
[
[
	"USMC_Soldier_TL",
	"USMC_Soldier_AR",
	"USMC_Soldier",
	"USMC_Soldier_AT"
],
...

Or had you ever have a look at that staticData.sqf from ALiVE? It's the perfect example, and that file is over 100KB in size, doing exactly what this thread here is all about (just the "good" old fashioned way).

So... what do we need instead (or maybe "on top" of the configFile)?

An ontology

see: Ontology (information science)

There is a reason why we aren't just using CfgGroups (e.g. to spawn such groups from automatically detected factions, no matter which origin). Sure, we can descent into config.bin/CfgGroups/West/BLU_F/Infantry, where West is the side, and BLU_F the faction. And then there is one more level down the hierarchy that actually seems reliable: classes like "Infantry", "Mechanized", "Armored", "Support", "SpecOps" (seemingly not infantry?), "Motorized_MTP" (okay, that's a bit weird; why the suffix? Are there more?).

But that's where it stops. From there, anything goes: "IRG_InfSquad", "BUS_SPGSection_MLRS", "OI_recon_EOD", you simply can't work with such things any longer in a meaningful way (have fun parsing those classnames for some clues...). And you can't just pick at random either (say within such a "well-named" class).

At the core of an ontology is a common, shared (fixed and controlled) vocabulary. And I argue that this is exactly what we need, and from there, that it will be enough to extend the configFile (without breaking anything already existing; fully backwards compatible that is).

The solution can be sketched as follows:

• Introduce that common, shared (fixed and controlled) vocabulary. The vocabulary consists of entries with:
  
  1. a config path/or parent entry,
     
  2. the word used as key in the config, and
     
  3. a definition of the word,
     

  [*] Words in the vocabulary can be parents (or classes, or maybe defined as sets with child words) or leaf-words, that define a most concrete thing (still on an abstract/meta level). A perfect match (easily modelled that is) with the configFile. Same recursive structure.

  [*] Integrate parent-words as classes into the configFile (under some new branch), with sub-classes that are not leaf-words being always defined/present, even if empty.

  [*] Every leaf-word is a mapping to some very specific class (or an array of specific class, maybe with some rule/function to pick from), somewhere else in the configFile. To give an example: let's have "Side/Faction/Infantry/TeamLeader" in terms of our ontology, which maps to config.bin/CfgVehicles/B_Soldier_TL_F, an existing class - as defined by the author of the addon that created this faction. This mapping is the work of addon makers. And they simply need to use the correct vocabulary, and then link to their own classes. That should not be too much of a hassle/to ask.

  [*] Finally mission writers need to rethink, and use (leaf-)words of the shared vocabulary, instead of hardcoding side, faction and even unit classes. Stop writing "B_Soldier_TL_F", and say (side>faction>TeamLeader) instead (requirements would either have to be checked first, say in order to respect/offer some addon, or there might be some fallback mechanism). Either way, this will be easy for the script-fanatics, not so much for the editor-fans. Hence there is probably one last point to make:

  [*] Editor-Integration: instead of putting down units from sides/factions, let's have some structure and use... the shared vocabulary. Mappings are in the configFile. No big deal. Of course, it's still up to mission writers, if they want to offer, say a faction/island setup or configuration, with whatever is installed on the users machine. But if made easy enough, I'm pretty sure this would soon catch on.

Sounds easy, hu? So why didn't I simply open a ticket/feature request, instead of spamming poor BIS forums?

Because it's not easy. Not at all, I'm afraid. It's that stupid vocabulary.

The vocabulary

Oddly enough, there is some kind of code, by means of infixes or suffixes, that pretty much already emulate, what we're up to. Every noticed those class names: B_soldier_SL_F, B_soldier_AR_F, B_engineer_F, B_soldier_AAT_F, ...? Lemme guess: Squad leader, Assistant Rifleman, uhm, Engineer?, Assistant Anti Tank? You get the drill. Well, that's exactly what we need. For a start (I mean, it's very much also a question of scope...), it would be fantastic to have a vocabulary of all infantery roles. Then if you're releasing your next faction, you simple write that mapping and link those roles up to the units you've implemented.

Now let's all agree on that vocabulary of all infantery roles.

That's the hard part.

Here a list I've assembled some time ago with respect to BIS's usage of these in-/prefixes (clearly these can't be directly taken without further consideration; shouldn't some stuff be rather an attribute/parent- or subclass, e.g. standard vs recon guys?):

   <empty> or <numeric>    Rifleman
   light                   Rifleman (Light)
   A                       Ammo Bearer
   AA                      Missile Specialist (AA)
   AAA                     Asst. Missile Specialist (AA)
   AR                      Machinegunner
   AAR                     Asst. Autorifleman
   AT                      Missile Specialist (AT)
   AAT                     Asst. Missile Specialist (AT)
   crew                    Crewman
   diver                   Assault Diver
   diver_exp               Diver Explosive Specialist
   diver_TL                Diver Team Leader
   engineer                Engineer
   exp                     Explosive Specialist
   GL                      Grenadier
   helicrew                Helicopter Crew
   Helipilot               Helicopter Pilot
   infantry_pilot          Para Trooper
   infantry_SF_s           Recon
   infantry_SF_s           Spotter
   infantry_sniper         Recon Marksman
   LAT                     Rifleman (AT)
   M                       Marksman
   medic                   Combat Life Saver
   MG                      Machinegunner
   officer                 Officer
   pilot                   Pilot
   recon                   Recon Scout
   recon_exp               Recon Demo Specialist
   recon_JTAC              Recon JTAC
   recon_lat               Recon Scout (AT)
   recon_medic             Recon Paramedic
   recon_TL                Recon Team Leader
   repair                  Repair Specialist
   SL                      Squad Leader
   sniper                  Sniper
   TL                      Team Leader
   UAV                     UAV Operator

And as just said: it's a question of scope aswell. How about:

• A vocabulary of weapons (sniper-rilfe, light machine gun, pistol, AT, AA, ...)
  
• A vocabulary of vehicles (main battle tank, mech. transport, mot. transport, ...). Would we need to give a min, capacity in the definition of such words? Are there other things we might need to specify, in order to "allow" linkage to specific classes?
  
• A vocabulary of groups Something along the lines of CfgGroups. Compositions of infantry and vehicles, described by a proper word/role.
  
• A vocabulary of buildings/structures (military, civilian, stronghold, tower, house, sleep-place...) What are the words? What rather attributes in the form of a parent-class, e.g. buildings>military>tower, vs. civ>military>tower; or indeed as attributes to filter for (too complicated already?). And again: can we specify things in the definitions of words?
  
• A vocabulary of plants (trees, bushs, ...) - ...oh, wait, are these things still classless? Nevermind then...
  
• ...
  

For a start/a first milestone, infantry roles and vehicles would IMHO need to be defined as bare minimum. E.g. weapons then can be inferred from the mapping of infantry roles. And groups (i.e. infantry and vehicle compositions) can be combined as needed. Although it would be better if we also had a vocabulary for groups: the maker of a faction should define how to map these groups, how these elements/compositions would look like, thereby giving that faction their own, very flavour and character. A mission maker should ideally be able to leverage this knowledge (automatically by using just the right vocabulary on just the right level of abstraction). Instead of manually (re-)creating groups, one should simply put down a fireteam, an AT team, a squad, ...

CfgGroups (or other branches of the config) got very close to be useable (in the sense of an ontology) here, unfortunately it's rather made to merely populate lists in the editor, more than anything else.

The thread/discussion

Reason number one for this thread is to come up with said vocabulary, and to have a discussion about "good" words, or words we need (and words we do not). Maybe we can already have a look at mappings to the official factions as a starting point (reverse engineering, but better not repeating old mistakes, blindly picking "bad" words).

Secondly, let's discuss scenarios how such plug'n'play could work. Plug'n'play factions are one thing. What would you do with a "vocabulary of buildings/structures"? What would this mean for your AI plugin? For your new island?

And for sure, you're also invited to discuss the overall topic (and proposed solution), from the perspective of players, addon-makers and mission writers alike. You think this is all a bunch of mumbojumbo? Let me know! :(

Edited April 5, 2015 by ruebe