Jump to content
Locklear

Characters And Gear Encoding Guide

Recommended Posts

Hello modders!

I'm Locklear, an encoder in BI, and you might have seen my posts around here on the forum, when I tried to help some of you with stuff and things (mostly the things). I usually (although not exclusively) work on characters and equipment, so I decided to create a guide for configuring those on the community wiki. The aim of the guide was to create a place for both new and veteran modders to go to when they need to understand or review some basics of the character and equipment configuration, and I hope this piece of documentation will help anyone interested in modding these parts of Arma 3 content.

You can find the guide here: https://community.bistudio.com/wiki/Arma_3_Characters_And_Gear_Encoding_Guide.

I created this thread so I can gather your feedback, questions, and suggestions regarding the guide. Should you feel anything is not clear enough, or perhaps altogether amiss, please let me know here. Please don't ask for help with a specific problem here, create a separate thread for such questions, as usual.

May your time in your favourite text editor be merry and your bugs scarce!

  • Like 4

Share this post


Link to post
Share on other sites

That is some splendid intel, thanks good Sir!

Only had a quick glance at it but that should solve a mystery or two, bookmarked immediately. :)

Share this post


Link to post
Share on other sites

Wow, that was a great read! Especially the script based randomization was something I would have probably never looked at otherwise :)

EDIT:

Headgear is usually inherited from the H_HelmetB class

That's obviously a true statement...but why? Pretty much all other equipment has nice 'trees' of abstraction. (i.e. arifle_MX_base_F as a common 'abstract' superclass of all MXs).

Why are Helmets (and vests, iirc) such a 'flat' hierachy? Mods that e.g. want to modify armor/passthrough values would have a much easier time if there was a base class for each 'type/category' of helmet ;)

Edited by ImperialAlex

Share this post


Link to post
Share on other sites

props for the well and indeph guide

quick question, a bit unrelated to the codding part, but related to the characters per say.

for uniforms, i want to have the position of the vest and backpack further up and back. Seems that moving the position of the proxies doesn't do anything. I am well aware that both the uniform and the backpack is skinned to the skeleton.

So the quesiton is: by moving about the 2 overlapping proxies \A3\Characters_F\Proxies\backpack and \A3\Characters_F\Proxies\equipment, should i see any effect in relation to the vest and backpack position, or those proxies are simply there to allow certain character simply to use those features, and there is no relation between their position in the character p3d and their appearance on the characters in game?

Share this post


Link to post
Share on other sites

Not particularly sure if this belongs here. But I've noticed an issue with the config-based randomisation scripts in combination with CBA (RC6). I thought I was going crazy some time ago until I've recently stumbled into the same issue again. Anyway, the guide says to disable randomisation on config level setting the init EHs to empty is sufficient.

So, with the civillian M-900 it would be something like this:

// Air (Police)
class C_Heli_Light_01_civil_F;

class IP_C_Heli_Light_01_civil_FPO: C_Heli_Light_01_civil_F
{
crew = "IP_I_helipilot_FPO";
displayName = "M-900 (BSM Police)";
faction = "IP_BSM";
hiddenSelectionsTextures[] = {"\IP_BSM\air\txt\heli_light_01_ext_wave_coPO.paa"};
vehicleClass = "IP_Air_PO";
side = 2;

class EventHandlers
{
	init = "";
};
};

It does work fine without running anything else. However, when I run CBA as well randomisation will still strike regardless of the empty EH. (Maybe some extended EHs thing?) What's helping in both cases is overwriting the init EH and disabling randomisation via init script:

class EventHandlers
{
init = "(_this select 0) setVariable ['BIS_enableRandomization', false]";
};

Just an observation for fellow creators. And if others can confirm that this is not caused by my own stupidity it might be worth a footnote in the guide. :)

Edited by IndeedPete

Share this post


Link to post
Share on other sites
for uniforms, i want to have the position of the vest and backpack further up and back. Seems that moving the position of the proxies doesn't do anything. I am well aware that both the uniform and the backpack is skinned to the skeleton.

