ArmA 2 Custom Keypoints and CfgLocationTypes

ArmA 2 Forum, ArmA 2 Home, ArmA 2 Config, ArmA 2 File Formats, ArmA 2 Missions, ArmA 2 3D Modeling, ArmA 2 Scripting, ArmA 2 Terrain, ArmA 2 Texturing, ArmA 2 Tools

ArmA 2 Custom Keypoints and CfgLocationTypes Tutorial by Bushlurker.

Here's a quick guide on how to define & implement them on your terrain.

Main types of keypoints… broadly speaking, some are “Names”, some are “Symbols” (or a combination of both) and some are completely invisible, but serve some “Strategic” purpose - like “CityCenter” for example.

Let's make a simple custom symbol one which can be named or not as we like.

The first thing we'll need is a symbol to use… this one from Google Chat will do nicely.

Now we need to add a suitable keypoint type name to “keypoints.dat” - here's mine.

BorderCrossing
VegetationBroadleaf
VegetationFir
VegetationPalm
VegetationVineyard
NameMarine
NameCityCapital
NameCity
NameVillage
NameLocal
RockArea
ViewPoint
FlatArea
FlatAreaCity
StrongpointArea
FlatAreaCitySmall
CityCenter
Hill
Name
Mount
Airport
Strategic
SteamingPile

As you can see, I've named my map symbol suitably in my kptypes.dat file and dropped it back in my Visitor 3 install directory, ready to use…

Into Visitor 3, load a demo terrain and we're ready to place those new Steaming Pile indicators.

Here you can see I've placed a normal keypoint, and in its Properties Window I've defined a classname and chosen the Keypoint Type “SteamingPile” from the list.

If you really want to name your Steaming Piles individually and, lets face it, who doesn't… then you could type a “Display Name” at this stage too.

* At this point it's worth remembering how these keypoint definitions work in Visitor.

As you define these keypoints, they're stored in the .pew file - it's only when you're at the viewing-in-buldozer while saving the .wrp stage, that they're written to the “yourterrain.hpp” file, ready to be #included in your main config.

So the next stage is to open buldozer, view the terrain and save a .wrp file… At that stage you can have a peek in your “myterrain.hpp” file and you'll see the new keypoint definition… mine looks like this…

class SteamingPile_01
{
	name = "";
	position[] = { 3043.26, 2006.69 };
	type = "SteamingPile";
	radiusA = 100;
	radiusB = 100;
};

If you'd defined a name for your Pile then it would appear in the name = “”; section.

Now we need to tell the engine precisely what a SteamingPile is.

The default Location Types are defined in a config section called, unsurprisingly, “cfgLocationTypes”, so the next thing we need to do is add our definition to that.

We'll sneak a little “patch” section into our main terrain config… Here's the opening section of the demo terrain I used.

class CfgPatches
{
	class AfghanValley
	{
		units[] = {"AfghanValley"};
		weapons[] = {};
		requiredVersion = 1.0;
		requiredAddons[] = {"Takistan"};
	};
};
 
class CfgLocationTypes
{
	class SteamingPile
	{
		name = "";
		drawStyle = "icon";
		texture = "Bush\AfghanValley\data\icons\steaming_pile_ca.paa";
		color[] = {};  //<--- uses icon colours or define RGB values in usual 0 > 1 format
		size = 32;
		shadow = 0;
		font = "Zeppelin33";   //<--- or try Zeppelin33italic
		textSize = 0.2;
	};
};
 
class CfgWorlds
{
	class CAWorld;
	class Takistan: CAWorld
	...etc, etc, etc ......

Right here at the beginning of the main terrain config is fine - or, if you were planning on doing a lot of these, you could define them all externally in a “mykeypoints.hpp” and just #include it at this location to keep your main terrain config less cluttered.

Finally, as you can see from the definition above, I'll need to drop my icon file into a directory called “icons” in the “Data” directory of my terrain… that way the icon will be included at the binarizing stage and be available in-game to be used on the map.

Try to keep icon sizes small and square, preferably ^2 and as you can see from the “_ca” suffix, alpha channels work nicely.

Have fun!