PEW File Format: Difference between revisions

From Bohemia Interactive Community
Jump to navigation Jump to search
(→‎ObjectClassEnum: Changed name & 5th Type name)
(Altered 'Selections', Removed 'AltNamedZones')
Line 64: Line 64:
     ulong                    nRoadBlocks;
     ulong                    nRoadBlocks;
     RoadBlock                RoadBlocks[nRoadBlocks];
     RoadBlock                RoadBlocks[nRoadBlocks];
    ulong                    nAltNamedZones;
    AltNamedZone            AltNamedZones[nAltNamedZones];//never seen (so far) on pose59
   
   
     ulong                    nKeyPoints;
     ulong                    nKeyPoints;
Line 561: Line 558:
         ShortBool  ok; // 0 or 1
         ShortBool  ok; // 0 or 1
  }
  }
===(Alt)NamedZone===
NamedZone
{
  ShortBool IsPresent;
  if IsPresent
  {
  ShortBool Movable;        // almost Always0;
  BisString Name1;          //"Les_new"
  ulong    AreaColor,OutlineColor;
  ulong    DisplayStyle;
  ulong    nPoints;
  PointsRectangle
  {
      float TopLeft.xy;
      float BottomRight.xy;
  }[nPoints/4];
            /* Typical Data
            **00 00 61 45  00 78 1B 46  00 20 64 45  00 20 19 46
            **00 20 64 45  00 78 1B 46  00 40 67 45  00 58 18 46
            **00 40 67 45  00 78 1B 46  00 60 6A 45  00 58 18 46
            **00 60 6A 45  00 78 1B 46  00 80 6D 45  00 90 17 46
            **00 80 6D 45  00 B0 1A 46  00 A0 70 45  00 C8 16 46
            **00 A0 70 45  00 E8 19 46  00 C0 73 45  00 00 16 46
            */
  ulong    ID;            // 0,1,2,3,4....
  if POSEW60
  {
    LongBool  Visible; // almost always true
  }
  else
  {
    BisString Name2;          //Les_new Name2==Name1
  }
  }
};
altnamed zone and named zone seem to be mutually exclusive


===KeyPoint===
===KeyPoint===
Line 656: Line 614:
  Selection
  Selection
  {
  {
   ushort       strlen;
   ushort               strlen;
   char[]       SelectionName[strlen];  // NOT null terminated
   char[]               SelectionName[strlen];  // NOT null terminated
   ulong       nSubSelections;
   ulong               nObjects;
   SubSelection SubSelections[nSubSelections]
   SelectionObject      SelectionObjects[nObjects]
  }
  }
====SubSelection====
====SelectionObject====
  SubSelection
  SelectionObject
  {
  {
   ulong ObjectId;
   ulong ObjectInstanceID;
  byte  Type;
   byte  Unknown[8];
   byte  Unknown[7];
}
}



Revision as of 23:32, 2 December 2011

Template:unsupported-doc

Introduction

PEW files are Visitor's project files. Visitor is BI's tool for creating Islands.

Visitor is a GUI tool interface that interacts with Bulldozer, an in-built 'world' viewer inside any Armed Assault engine.

The contents of the PEW project file are not directly related to the ultimate output, a WRP file. However, that data contains all similar elements, such as road networks, elevations, cell matrices, models (P3D files) and textures (RVMAT files).

Exporting a PEW file into WRP format involves the use of Bulldozer, since it is Bulldozer that decides how it wants that data presented rather than anything Visitor might like to decide. It is Bulldozer that determines the format and version of the resulting WRP file (in 8WVR format), so the WRP version is based on the version of the Real Virtuality engine used to create it. This is not the same thing as saying the VERSION of the engine. It is the engine, that decides, the VERSION of wrp it needs to generate.