So the quesiton is: by moving about the 2 overlapping proxies \A3\Characters_F\Proxies\backpack and \A3\Characters_F\Proxies\equipment, should i see any effect in relation to the vest and backpack position, or those proxies are simply there to allow certain character simply to use those features, and there is no relation between their position in the character p3d and their appearance on the characters in game?

In general, the proxied model replaces the proxy in the original model, so the position of both the proxy and the proxied model matters, and adjusting either will have an effect. However, this is apparently not the case with characters, so if you want to adjust where, for example, a backpack is placed, you need to adjust the backpack's position in its model.

Share this post


Link to post
Share on other sites

I thought I once saw a reference to a "undefine property" command for configs. I.e. if you inherit a class and want to remove one of the inherited properties. Is that a thing or is my memory failing me?

EDIT: I found examples of the type "delete [inherited subclass]". Does it work on things other than subclasses, too?

Edited by ImperialAlex

Share this post


Link to post
Share on other sites

It works for every classes, but to be effective, because of the way the engine parses the configs, a delete must be called from a different PBO than the one wherein the class to delete is declared for the first time.

Share this post


Link to post
Share on other sites
I thought I once saw a reference to a "undefine property" command for configs. I.e. if you inherit a class and want to remove one of the inherited properties. Is that a thing or is my memory failing me?

EDIT: I found examples of the type "delete [inherited subclass]". Does it work on things other than subclasses, too?

As a little follow-up to Julien's explanation, I'd like to add I was advised not to use a delete, and I'd recommend the same for the sake of clarity and to avoid any possible bugs that could be caused by the specifics of using that function.

Share this post


Link to post
Share on other sites

Great thread!

Thanks for the efforts!

Share this post


Link to post
Share on other sites

Thanks for answering my question...given the success, I'm back with another config question ;)

class UniformInfo {
class SlotsInfo {
	class NVG : UniformSlotInfo {
		slotType = 602;
	};
	class Scuba : UniformSlotInfo {
		slotType = 604;
	};
	class Googles : UniformSlotInfo {
		slotType = 603;
	};
	class Headgear : UniformSlotInfo {
		slotType = 605;
	};
};
};

What does this do? I can sort-of guess what headgear,NVG and goggles do...but what does "scuba" do?

And, slightly unrelated: Is there a way to define a uniform/soldier that cannot equip any vest?

Share this post


Link to post
Share on other sites
What does this do? I can sort-of guess what headgear,NVG and goggles do...but what does "scuba" do?

And, slightly unrelated: Is there a way to define a uniform/soldier that cannot equip any vest?

Scuba does effectively nothing. :) Concerning a uniform unable to equip any vest, I'm not aware of any way how to make it, sorry.

Share this post


Link to post
Share on other sites
Scuba does effectively nothing. :) Concerning a uniform unable to equip any vest, I'm not aware of any way how to make it, sorry.

