Armory configuration: Difference between revisions
Lou Montana (talk | contribs) m (Text replacement - "\{\{( *)Informative( *)\|" to "{{$1Feature$2|$2Informative$2|") |
Lou Montana (talk | contribs) m (Text replacement - "{{Feature | Informative | " to "{{Feature|informative|") |
||
(2 intermediate revisions by the same user not shown) | |||
Line 4: | Line 4: | ||
Each item in the game can also use a variety of parameters to be set up properly. | Each item in the game can also use a variety of parameters to be set up properly. | ||
{{Feature | | {{Feature|informative|Whenever a code sample shows {{hl|...}}, this means a full config will likely have more content, but this is not shown in these samples because it is not relevant to the Armory.}} | ||
Line 83: | Line 83: | ||
Class ''Library'' and its members are deprecated and while still supported, should no longer be added. | Class ''Library'' and its members are deprecated and while still supported, should no longer be added. | ||
{{Feature | | {{Feature|informative|The Armory relies heavily on an item's config properties, so please take care in defining them properly. | ||
Some properties may seem insignificant and are inherited from a parent class, but will alter the way items are processed in challenges.}} | Some properties may seem insignificant and are inherited from a parent class, but will alter the way items are processed in challenges.}} | ||
Line 272: | Line 272: | ||
Only enabled when explicitly enabled | Only enabled when explicitly enabled | ||
{{Feature | | {{Feature|informative|Each world may define one or more Fitness Tracks. | ||
All properties defined as first element in the Arrays correspond to other properties defined as first element in those Arrays.}} | All properties defined as first element in the Arrays correspond to other properties defined as first element in those Arrays.}} | ||
Line 351: | Line 351: | ||
Only enabled when explicitly enabled | Only enabled when explicitly enabled | ||
{{Feature | | {{Feature|informative|Each world may define one or more Mobility Ranges. | ||
All properties defined as first element in the Arrays correspond to other properties defined as first element in those Arrays.}} | All properties defined as first element in the Arrays correspond to other properties defined as first element in those Arrays.}} | ||
Line 442: | Line 442: | ||
Only enabled when explicitly enabled | Only enabled when explicitly enabled | ||
{{Feature | | {{Feature|informative|Each world may define one or more Kill Houses. | ||
All properties defined as first element in the Arrays correspond to other properties defined as first element in those Arrays.}} | All properties defined as first element in the Arrays correspond to other properties defined as first element in those Arrays.}} | ||
Line 521: | Line 521: | ||
{{GameCategory|arma1| Editing}} | {{GameCategory|arma1|Editing}} |
Latest revision as of 22:41, 16 May 2024
The Armory can have its parameters set in various configs. It is possible to change general settings like challenges, but also to override certain challenge parameters for one specific world. Each item in the game can also use a variety of parameters to be set up properly.
CfgArmory
This is where you configure general settings for the Armory and more specifically challenges. Usually it is only necessary to work in this class when setting up the Armory for a new project or mod.
Challenges
Generally there are two base classes available (Primary and Secondary) which should ideally be used as base class for primary and secondary challenges.
// Main Armory configuration class
class CfgArmory
{
...
// Configure global challenge properties
class Challenges
{
// Your challenge class
class Challenge1
{
id = -1; // Unique ID number
title = ""; // Title which is displayed
type = 0; // 0: primary, 1: secondary
script = ""; // Name of the script without path or extension
tidExclusions[] = {}; // For which Type ID's is this challenge excluded?
configConditions[] = {}; // What config conditions must the item satisfy?
runtimeConditions[] = {}; // What runtime conditions must the item satisfy?
// Should a world explicitly enable this challenge or is it available by default?
explicitEnable = 0;
};
...
};
};
Config conditions
The following conditions to test an item's static config against are available:
- hasWeapon: the item is armed with at least one weapon
- amphibious: the item is amphibious / can swim
- hasTransport: the item can transport passengers
- isNotWoman: the item is not a female
Runtime conditions
The following conditions to test an item's current state in the world against are available:
- flying: the item is currently flying (isFlying in the MP Armory)
- nearWater: the item is currently near water (within 400 meters for TID 0 and 1, within 150 meters for all others)
- nearRoad: the item is currently near any roads (within 300 meters)
- movingFast: the item is currently moving fast (at least 50% of its maximum speed) (isMovingFast in the MP Armory)
- isDriver: the player is the driver of the item he is in (MP Armory only)
- isNight: it is night (MP Armory only)
- notAlone: there is more than one player (MP Armory only)
- notAloneAndOnFoot: there is just one player and is he on foot (MP Armory only)
- vehicleForAll: there ia at least one vehicle at ARMEX which can fit all players at once (MP Armory only)
Type IDs
Type IDs sort items into the major categories:
- 0: Armored (Tracked in the MP Armory)
- 1: Soft (Wheeled in the MP Armory)
- 2: Static
- 3: Helicopters
- 4: Airplanes
- 5: Ships (not currently supported in the MP Armory)
- 6: Rifles
- 7: Machineguns
- 8: Sidearms
- 9: Launchers
- 10: Explosives
- 11: Characters (not currently supported in the MP Armory)
- 12: Animals (not currently supported in the MP Armory)
CfgWeapons / CfgVehicles
Each weapon and vehicle should define at least an Armory text description. To configure this property, it is best to use class Armory within such item's class. Class Library and its members are deprecated and while still supported, should no longer be added.
class CfgVehicles
{
...
class SomeVehicle
{
...
class Armory
{
// The item's text description (one or several paragraphs).
// Equivalent of the deprecated libTextDesc member.
description = "My description ...";
// Specifically disable this item for the Armory.
// Default is 0 and therefore enabled.
// Equivalent of the deprecated libEnabled member.
disabled = 1;
// Override automatic categorization with this Type ID.
// Do not add unless absolutely necessary.
type = 12;
// Optionally set the author's name of this item.
author = "MyMod";
// These hints are randomly shown to players while using this item (Array of String).
// MP Armory only!
hints[] =
{
"My hint!"
};
...
};
};
};
CfgWorlds
The Armory can be configured for any world and this is where the bulk of the configuration takes place.
Random positions
The Armory and several other systems will often search the world for random positions. In order for this to work efficiently, two parameters should be set and fine-tuned in the world's main class.
class CfgWorlds
{
...
class SomeWorld
{
// The X and Y world coordinate for the center of a square in which random positions are searched.
// Usually this square should cover the main (and interesting) part of the world map.
// Designers may find this square by placing a marker with the same dimensions and fine-tuning it.
safePositionAnchor[] = {1, 1};
// The distance in meters from the center of the same square.
safePositionRadius = 5000;
...
};
};
World properties
Not all of the following positions are mandatory to define, but having them will make for better functionality.
class CfgWorlds
{
...
class SomeWorld
{
class Armory
{
// A default position used to try out items.
// Usually such position is random, but in case nothing was found, the default is used.
// If none is defined, the world's centerPosition is used instead.
positionStart[] = {1, 1};
// The same as above, but specifically for water vehicles.
// Obviously this should be inside a body of water (the larger the better).
// If none is defined, positionStart is used.
positionStartWater[] = {1, 1};
// The game requires a player character to be present in the world.
// Try to use a remote position, like a tiny island in the ocean.
// If none is defined, positionStart is used.
positionAdmin[] = {1, 1};
// A list of blacklisted areas in which no positions may be used.
// Typically used for inaccessible mountains, small lakes, etc.
// Each element consists of two XY-coordinates.
// The top-left point and bottom-right point defining a square area.
positionBlacklist[] =
{
{{1, 1}, {2, 2}},
{{3, 3}, {4, 4}}
};
// A list of XY-coordinates used for the Viewer mode.
// If none is defined, positionStart is used.
positionsViewer[] =
{
{1, 1},
{2, 2}
};
// A list of XY-coordinates used for the Viewer mode for water vehicles.
// If none is defined, positionStartWater is used.
positionsViewerWater[] =
{
{1, 1},
{2, 2}
};
...
};
};
};
Challenges
Many challenges require special parameters to be defined to function correctly. Some challenges will simply never be started when they have not be configured for a world and not explicitly enabled (see CfgArmory.Challenges).
All of the following definitions are classes within CfgWorlds.SomeWorld.Challenges.
class CfgWorlds
{
...
class SomeWorld
{
...
class Challenges
{
...
};
};
};
Disabling challenges
A challenge can be disabled explicitly for a certain world. This is only necessary for challenges which do not require explicit enabling.
class SomeChallenge
{
disabled = 1;
...
};
CheckpointRace
Always enabled unless disabled
class CheckpointRace
{
// Defines a fixed race route as back-up to the dynamic route system.
// In case no dynamic route can be found, this one is used.
backUpRoute[] =
{
{1, 1}, // Waypoint 1
{2, 2} // Waypoint 2
};
};
FiringRange
Only enabled when explicitly enabled
class FiringRange
{
// One or more XY-coordinates for a Firing Range
// The Firing Range needs large and long open areas, like airstrips.
positionsStart[] = {{1, 1}};
directionsStart[] = {90};
// Corresponding azimuths for the above coordinates in degrees
// The first azimuth corresponds to the first coordinate set.
positionsStartWater[] = {{2, 2}}; // As above, but for water vehicles
directionsStartWater[] = {180}; // Idem
};
FitnessTrack
Only enabled when explicitly enabled
class FitnessTrack
{
positionStart[] = {{1, 1}}; // Player spawning positions
directionStart[] = {90}; // Player spawning directions
// These scripts are called as function and should return an Array with a [[Dynamic_Object_Compositions|DynO]] object composition.
// These are the objects, such as climbing obstacles, flags, signs, etc.
objectSets[] = {"myDynoScript.sqf"};
positionAnchor[] = {{1, 1}}; // XY-coordinate sets where the DynO sets are spawned (using azimuth 0)
// The lists of gameplay challenges of the Fitness Track
// Mainly defines what hints are shown, but does not place the actual obstacle object!
obstacleSets[] =
{
{
/*
Array format:
0 - challenge XY-coordinates - Array
1 - azimuth in degrees - Scalar
2 - completion trigger area width in meters - Scalar
3 - completion trigger area height in meters - Scalar
4 - challenge type ID - Scalar
0: Start
1: Zig-zag maze
2: Duckboard
3: Hole
4: Barbed wire
5: Climbing
6: Ladder
7: Concrete ramp
8: Buoy
9: Wooden ramp
10: Finish
11: Waypoint
12: Step over
5 - hint to override default - String
*/
{{1, 1}, 90, 3, 2, 0, ""}, // First challenge
{{2, 2}, 180, 4, 1.5, 10, "Hello world!"} // Second challenge
}
};
// XY-coordinates for live-firing machineguns used at the crawling obstacle
positionMachineguns[] =
{
{{1, 1}, {2, 2}}
};
// Azimuths in degrees for the above machineguns
directionMachineguns[] =
{
{90, 180}
};
// The following properties are exactly as above, but for the animal Fitness Track.
positionStartAnimal[] = {{1, 1}};
directionStartAnimal[] = {90};
objectSetsAnimal[] = {"myAnimalDynoScript.sqf"};
positionAnchorAnimal[] = {{1, 1}};
obstacleSetsAnimal[] =
{
{
{...},
{...}
}
};
...
};
MobilityRange
Only enabled when explicitly enabled
class MobilityRange
{
positionStart[] = {{1, 1}}; // Player spawning positions
directionStart[] = {90}; // Player spawning directions
// Like above, but for amphibious vehicles (optional)
positionStartAmphibious[] = {{2, 2}};
directionStartAmphibious[] = {180};
// Like above, but for water vehicles
positionStartWater[] = {{3, 3}};
directionStartWater[] = {270};
// These scripts are called as function and should return an Array with a [[Dynamic_Object_Compositions|DynO]] object composition.
// These are the objects, such as ramps, flags, signs, etc.
objectSets[] = {"myDynoScript.sqf"};
positionAnchor = {{1, 1}}; // XY-coordinate sets where the DynO sets are spawned (using azimuth 0)
// Like above, but for water vehicles
objectSetsWater[] = {"myWaterDynoScript.sqf"};
positionAnchorWater[] = {{1, 1}};
// The lists of gameplay challenges of the Mobility Range
// Mainly defines what hints are shown, but does not place the actual obstacle object!
obstacleSets[] =
{
{
/*
Array format:
0 - challenge XY-coordinates - Array
1 - azimuth in degrees - Scalar
2 - completion trigger area width in meters - Scalar
3 - completion trigger area height in meters - Scalar
4 - challenge type ID - Scalar
0: Start
1: Small humps
2: Small alternating humps
3: Ramp
4: Checkpoint
5: Large humps
6: Large alternating humps
7: Waypoint
8: Mount
9: Finish
10: Chicane
11: Slalom
5 - hint to override default - String
*/
{{1, 1}, 90, 3, 2, 0, ""}, // First challenge
{{2, 2}, 180, 4, 1.5, 9, "Hello world!"} // Second challenge
}
};
// Like above, but for water vehicles
obstacleSetsWater[] =
{
{
{...},
{...}
}
};
// It's possible to have flaming, rolling barrels be triggered while clearing the range.
positionRollingBarrels[] = {{1, 1}}; // XY-coordinate sets where the barrels start
directionRollingBarrels[] = {90}; // Azimuths in degrees used to push the barrels towards
positionTriggerRollingBarrels[] = {{2, 2}}; // XY-coordinate sets for the triggers for the barrels
radiusTriggerRollingBarrels[] = {10}; // Radii for the above triggers
// You may enable oncoming traffic on the range, which create a moving obstacle.
positionOncomingTraffic[] = {{1, 1}}; // XY-coordinate sets where the vehicles are spawned
directionOncomingTraffic[] = {90}; // Azimuths in degrees of the spawned vehicles
// Sets of waypoints the vehicles will drive along
waypointsOncomingTraffic[] =
{
{
{1, 1},
{2, 2}
}
};
positionTriggerOncomingTraffic[] = {{2, 2}}; // XY-coordinate sets for the triggers for the traffic
radiusTriggerOncomingTraffic[] = {10}; // Radii for the above triggers
};
KillHouse
Only enabled when explicitly enabled
class KillHouse
{
// Kill House properties for infantry with man-portable weapons
class Small
{
positionStart[] = {{1, 1}}; // Player spawn XY-coordinate sets
directionStart[] = {90}; // Player spawn azimuths in degrees
positionEnd[] = {{2, 2}}; // Final waypoint XY-coordinate sets
// These scripts are called as function and should return an Array with a [[Dynamic_Object_Compositions|DynO]] object composition.
// These are the extra objects, such as wrecks, barrels, crates, etc.
objectSet[] = {"myDynoScript.sqf"};
positionAnchor[] = {{1, 1}}; // XY-coordinate sets where the DynO sets are spawned (using azimuth 0)
// Waypoint sets through the Kill House as XY-coordinate sets
waypoints[] =
{
{
{1, 1},
{2, 2}
}
};
// Sets of targets placed throughout the Kill House
class Targets
{
class TargetSet1
{
class Target1
{
// Target type:
// 0: static
// 1: moving
type = 1;
position[] = {1, 1}; // Target position
direction = 90; // Target azimuth in degrees
upTime = 4; // How long does the target remain popped up?
positionMove[] = {2, 2}; // In case of a moving target: where to move to?
moveTime = 8; // In case of a moving target: how long will it take to move in seconds?
// Target side:
// 0: enemy to the player
// 1: civilian
// 2: a 50% chance for one or the other
side = 0;
// Target size:
// 0: small (infantry)
// 1: large (vehicle)
size = 0;
// Target spawn condition:
// 0: always spawn
// 1: a 50% chance to spawn
spawn = 0;
positionTrigger[] = {3, 3}; // XY-coordinate of the trigger to activate the target
radiusTrigger = 10; // Radius of the above trigger
};
...
};
};
};
// Like above, but for vehicles
class Large
{
...
};
// Like above, but for water vehicles
class Water
{
...
};
};