Furthermore, the resulting Wrp file is (for want of a better expression) 'unbinarised' 8WVR format. It is nothing more or less, than a (modified) copy of texture, elevations and models. Period. Roadnetworks and other ancilliary data is only processed into a 'binarised' OPRW format wrp, using Bi's binarizer tool.

Note that it is possible to generate 8WVR format without involving bulldozer (or arma) using [party tools].


While there have been several PEW versions, the ones listed here are:

  • POSEW59 and
  • POSEW60

There are only a few subtle differences to their makeup.

Legend

See Generic FileFormat Data Types

File Format

  • This file format is principally used with Armed Assault v1.09 and later, with the ArmA Tools Suite final release (v1.14).
 POSEW59
 POSEW60
 {
   PoseHeader               Header;
   ulong                    nOFPTextures           // none in Arma;
   OFPTexture               OFPTextures[nOFPTextures];
   ulong                    nObjectTemplates;
   ObjectTemplate           ObjectTemplates[nObjectTemplates];
   shortBool                NoOfpTerrains;
   if  (!NoOfpTerrains)
   {
   ulong                    nOFPTerrains;         //  none in Arma;
   OFPTerrain               OFPTerrains[nOFPTerrains];
   }
   shortBool                NoOFPForests;         //  none in Arma;
   if  (!NoOFPForests)
   {
   ulong                    nOFPForests;          
   OFPForest                OFPForests[nOFPForests];
   }
   RoadNets                 RoadNets[...];
   Elevation                Elevation[...];
   ulong                    NoOfObjects;
   Object                   Objects[NoOfObjects];

   ulong                    NoOfLayers;
   String                   CurrentLayerName;           //"Base"
   Layer                    Layers[NoOfLayers] ;

   ulong                    nNamedZones;// almost never present on pose60
   NamedZone                NamedZones[nNamedZones];
 
   ulong                    nRoadBlocks;
   RoadBlock                RoadBlocks[nRoadBlocks];

   ulong                    nKeyPoints;
   KeyPoint                 KeyPoints[nKeyPoints];    
   ulong                    NoOfBackgrounds;
   Background               Backgrounds[NoOfBackgrounds] ;// not checked for 59
   ulong                    TotalSizeOfSelections; // from here, to end of file
   ulong                    nSelections;
   Selection                Selections[nSelections];
 }


PoseHeader

Header
{
 char     Signature[7];        // "POSEW59" or "POSEW60" note: NOT null terminated
 ulong    Length;              // of PEW file;
 ulong    UnknownLong;         // typically 0
 String   IslandRvMatPath;     //"SomePboPrefix\SomeIsland\data\0" see below
 String   IslandP3dPath;       //"" (objects)
 float	  TerrainGridSize;     //10.0 metres 
 float	  SegmentSize;         //400.0 (==SegmentSize - SegmentOverlap)
 String   IslandClassname;     //""
};

Texture And Terrain Sizes

  • Pew files deal with terrain. There is no 'texture' size as such. Therefore the gridsize specified in the header pertains to terrain cells.
  • In contrast, the gridsize specified in a WRP pertains to TEXTURE(rvmat) cells.


"Texture", 'Material','Surface', 'Layer' are synonomous to rvmat files. They are the island's unique surface as generated by importing from a sat mask image. There can be, multipler layers of rvmat files.

Terrain, are the cell grids of the map and as often as not specified at a different (larger) dimension.

Unlike Wrp files, Textures and Terrain sizes are not declared in a pew directly. At least, not, in the header.

The Terrain (Map) Size is declared in the elevations structure.

