Restructure unitclasses into per side files
Needs Review, Needs TriagePublic

Description

We currently use a single UnitClasses.sqf file for all 4 sides in our modsets. For every combination we add a new one that has to maintained later with every update on code or the addons.
My idea is to divide it into one file per side, so we have UnitClassesPlayer, UnitClassesEnemy, UnitClassesIndep and UnitClassesCivilian. That way we have a single UnitClassesEnemy file for RHS AFRF to maintain and can then choose a different UnitClassesIndep file in the build script depending on terrain or mods that we want, for example a version for old RHS Indep units, new RHS GREF factions, something from CUP, our CAF units, etc.

The problem I see is how to seperate the files for arrays with an overlap between sides? We have that on most surprises, the parked vehicles and static weapons. We could handle it by:

  • choosing only one side and putting it in there. Least amount of work, but which side? What about factions that don't have the necessary units, on a different combination of addons we might want the other side? On the plus side no more mixed camps, but maybe we want that.
  • using two arrays, as with all the others. More work to a bunch of different scripts. Upside, no more mixed camps and the possibility to do for example different roadblocks for Enemy and Indep side. But again, maybe we want mixed stuff and what about missing units, would empty arrays be a problem? What about empty arrays for both sides?
  • changing all arrays to the style we use for ammo boxes. Using the pushback command we add to the existing array. Most work, but that way we could still mix. Separating arrays could of course still be done if we want. But this way we would have support to use more than one UnitClassesSide file in a mission (additional work). No idea how useful it is, but for example we can build a version with only the BIS version of UnitClassesCivilian, or one with only the CUP version. On a third we combine the two (and add a third or fourth) but still only maintain one file . It would allow people to easily add just a few more weapons or units from other addons and do their personal versions without changing it on every update.

I hope it's understandable what I want to say. Any thoughts? Problems I didn't think of? Any ideas how to actually implement that?

Scruffy created this task.Jun 7 2016, 8:50 PM
Scruffy created this object in space S1 Public.

Could you give an example what configurations you want to create? (e.g. based on RHS units).

About mixed camps: are they really necessary? Mostly there are strange consequences in war-torn mode.

Seperating factions, so it is easier to mix them.
Mixed camps is more like an oversight. We are working on cleaning that up a bit.

Here what I've thought out.

All mods UnitClasses are divided to several files (with equal names in each mod): units, units_ind, weapons, civilian, vehicles, vehicles_ind.
If it's needed mod is devided to several submods, E.g. for RHS:

  • RHS
  • RHS d
  • RHS mf
  • RHS w

RHS(base) contains common classes, "RHS *" contain corresponding classes only.
In this context RHS-US is another mod, not submod.

Each file contains pushback-style configs (I think we'll replace it with "append" command style later).

Builder config json will have these lines for Altis(RHS w) and Lingor(RHS mf):
{
"island" : "Altis",
"sqm": "Altis",
"units" : ["RHS","RHS w"],
"units_ind" : ["RHS"],
"weapons" : ["RHS","RHS w"],
"civilian" : ["Vanilla"],
"vehicles" : ["RHS","RHS w"],
"vehicles_ind" : ["RHS"],
"replace" : {},
"name" : "co10_Escape_RHS"
},
{
"island" : "Lingor",
"sqm": "Lingor3",
"units" : ["RHS","RHS mf"],
"units_ind" : ["RHS"],
"weapons" : ["RHS","RHS mf"],
"civilian" : ["Vanilla"],
"vehicles" : ["RHS","RHS mf"],
"vehicles_ind" : ["RHS"],
"replace" : {},
"name" : "co10_Escape_RHS"
}

E.g. let's build Altis. Builder copies "units" files from both "RHS" and "RHS w" submods to mission UnitClasses. Then it copies "units_ind" file from "RHS" submod only. Then weapons from both submods. Then "civilian" file from "Vanilla" mod (RHS mod don't have such file). The same for vehicles.