Thanks again for the answers! Any chance of seeing a "canCarryVest" property in the future (similar to the canCarryBackpack - if that's even still used by the engine)?

In a surprising turn of events I've got more questions ;)

Can you explain the different icons/pictures a bit more? The CfgVehicles config guideline says that "icon" should be a map/editor thing and "picture" should be what you see in the in-game hud/command UI but that doesn't seem to line-up entirely with what I'm experiencing.

I'm also wondering where the icons in the "switch unit" UI come from? Some more details on this would be greatly appreciated :)

Share this post


Link to post
Share on other sites

I vaguely remember that the CSAT uniforms had armor values for body parts in the past? I haven't found anything in the config however.

Do i just remember it wrong, or where did the feature went?

Share this post


Link to post
Share on other sites
Thanks again for the answers! Any chance of seeing a "canCarryVest" property in the future (similar to the canCarryBackpack - if that's even still used by the engine)?

In a surprising turn of events I've got more questions ;)

Can you explain the different icons/pictures a bit more? The CfgVehicles config guideline says that "icon" should be a map/editor thing and "picture" should be what you see in the in-game hud/command UI but that doesn't seem to line-up entirely with what I'm experiencing.

I'm also wondering where the icons in the "switch unit" UI come from? Some more details on this would be greatly appreciated :)

Concerning "canCarryVest", please feel free to make a feature request in the Feedback Tracker, but to be honest, adding this feature seems unlikely.

Icon: A small circle with an arrow you see in the editor, on the map, or in the Team Switch dialog.

Picture: A picture seen in the frame of a soldier of your unit, if you're a commander.

You can find both pictures and icons in \A3\Ui_f\data\Map\VehicleIcons\. I hope this helps. :)

I vaguely remember that the CSAT uniforms had armor values for body parts in the past? I haven't found anything in the config however.

Do i just remember it wrong, or where did the feature went?

Every soldier has the head, body, hands, and legs hitpoints defined (that means with an armor value, as well). However, these properties are defined in a character's config, not in a uniform's one, which might be the reason why you can't find them.

Share this post


Link to post
Share on other sites
Every soldier has the head, body, hands, and legs hitpoints defined (that means with an armor value, as well). However, these properties are defined in a character's config, not in a uniform's one, which might be the reason why you can't find them.

I see. So what happens if the player changes the uniform he is wearing? Does it also change your hitpoints based on the "character config" you are wearing, or will it always stay the initial values and the uniform change is just optical?

Share this post


Link to post
Share on other sites

Simply said, a uniform is "linked" to a soldier class (please notice the uniformClass property within the ItemInfo subclass of uniform classes). When another character equips the uniform, he gets relevant stats of the soldier class to which the uniform is linked.

Share this post


Link to post
Share on other sites

Just a short information regarding the randomization part, the method will change a bit.

Currently, in the dev branch, the init event handler has been changed, it now uses a new function (BIS_fnc_unitHeadgear) instead of the script, which take the following parameters:

/*
   Author: Julien VIDA <@tom_48_97>

   Description:
   This function is used for randomizing headgear and facewear of a character.

   Parameter(s):
   _this select 0: Object - Unit
   _this select 1: Headgear
       Array - Headgear list with individual probability
       Bool - false, change nothing to the headgear
       String - valid Headgear class
   _this select 2: Facewear
       Array - facewear list with individual probability
       Bool - false, change nothing to the facewear
       String - valid facewear class

   Returns:
   Bool - True when done
*/

The event handlers are now:

// FIA
// I_G_Soldier_base_F
class EventHandlers: EventHandlers
{
   init="if (local (_this select 0)) then {[(_this select 0), [], []] call BIS_fnc_unitHeadgear;};";
};
// Civilian
// C_man_1
class EventHandlers: EventHandlers
{
   init="if (local (_this select 0)) then {[(_this select 0), [], nil] call BIS_fnc_unitHeadgear;};";
};

Also, BIS_enableRandomization will only work with spawned objects (via scripts), for the objects placed from the editor, it will be in the mission config file, with disableRandomization. Note that except the way to prevent the randomization, there's a full backward compatibility.

Share this post


Link to post
Share on other sites

If I didn't want to use any custom textures or objects, and just wanted to create a custom unit that a Zeus curator could spawn in multiplayer, could I do that without creating and distributing a PBO? Could I, for example, create the addon folder and define all of these configuration files inside a mission folder, export that to multiplayer (which I guess does create a PBO) and then upload it to the server? Upon connecting, players download the mission, and theoretically, the customized units, right? Or are there certain default paths that the game will look for when referencing units and fail to find because of the directory that the mission file is in?

What I'm trying to do is create CSAT units with RHS weapons and clothes that I can spawn as Zeus in multiplayer games. But I don't want to make everyone download a new mod to accomplish it. I'd like to push it with the mission file.

Share this post


Link to post
Share on other sites

You can script it in but if you want to add new configs for Vehicles, Weapons, Mags or ammo (among others) then it would need to be a mod.

Have a look at this:

https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#CuratorGroupPlaced

You can then assign new gear by script to the groups (and therefore units of the groups) when you plonk them on the map.

Edit:

Or this for the units themselves:

https://community.bistudio.com/wiki/Arma_3:_Event_Handlers#CuratorObjectPlaced

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×