TextureSizeS (plural) are derived, not declared, in each surface 'Layer' of pew. Since, ultimately, each layer must 'fit' onto the map. Each layer contains a shift value of how much SMALLER the surface is, relative to the map. For OFP, and OFP converted-to-arma, islands, this is 0 (there is no difference betweem a 256x256 cell Terrain and a 256x256 cell Texture.

For Arma,it is *generally* x 4 (shift value=2).

  • TerrainGridSize

A wrp file's GridSize is the OPPOSITE of a PewFile's GridSize.

In a wrp, it defines the size (in meters) of each cell of the TEXTURE (rvmats).

In a pew, there is no direct TEXTURE dimension since there can be multiple layers, each with different (derived) dimensions.

So this value, in a pew, is the TERRAIN dimension.


  • IslandRvMatPath

RVMAT file references in the Layers structure are listed as relative addresses to the IslandRvMatPath. This is in contradistinction to the general Bis way-of-doing-things where all references are hard references.

Traditionally, an RVMAT(Island) data path is declared as "Layers\some.rvmat". It is expected, therefore, that you do indeed have a "P:\SomePboPrefix\SomeIsland\...\Layers" folder. Put another way, the prefix of the PBO must be "SomePboPrefix\SomeIsland\...".

The SubFolder 'Layers' is hard wired by Visitor. It is generated automatically when importing a satmask image. Thus, all relative reverences to the rvmats that Visitor produces, are prefaced by 'Layers\'.

Using 3rd party tools, you can, should you wish to, alter this prefixing and location of the rvmats to anywhere at all, including no path at all (Visitor, the engine, and the binarizer don't actually care). The purpose in doing so is somewhat moot, since, unlike p3d's, rvmat's for an island are unique to an island. The chances or need of referencing them by something else is zilch. Hence, unlike p3d's, they may just as well stay in the wrp's pbo. Point being, they don't have to.

  • IslandObjectPath uses the same mechanics as above. However, since P3D files are almost inevitable declared from multiple locations (any PBO, including the base 'CA' PBO included in the game) its use is moot. Be that as it may, the mechanism exists and works, identically to IslandRvMatPath.


PEW files are not known to contain anything in IslandObjectPath or IslandClassname.

OFPTexture

OFPTexture
{
 ulong	    TextureID;
 String    TextureFileName;	// "snih3.paa"
 String    TextureName;	// "snih3"
 String    RvmatName;		// "snih3.rvmat"
 byte      UnknownBytes[14];	// (typically 0)
 RGBAColor Colour;
}

ObjectTemplate

 ObjectTemplate
 {
     String       ModelFilename; //"SomePrefixRoot\data\jablon.p3d\0"
     String       ModelName;     //"jablon"
     ulong        ObjectType;    // 0..5 (so far...)
                                 // 0 Undefined - This type should never be encountered.
                                 // 1 Natural
                                 // 2 Artificial
                                 // 3 Road (RoadFlag will be true)
                                 // 4 Forest
                                 // 5 Road2 (RoadFlag will be false)
     RGBAColor     OutlineColour; 
     RGBAColor     ObjectColour;  
     double	   GeometryBounds[2];            // 50.0
     ulong	   ModelID;                      // uniqueID, used by objects to lookup this model(p3d)
     XYZTriplet    GeometryAutocenterPos;
     double	   ResolutionBounds[2];          // 50.0
     XYZTriplet    ResolutionAutoCenterPos;
     shortBool	   Generally0x01;   
     shortBool	   RandomScaleFlag;
     double	   RandomScaleMinMax[2];         // 50.0
     shortBool	   RandomRotateFlag;
     double	   RandomRotateMinMax[2];        // 20.0
     shortBool	   RandomOrientationFlag;     
     double	   RanmdomOrientationMinMax[2];  // 180.0
     shortBool	   RoadFlag;
     if (RoadFlag) 
     {
           TransformMatrix RoadNamedSelections; // (LB, PB, LE, PE)
           TransformMatrix XRoadNamedSelections;// (LD, LH, PD, PH)
     };
     ulong        nNamedVectors;                // Usually 0 (zero)
     NamedVector  NamedVectors[nNamedVectors];
     ulong        MarkerType;	                // Rectangular = 0, Elliptical = 1 
 }

As opposed to layers (material RVMAT surfaces), 'objects' are instances of models placed onto the map. Irrespective of the number of objects there is only one reference to the model used, which is then referenced as often as needed.

ModelFilename, ModelName, and ModelID are unique unduplicated entries.

The ModelID is not zero based; its value is incremental according to the number of times any model has been added while editing, even if previous models have been deleted; model IDs do not rearrange themselves and deleted IDs are not recycled for re-use. The ObjectID illustrated on maps is, in contrast, the unique InstanceID of each object in the objects structure below. 'Road2' type cannot be defined with Visitor3 Personal Edition. It's a type specific to VBS2 V3 edition.

NamedVector

 NamedVector
 {
    String     Name;       //"pohrada"
    LongBool   Unknown;
    ulong      nTriplets; // generally 2 sometimes 1
    XYZTriplet StartEndPos[nTriplets];
 }

As of v60 a rarely used sub structure with ObjTemplates.

OFPTerrain

OFPTerrain
{
 String  TerrainName;
 byte    UnknownBytes[11];
 ulong	  nSurfaces;
 OFPSurface OFPSurfaces[nSurfaces];
}

OFPSurface

OFPSurface
{
 String SurfaceName;
 float	 Surfacefloat[4];
 byte   UnknownBytes[16];
}

OFPForest

OFPForest
{
 String    ForestName;
 RGBAColor OutlineColour;
 RGBAColor ObjectColour;
 ulong	    SquareFillModelID;
 ulong	    SquareModelID;
 ulong	    TriangleModelID;
 ulong	    Unknown1;	// (typically 0)
 ulong	    Unknown2;	// (typically 0)
}

RoadNet

   shortBool NoRoads;
   if  (!NoRoads)
   {
     ulong    nTypes;
     RoadType RoadTypes[nTypes];
     ulong    nXRoads;
     XRoad    XRoads[nXRoads];
   }

RoadType

 RoadType
 {
   String       FamilyName;        // "cesta","silnice",etc
   RGBA         KeyPartsColour;    
   RGBA         NormalPartsColour; 
   shortBool    FilledLine;        // 0 or 1
   double       MaxAngle;          // 25.0 degrees 
   double       MaxBankAngle;      // 5.0 degrees
   ulong        nStraights;
   RoadList     Straights[nStraights];
   ulong        nCurves;
   RoadList     Curves[nCurves];
   ulong        nSpecials;
   RoadList     Specials[nSpecials];
   ulong        nTerminators;
   RoadList     Terminators[nTerminators];
   }
 }
RoadList
 RoadList     
 {
      String      ModelName;      // "cesta25"
      ulong       ObjectID;       // in the model list
      ushort      MeterType;      // 0,1,2,3 not present for Terminators
      shortBool   CanChangeAngle; // not present for Terminators or Curves
 }
MeterType Values
Type Straights Curves
0 6 m 25 m
1 12 m 50 m
2 25 m 75 m
3 100 m

Broadly speaking, there are a few basic road types:

  • asfalt: Bitumen
  • silnice: Paved
  • cesta: Dirt

Each RoadType describes the general characteristics of the corresponding road, and can have multiple curved, straight, special, and termination P3D models associated with it.

Generally speaking, there are:

  • 3 'straight' models, approximately 6, 12, and 25 meters long respectively.
  • 4 'curved' models, approximately 25, 50, 75, and 100 meters long.
  • 1 'termination' type.

The termination type is a road like any other but tends to be a fixed 6 meter fade out of the general road texture.

XRoad

XRoad
{
 String    Name;	      //kr_asfaltka_asfaltka_t.
 ushort    Shape;            //1 or 3
 RGBA      color;	      //FF FF FF FF 
 shortBool CanChangeBankAngle;
 ulong     ObjectID;
 String    Intersections[4]; //"asfaltka","silnice","cesta",Type=3 "silnice" else ""
}

Although "CrossRoads" could conceivably have any number of intersections, only two types are handled.

  • Type 1: A T_Junction (3 intersections)
  • Type 3: A genuine crossroad (4 way intersection)

For T_Junctions, there is obviously no 4th intersection and this is null filled.

Without taking too literal an interpretation, there are some major types of road.

  • asfaltka:bitumen (sealed)
  • silnice: Paved
  • cesta: Dirt

Thus the names of each intersection reflect the road type of that intersection, sometimes resulting in (up to) four identical names.

The overall name of the crossroad itself, tries to reflect the nature of it's makeup thus kr_asfaltka_asfaltka_t: an bitumen T_Junction kr_silince_x_cesta: a crossroad of paved and dirt roads.

Elevation

Elevation
{
   XYPair   TerrainSize; // 256 x 256 eg
   float    Heights[TerrainSize];
   float    BlueEdgeTerrainHeights[NoOfBlueFloats]  ; //Always zero values 
   // NoOfBlueFloats = (TerrainSize_Y * TerrainSize_X)/16;
   ulong    Always0;
}

Object

Object { ShortBool IsPresent; if (IsPresent) { ShortBool Moveable; // always 0 ulong ObjectID; // See Below float TransformColumn[3][4]; // See Generic FileFormat Data Types]] in COLUMN format double ObjectRelativeSize; // decimal percentage String InstanceName; // "" mostly. "minimalStrelPos" eg for artifical objects float RelativeSurfaceElevation; RGBA OutlineColour; RGBA ObjectColour; ulong ModelID; // See below }; };

  • TransformColumn

The XYZ positional component is the absolute position. If a relative elevation has been specified in the pew, that value has been added to the component at this storage time.

  • ObjectID

Every object entry has a zero-based, linear sequential ObjectID. ObjectID is unique for every object and is the value displayed on a map for all models placed on it (including roads, grass, etc.). Thus, every tree and every road section has its own unique ObjectID.

The first Object in the PEW file is ObjectID==0, the next 1,2,3,4 etc.

If an object has been deleted, that entry retains its unique object ID, even though the ObjectID is no longer stored. If an object is not present (IsPresent is false), the ObjectID is calculated based on the last used object ID. The next real object (IsPresent is true) will always be the Nth ObjectID because the number always increases by the number of object entries, present or not. The reason for this is to maintain consistent IDs for objects so that missions can rely on a bush having the same NearestObject ID as it always had, irrespective of map upgrades.

When you add a new object, it is thus always is added to end of table with a new object ID. When you remove an object, the object ID remains reserved even though the object no longer exists.

This mechanism works well within the ArmA engine, but fails to help at all for conversion of OFP islands unless you methodically and manually enter all of the entries in the correct order. With upwards of 100,000 entries per island, this is practically impossible.

  • ModelID

Note that this is the unique ID of the ModelID in the object Template. It is not an index into the template structures. Unusual, and slow as a result.

Layer

   Layer
   {
       ulong           SizeType;         //0..2 //see below
       String          Name;             //"Base"
       shortBool       DefaultIndicator; // 0 ... 1
       if (DefaultIndicator == 0)
       {
           ulong  SurfaceTable[TableSize.x*y];
           ulong  TextureTable[TableSize.x*y];
           byte   UnknownTable[(TableSize.x*y/4)];
           ushort UnknownShort;
       };
       if (DefaultIndicator == 1)
       {
           ulong           NoOfTerrainMaterials;
           TerrainMaterial[NoOfTerrainMaterials]
           {
               ulong  BitFlags;     // 1 = label, 0x40 = rvmatfile,,,,
               String MaterialName; // "---sea---","Layers\P_000-000_L00.rvmat"
               ulong  TypeID;       // 0..3
           };
           ulong RvmatIndexTable[TableSize.x*y];
       };
   };

TableSize = Elevations.TerrainSize>> SizeType;

RvmatIndexTable

The texture table contains 1-based indexes into the rvmats. This is a traditional bis way-of-doing-things in that the 0th 'rvmat' is, by default 'sea' texture and does not have an associated file, nor, is it referenced in this table.

The organisation of 'cells' differs from it's equivalent wrp. They are the reversed, mirror image of each other. Thus for a pew file with a 'poetic' 4x4 island:

  PEW    
 D 9 5 1
 E A 6 2
 F B 7 3
10 C 8 4

vs WRP

D E F 10
9 A B C
5 6 7 8
1 2 3 4

Unlike a wrp there is no Texture Size (256x256) eg. It is a derived value from the Elevations size (ergo the TerrainSize) (1024x1024 eg) The size of this table, the 'Texture Size' is defined as a ratio via LayerSizeType.

  • 0 same
  • 1 half
  • 2 quarter

Rvmat Conventions

Naming of rvmat files (generally) follows a simple convention largely because the files are auto_generated when importing the satmask. The resolved Texture size (dependent on the pixels and resoltion wanted) are divided into x and y numbered co-ordinates thus

p_(x)00..(x)nn_(y)00..nn_L00..zz

where:

(x) and (y) are the cellgrid position (and not part of the label)

Lzz is the layer

For a mythical single layer island with an 8x8 TEXTURE , files names will range from

p_00_00_L00 to p_07_07_L00



PxxPyy


RoadBlock

RoadBlock
{
 ShortBool IsPresent; 
 if IsPresent
 {
 ShortBool Always1; 
 ushort    Unknown;          // Typically 0
 ulong     RoadBlock Number; // increments with each placed keypart
 float     X-Coord;
 float     Y-Coord;
 float     Elevation;
 float     Angle;
 ushort    Unknown;          // Typically 1
 float     X-Coord;          // Copy of previous X-Coord
 float     Y-Coord;          // Copy of previous Y-Coord
 float     Elevation;        // Copy of previous Elevation
 float     Angle;            // Copy of previous Angle
 ulong     Unknown;          // Involves object counts, somehow
 ulong     Type;             // 0,1,2,3 for keypart of Crossroad, Straight, Special, Terminator
 ushort    Type;             // 0,1,2,3 (Unknown)
 String    RoadFamilyName;   //"hlavni silnice"
 String    RoadModelName;    //"kr_silnice_cesta_t"
 RGBA      color;            
 ShortBool Always1; 
 ulong     Count; 
 FamilyList FamilyLists[Count];
 float     Unknown[27];
           /* This is geometrical data for the keypart. Each keypart has its
           **   own values filling out this zone, depending on its shape. Two
           **   identical keyparts will have identical data in this section.
           ** Example data:
           ** FA D4 30 BF  94 58 08 3D  00 00 C8 C0  00 00 60 C0
           ** 00 00 00 00  00 00 48 C1  00 00 60 40  00 00 00 00
           ** 00 00 48 C1  00 00 60 C0  00 00 00 00  00 00 00 00
           ** 00 00 60 40  00 00 00 00  00 00 00 00  00 00 C8 C0
           ** 00 00 00 00  00 00 30 C0  00 00 C8 C0  00 00 00 00
           ** 00 00 1C C1  04 01 00 00  00 00 00 00  00 00 00 00
           ** 09 00 00 00  0B 80 00 00  04 00 00 00
           */
 ulong     Count;    
 ModelList ModelLists[Count];
 }
}
Type Description
0 Road Ending with FamilyName and its ModelName_konec
1 TJunction ModelName Only
2 Road similar to type 0
3 Xroad with ModelName Only

FamilyList

FamilyList
{
  ulong  Unknown[4];// Typically 00 00 C8 C0 00 00 C8 C0 00 00 00 00 0E 01 00 00
  String Name;     // "silnice hlavni silnic\0"
}

This struct is principally used for XRoads and T_Junctions. It typically lists the order of all RoadFamilyName values required.

ModelList

ModelList
{
 ulong      Count;           //for example, 15
 BlockModel BlockModel[Count];
 String     FamilyName;      //"silnice hlavni silnic\0"
 ulong      Unknown[4];      //Typically 00 00 C8 C0 00 00 C8 C0 00 00 00 00 0E 01 00 00
 RGBA       color[2];         
 ShortBool  Always01;        //01
 ulong      buf2[4];         // Typically 00 00 00 00 00 00 39 40 00 00 00 00 00 00 24 40
}
BlockModel
   BlockModel 
   {
       ulong	   ModelFlag;   // 0x000001 ... 0x00010001
       XYZTriplet Position;      // Model coordinates
       float	   ModelDirection;
       ulong	   ObjectID;
       ushort     Type;               //0,1,2,3
       String     ModelName;          //"silnice10 100\0"
       ulong      unknown[25];
          /*typical data
          **00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
          **C4 76 C2 3F 0E EB 8A C1 00 00 00 00 BE 00 00 00 
          **CC ED 26 BE CA 0F 12 40 56 30 28 3F 00 00 00 00 
          **18 CA 04 C1 48 8B 3D C0 00 00 00 00 2D 3D 91 C1 
          **06 01 C0 40 00 00 00 00 EE 98 84 C1 99 99 91 C0 
          **00 00 00 00 64 4A 5F 35 99 99 91 40 00 00 00 00 
          **64 4A 5F B5 01 00 
          */
       ShortBool  ok; // 0 or 1
}

KeyPoint

KeyPoint
{
 ShortBool  IsPresent; 
 if (IsPresent)
 {
  ShortBool  Always0; 
  String    ClassName;  //"Noe_Lany"
  RGBA      AreaColor,OutlineColor;
  ulong     DisplayStyle; //0 solid
                          //1..6 hatch-horz,vert,cross,skew right,skew left,skewcross
                          //7 standard
  ShortBool Visible; 
  float     Offset[2];  // map relative
  float     Size[2];    // 250 x 250.0 eg (width and height)
  ulong     ID;         // 0,1,2,3,4,5,6....
  BisString TownName;   //"Lipany", "Hill"
  BisString LocaleType; //"NameCity" NameCityCapital, NameVillage, NameLocal, VegetationBroadLeaf,Hill,Marine,ViewPoint
  BisString ClassText;  // "canOcclude=1; BumbleButt='FlowControl2"; ++=)#4555Semi"
 }
}

There is always a classname associated with this Keypoint,

  • Forest_Owls
  • Abel_LaTrinite
  • MyPinkElephant

and in most cases a text name that is 'seen' on the map

"La Refuge Des Chassuers"

Viewpoint and Marine types normally don't have names associated with them. There is no "place" in the sea.

Each of these Keypoints have a Locale Type. Some of which are:

  • NameCity
  • NameCityCapital
  • NameVillage
  • VegetationBroadLeaf (Forest)

Background

 Background // this structure has not been seen
 {
      String BackgroundFilename;//"sat_lco.bmp"
      String BackgroundName; //"overlay1"
      float  OffsetXY[2];
      float  SizeXY[2];
      ulong  Transparency;
      shortBool Visible; // or ulong?
 }


Selection

Selection
{
 ushort               strlen;
 char[]               SelectionName[strlen];  // NOT null terminated
 ulong                nObjects;
 SelectionObject      SelectionObjects[nObjects]
}

SelectionObject

SelectionObject
{
 ulong ObjectInstanceID;
 byte  Unknown[8];

}

Enums

ObjectTemplateTypeEnum

enum ObjectTemplateTypeEnum { Undefined = 0, Natural = 1, Artificial = 2, Road = 3, Forest = 4, Road2 = 5 }

MarkerTypeEnum

enum MarkerTypeEnum { Rectangular = 0, Elliptical = 1 }