Somebody is needed to implement it in builder (I'm not Python programmer).

Maybe weapons should be combined with units, maybe some new subclasses should be separated (it depends on all used mods). I described general way only.

That is mostly like we planned it. We thought weapons should be side specific and this included with the faction. I also plan to modify the game to load the files and the compiler to just copy them. That will make it easier to adapt/reuse/restore modsets from people that modfied the mission without our toolchain. We will probably finish the new loading when both me and Scruffy are back from holiday (Scruffy this week afaik and me next?

You can always rely on me with RHS.

Good to know. We have a meetup arounsd 05.08 to 07.08. Would be cool if you are reachable by that dates.

I put up the first versions so you can all have a look. For starters I separated the old "Vanilla" and "Vanilla Apex" unitclasses into a bunch of new files. It already works if you unpack a mission by hand and replace the unitclasses.sqf with the new basefile, then add the other needed files to the missions\Units folder.

The "unitclasses.sqf" now losely inside the \mods folder is the base file, all empty arrays are declared there and also inside it is the //INCLUDE part where the Python placeholders need to go.
I made 3 files for the enemy and independent side: units, vehicles, and weapons
Player side has only units and weapons, as there are not so many that a separation seemed necessary to me.
Civ side has only one file, as it's only vehicles so far.

I separated the new files on the project into the folders of the side first (Player, Enemy, Indep and Civ) and I guess to keep it clean another subfolder for the mod (BIS, RHS, CUP, etc) would help (didn't create that yet).
The filename is for example "Enemy_E_units_BIS_Apex_CSAT.sqf", so we have the side in the mission first, then E or W to show if it uses East or West units, then we have units/veh/weap, next the mod (or here: BIS) and last the faction name.
I thought with the folders we can organise the files for ourselves in the project. The filename helps when someone looks at a compiled mission later when everything used is in one folder. It should be easy to see if at least one of each file is there, which factions are used, what is extended by a second or third file of the same type.

Renaming or sorting differently would be easy now, and please tell me if if you have any ideas we could do it better, or things I should separate or move to different files. Especially the snake charmers that need to implement this into the building script, if we can/need to do something to make it easier or work at all.
The new "config.json" file would look like Dystopians example from above for the "Mods" declarations, but with a few added lines as I made more parts?

When we agree on a format I'll start separating the other old files into the new ones.

I think:

  • comments must be wiped out of files. It's hard to sync them between files, and they can be always described in the porting manual or in unitclasses.sqf;
  • pushback must be replaced with append style:
a3e_arr_Escape_EnemyCivilianCarTypes append [
	"C_Hatchback_01_F",
	"C_Hatchback_01_sport_F",
	"C_Offroad_01_F"
];

But please not with

,"asdf"

syntax :)

There're also some equal classes in corresponding Vanilla and Apex files (e.g. Enemy_E_weap_BIS_Apex_CSAT and Enemy_E_weap_BIS_CSAT), I suggested above to move such classes to one file (just BIS maybe or BIS_CSAT).

NeoArmageddon added a comment.EditedSep 20 2016, 7:20 AM

I like the ,"blah" Style. It prevents the most common error or atleast makes it quick to spot when working with the configs.
I also don't see why comments should be removed. There is no real way to sync them between files. I can't really come up with a case you want to do that.

I like the ,"blah" Style. It prevents the most common error or atleast makes it quick to spot when working with the configs.

yes, sorry, my mistake. I found our old conversation about it. I was against not moving ]; to the next line.

I also don't see why comments should be removed. There is no real way to sync them between files.

All variables are self-documented. There is no need to describe them in each config file. And here's 2 diffs from current files:

--- Enemy_E_veh_BIS_Apex_CSAT.sqf	Mon Sep 19 01:46:49 2016
+++ Enemy_E_veh_BIS_CSAT.sqf	Mon Sep 19 01:46:49 2016
@@ -1,5 +1,5 @@
 /*
- * Description: This file contains the vehicle types  for the units spawned in the mission for the enemy side (east or west).
+ * Description: This file contains the vehicle types for the units spawned in the mission on the enemy side (east or west).
--- Enemy_E_weap_BIS_Apex_CSAT.sqf	Mon Sep 19 01:46:49 2016
+++ Enemy_E_weap_BIS_CSAT.sqf	Mon Sep 19 01:46:49 2016
@@ -1,5 +1,5 @@
 /*
- * Description: This file contains the weapons and magazines found in ammo boxes/cars for the enemy side.
+ * Description: This file contains the the weapons and magazines found in ammo boxes/cars for the enemy side.

And it's hard to fix such diffs in all files.

I can't really come up with a case you want to do that.

I can't really translate this sentence.

What I mean: The comments don't harm, neither when editing nor when committing. I don't see a reason to actively remove them.

OK, this is my last pro for comment deleting: in Civ_BIS_Apex.sqf comments are much bigger than the code.

Also "switch (_enemyFrequency) do {" construction in Enemy_E_veh_BIS_CSAT.sqf (e.g.) can be optimized such way:

a3e_arr_Escape_MilitaryTraffic_EnemyVehicleClasses append [
	"O_MRAP_02_F"
	,"O_MRAP_02_F"
	,"O_MRAP_02_F"
	,"O_MRAP_02_hmg_F"
	,"O_MRAP_02_hmg_F"
	,"O_Quadbike_01_F"
	,"O_Quadbike_01_F"
	,"O_Truck_02_covered_F"
	,"O_Truck_02_transport_F"
	,"O_Truck_02_ammo_F"
	,"O_Truck_02_box_F"
	,"O_Truck_02_fuel_F"
	,"O_Truck_02_medical_F"
	,"O_APC_Wheeled_02_rcws_F"
	,"O_APC_Tracked_02_AA_F"
	,"O_APC_Tracked_02_cannon_F"
	,"O_MBT_02_arty_F"
	,"O_MBT_02_cannon_F"
	,"O_Truck_03_device_F"
	,"O_Truck_03_transport_F"
	,"O_Truck_03_covered_F"
	,"O_Truck_03_ammo_F"
	,"O_Truck_03_fuel_F"
	,"O_Truck_03_medical_F"
	,"O_Truck_03_repair_F"
];
switch (_enemyFrequency) do {
    case 1: {//Few (1-3)
		a3e_arr_Escape_MilitaryTraffic_EnemyVehicleClasses append [
			"O_MRAP_02_F"
			,"O_Quadbike_01_F"
		];
    };
    case 2: {//Some (4-6)
		a3e_arr_Escape_MilitaryTraffic_EnemyVehicleClasses append [
			"O_APC_Wheeled_02_rcws_F"
			,"O_APC_Tracked_02_AA_F"
			,"O_APC_Tracked_02_cannon_F"
			,"O_MBT_02_arty_F"
			,"O_MBT_02_cannon_F"
		];
    };
    default {//A lot (7-8)
		a3e_arr_Escape_MilitaryTraffic_EnemyVehicleClasses append [
			"O_APC_Wheeled_02_rcws_F"
			,"O_APC_Tracked_02_AA_F"
			,"O_APC_Tracked_02_cannon_F"
			,"O_MBT_02_arty_F"
			,"O_MBT_02_cannon_F"
		];
    };
};

Moreover case 2 and default can be combined because they're equal.

Scruffy added a comment.EditedSep 25 2016, 3:51 PM

I switched the files I had done so far from pushback to append command.
Also added subfolder in the repository for mods.
Also included the new "switch (_enemyFrequency)" thing, much clearer and easier to read this way.

I did not check duplicate classes, the original VanillaApex file wasn't done by me and I only converted that, because the BIKI isn't updated with Apex classes. Fixing classes and balancing is for sometime later.

Same with comments, didn't change anything yet. I think it's a convenience issue, for anyone new working with the files not knowing them it's better to have an old comment than nothing, or having to search in different files. I think we could rather delete the one in the base unitclasses, as you don't change anything in there, except the INCLUDE part.
But I have put "write new comments" on my mental to-do list for a long time, along with "write a tutorial post for unitclasses" in BIF. Someday I might actually do it ^^
I'll create a new ticket for that