[Format] NFA NFC NFS QPF (and partially NFW, header NFM)

[glandu2]

As some post talk about these file but it seems that their format was not posted here (even if it's somewhat easy to figure out their format vs RDB files)

So here there are. Feel free to correct me or add information about missing or incomplete files.

Note that I never drawn their content so I may make mistake about which file has what coords.

NFA files may contain collision bounding box of things, the player can't go through these lines in a normal game play.

 Spoiler

struct {
  int polygonCount;
  struct Polygon {
    int pointNum;
    struct Point {
      int x;		//same unit as location file nfc
      int y;
    } points[pointNum];
  } polys[polygonCount];
}

so in this file, there are several polygons which contains several points.

NFC files might be worldlocation

 Spoiler

struct HEADER {
  int record_count;
  LOCATION_INFO_HEADER data[record_count];
}

struct LOCATION_INFO_HEADER
{
  int nPriority;
  struct {
    float x;
    float y;
    float z;
  } vCenterPosition;
  float fRadius;
  int strDescriptionSize;
  char description[strDescriptionSize];
  int strScriptSize;
  char scriptLUA[strScriptSize];
  int polygonCount;
  Polygons polys[polygonCount];
};

struct Polygons {
  int pointCount;
  struct Point {
    int x;			//unit: 1 game point = x*tileLength/8 + rx*(mapLength(=16128))
    int y;
  } points[pointCount];
}

So in this file, there are several location which have a centerPosition, a description (in korean, it seems to be the location name shown in game, but in korean) and a LUA function with an argument/
The LUA function is called when loading the map. I think that it's just a way to retrieve the worldlocation ID or something like that.
Each location contains several polygons (or just one) with several points that should describe where is the location in the game world.

NFS files

 Spoiler

struct NFS_HEADER_V02 {
  char szSign[16] = "nFlavor Script";
  short dwVersion;
  int dwEventLocationOffset;   //offsets in the file
  int dwEventScriptOffset;
  int dwPropScriptOffset;
}

-------------------------------------------
struct EventLocation {
  int nLocationCount
  Location records[nLocationCount];
}

struct Location {
 //records (note: real coords (in game) = coord*tileSize)]:
  double left;
  double top;
  double right;
  double bottom;
  int stringSize;
  char string[stringSize];    //a string of length stringSize
}

-------------------------------------------
struct EventScript {
  int nScriptCount;
  Script records[nScriptCount];
}

struct Script {
  int nRegionIndex;
  int nFunctionCount;
  function records[nFunctionCount];
}

struct function {
  int nTrigger
  int nStringSize;
  char functionString[nStringSize];
}

-------------------------------------------
struct PropScript {
  int nScriptCount;
  PropScriptInfo record[nScriptCount];
}

struct PropScriptInfo {
  int prop_id;
  int x;			//unit: normal game: absoluteX = rx * (mapLength=16128) + x
  int y;
  short model_id;
  int nFunctionCount;
  function records[nFunctionCount];  //same record definition as for Script functions
}

Sorry for the different format ... I figured out this one several years ago and others the yesterday

What I think:
This file contain several event location which seems to trigger LUA function calls when someone enter it or interact with an object.
The event area is one or more square(s) using special coords (must multiply by tileSize which is 42). A square may have an associated string but I don't know to what it refer (probably a LUA function)

The file contains also scripts records which contain the region ID (the index of the square defined before in the file ?) and a set of function to be called. I didn't find a file with trigger not 0. The function is a string which is like "mob(215036, #box)", probably the monster ID.

It contains a propscript, which is a set of several prop that have a model and a position. I think that the functions are called whenever someone click on this prop (like portals ? -- [edit:ismokedrow] portals are in qpf files, and I indeed not seen this structure in files)

QPF file contains quest prop (object that trigger something)
Also discovered by iSmokeDrow, I found maybe the end of a record (using sframe data from a old sframe.pdb)

 Spoiler

struct Header
{
  char szSign[18];
  unsigned int dwVersion;
  int nPropCount;
  Prop propEntry[total_entries];
}

struct Prop
{
  int nQuestDBID;
  float x;		//normal unit ingame, add rx * 16128 (region size)
  float y;
  float fZOffSet;
  float fRotateX;
  float fRotateY;
  float fRotateZ;
  float fScaleX;
  float fScaleY;
  float fScaleZ;
  unsigned short wPropNum;
  bool bLockHeight;
  float fLockHeight;
  short nTextureGroupIndex;
}

So the file contains several prop which have a ID and transformations info (position, rotation, scale). I think that if bLockHeight == true, then the position of the object is fixed at a Z position too (not just on the ground). This may used for object on a wall for example, but not on the ground.
[edit:ismokedrow] all FieldProp seems to be in this file

I just read the NFW files but I don't know what mean the data inside.

 Spoiler

struct Root {
  int waterInfoNum;
  struct Prop {
    float values[9];
    int unk1;
    int someId;
  } waterInfo[waterInfoNum];
}

so this file contains several water info, someId might be an ID refering a row in db_lowqualitywater.rdb but I don't checked that. There is 9 float values which I don't what they are. (And 9 is not a multiple of 2 so it does not seems to be coords)

Other format: NFM, PVS, NFE. I don't know about them and didn't dug into these file so much. But I found some interesting structure in the sframe.pdb, so here they are:

 Spoiler

struct NFM_HEADER_V22
{
  char szSign[16];
  unsigned int dwVersion;
  unsigned int dwMapPropertiesOffset;
  unsigned int dwTerrainSegmentOffset;
  unsigned int dwPropOffset;
  unsigned int dwVectorAttrOffset;
  unsigned int dwWaterOffset;
  unsigned int dwGrassColonyOffset;
  unsigned int dwEventAreaOffset;
  int nTileCountPerSegment;
  int nSegmentCountPerMap;
  float fTileLength;
};

struct NFM_SEGMENTHEADER_V11
{
  unsigned int dwVersion;
  unsigned __int16 tile[3];
};

struct NFM_VERTEXSTRUCT_V11
{
  float fHeight;
  unsigned int wFillBits[2];
  unsigned __int64 wAttribute;
  KTripleColor Color;
};

struct NFM_PROPSTRUCT_V15
{
  int nPropIndex;
  float x;
  float y;
  float fZOffset;
  float fRotateX;
  float fRotateY;
  float fRotateZ;
  float fScaleX;
  float fScaleY;
  float fScaleZ;
  unsigned __int16 wPropNum;
  bool bLockHeight;
  float fLockHeight;
  __int16 nTextureGroupIndex;
};

struct NFM_SPEED_GRASS_V1
{
  float px;
  float py;
  float nx;
  float ny;
  float nz;
};

struct NFM_PVS_HEADER_V1
{
  char szSign[16];
  unsigned __int16 dwVersion;
  char nSegmentCountPerMap;
  char nMapStartPosX;
  char nMapStartPosY;
  unsigned __int16 nSegmentCount;
  int nPropCount;
  char nSegmentLeft;
  char nSegmentTop;
  char nSegmentRight;
  char nSegmentBottom;
};

struct NFM_CAMERA_WORK_STRUCT_V1
{
  float px;
  float py;
  float pz;
  float tx;
  float ty;
  float tz;
  float opx;
  float opy;
  float otx;
  float oty;
  unsigned int m_dwSpeed;
  float m_fTargetRotation;
  float m_fCameraRotation;
};

struct NFM_SPEED_GRASS_COLONY_INFO
{
  int nPolygonID;
  float fDensity;
  float fDisTribution;
  float fSize;
  float fHeightP;
  float fHeightM;
  KColor Color;
  float fColorRatio;
  float fColorTone;
  float fChroma;
  float fBrightness;
  float fCombinationRatio;
  float fWindReaction;
};

struct NFM_PROP_DATA_V1
{
  unsigned int nSegmentIdx;
  unsigned int nPropIdx;
};

struct NFM_PVS_SEGMENT_V1
{
  char nSegmentX;
  char nSegmentY;
  unsigned __int16 nIncludeSegmentCount;
};

struct NFM_SEGMENT_DATA_V1
{
  char nSegmentX;
  char nSegmentY;
};

struct NFM_PVS_PROP_V1
{
  char nSegmentX;
  char nSegmentY;
  int nIncludePropCount;
};

struct NFM_CAMERA_WORK_HEADER_V1
{
  char szSign[19];
  unsigned int dwVersion;
  unsigned __int16 camerawork;
};

So as I said, I didn't take the time for deep investigation about these file about what they talk about. But I don't think I am so far from the reality. (And some of other devs here know more about these file than me, but didn't released the file format, common guys It's better together : D (no I don't play minecraft)

(edited parts with information about someone else are notified like this: [edit:<pseudonym>])

[c1ph3r]

Originally Posted by glandu2

As some post talk about these file but it seems that their format was not posted here (even if it's somewhat easy to figure out their format vs RDB files)

So here there are. Feel free to correct me or add information about missing or incomplete files.

Note that I never drawn their content so I may make mistake about which file has what coords.

NFA files may contain collision bounding box of things, the player can't go through these lines in a normal game play.

 Spoiler

struct {
  int polygonCount;
  struct Polygon {
    int pointNum;
    struct Point {
      int x;		//same unit as location file nfc
      int y;
    } points[pointNum];
  } polys[polygonCount];
}

so in this file, there are several polygons which contains several points.

NFC files might be worldlocation

 Spoiler

struct HEADER {
  int record_count;
  LOCATION_INFO_HEADER data[record_count];
}

struct LOCATION_INFO_HEADER
{
  int nPriority;
  struct {
    float x;
    float y;
    float z;
  } vCenterPosition;
  float fRadius;
  int strDescriptionSize;
  char description[strDescriptionSize];
  int strScriptSize;
  char scriptLUA[strScriptSize];
  int polygonCount;
  Polygons polys[polygonCount];
};

struct Polygons {
  int pointCount;
  struct Point {
    int x;			//unit: 1 game point = x*tileLength/8 + rx*(mapLength(=16128))
    int y;
  } points[pointCount];
}

So in this file, there are several location which have a centerPosition, a description (in korean, it seems to be the location name shown in game, but in korean) and a LUA function with an argument/
The LUA function is called when loading the map. I think that it's just a way to retrieve the worldlocation ID or something like that.
Each location contains several polygons (or just one) with several points that should describe where is the location in the game world.

NFS files

 Spoiler

NFS_HEADER_V02:
char szSign[16] = "nFlavor Script";
short dwVersion
int dwEventLocationOffset
int dwEventScriptOffset
int dwPropScriptOffset

-------------------------------------------
[EventLocation]
int nLocationCount
[Location records] x nLocationCount

[Location records (note: real coords (in game) = coord*tileSize)]:
double left;
double top;
double right;
double bottom;
int stringSize;
char string[stringSize];

-------------------------------------------
[EventScript]
int nScriptCount;
[Script records] x nScriptCount;

[Script records]
int nRegionIndex;
int nFunctionCount;
[function records] x nFunctionCount;

[function record]
int nTrigger
int nStringSize;
char functionString[nStringSize];

-------------------------------------------
[PropScript]
int nScriptCount;
[propscripts record] x nScriptCount;

[propscript]
int prop_id;
int x;			//unit: normal game: absoluteX = rx * (mapLength=16128) + x
int y;
short model_id;
int nFunctionCount;
[function records] x nFunctionCount;

Sorry for the different format ... I figured out this one several years ago and others the yesterday

What I think:
This file contain several event location which seems to trigger LUA function calls when someone enter it or interact with an object.
The event area is one or more square(s) using special coords (must multiply by tileSize which is 42). A square may have an associated string but I don't know to what it refer (probably a LUA function)

The file contains also scripts records which contain the region ID (the index of the square defined before in the file ?) and a set of function to be called. I didn't find a file with trigger not 0. The function is a string which is like "mob(215036, #box)", probably the monster ID.

It contains a propscript, which is a set of several prop that have a model and a position. I think that the functions are called whenever someone click on this prop (like portals ?)

QPF file contains quest prop (quest object that trigger something)
Also discovered by iSmokeDrow, I found maybe the end of a record (using sframe data from a old sframe.pdb)

 Spoiler

struct Header
{
  char szSign[18];
  unsigned int dwVersion;
  int nPropCount;
  Prop propEntry[total_entries];
}

struct Prop
{
  int nQuestDBID;
  float x;		//normal unit ingame, add rx * 16128 (region size)
  float y;
  float fZOffSet;
  float fRotateX;
  float fRotateY;
  float fRotateZ;
  float fScaleX;
  float fScaleY;
  float fScaleZ;
  unsigned short wPropNum;
  bool bLockHeight;
  float fLockHeight;
  short nTextureGroupIndex;
}

So the file contains several prop which have a ID and transformations info (position, rotation, scale). I think that if bLockHeight == true, then the position of the object is fixed at a Z position too (not just on the ground). This may used for object on a wall for example, but not on the ground.

I just read the NFW files but I don't know what mean the data inside.

 Spoiler

struct Root {
  int waterInfoNum;
  struct Prop {
    float values[9];
    int unk1;
    int someId;
  } waterInfo[waterInfoNum];
}

so this file contains several water info, someId might be an ID refering a row in db_lowqualitywater.rdb but I don't checked that. There is 9 float values which I don't what they are. (And 9 is not a multiple of 2 so it does not seems to be coords)

Other format: NFM, PVS, NFE. I don't know about them and didn't dug into these file so much. But I found some interesting structure in the sframe.pdb, so here they are:

 Spoiler

struct NFM_HEADER_V22
{
  char szSign[16];
  unsigned int dwVersion;
  unsigned int dwMapPropertiesOffset;
  unsigned int dwTerrainSegmentOffset;
  unsigned int dwPropOffset;
  unsigned int dwVectorAttrOffset;
  unsigned int dwWaterOffset;
  unsigned int dwGrassColonyOffset;
  unsigned int dwEventAreaOffset;
  int nTileCountPerSegment;
  int nSegmentCountPerMap;
  float fTileLength;
};

struct NFM_SEGMENTHEADER_V11
{
  unsigned int dwVersion;
  unsigned __int16 tile[3];
};

struct NFM_VERTEXSTRUCT_V11
{
  float fHeight;
  unsigned int wFillBits[2];
  unsigned __int64 wAttribute;
  KTripleColor Color;
};

struct NFM_PROPSTRUCT_V15
{
  int nPropIndex;
  float x;
  float y;
  float fZOffset;
  float fRotateX;
  float fRotateY;
  float fRotateZ;
  float fScaleX;
  float fScaleY;
  float fScaleZ;
  unsigned __int16 wPropNum;
  bool bLockHeight;
  float fLockHeight;
  __int16 nTextureGroupIndex;
};

struct NFM_SPEED_GRASS_V1
{
  float px;
  float py;
  float nx;
  float ny;
  float nz;
};

struct NFM_PVS_HEADER_V1
{
  char szSign[16];
  unsigned __int16 dwVersion;
  char nSegmentCountPerMap;
  char nMapStartPosX;
  char nMapStartPosY;
  unsigned __int16 nSegmentCount;
  int nPropCount;
  char nSegmentLeft;
  char nSegmentTop;
  char nSegmentRight;
  char nSegmentBottom;
};

struct NFM_CAMERA_WORK_STRUCT_V1
{
  float px;
  float py;
  float pz;
  float tx;
  float ty;
  float tz;
  float opx;
  float opy;
  float otx;
  float oty;
  unsigned int m_dwSpeed;
  float m_fTargetRotation;
  float m_fCameraRotation;
};

struct NFM_SPEED_GRASS_COLONY_INFO
{
  int nPolygonID;
  float fDensity;
  float fDisTribution;
  float fSize;
  float fHeightP;
  float fHeightM;
  KColor Color;
  float fColorRatio;
  float fColorTone;
  float fChroma;
  float fBrightness;
  float fCombinationRatio;
  float fWindReaction;
};

struct NFM_PROP_DATA_V1
{
  unsigned int nSegmentIdx;
  unsigned int nPropIdx;
};

struct NFM_PVS_SEGMENT_V1
{
  char nSegmentX;
  char nSegmentY;
  unsigned __int16 nIncludeSegmentCount;
};

struct NFM_SEGMENT_DATA_V1
{
  char nSegmentX;
  char nSegmentY;
};

struct NFM_PVS_PROP_V1
{
  char nSegmentX;
  char nSegmentY;
  int nIncludePropCount;
};

struct NFM_CAMERA_WORK_HEADER_V1
{
  char szSign[19];
  unsigned int dwVersion;
  unsigned __int16 camerawork;
};

So as I said, I didn't take the time for deep investigation about these file about what they talk about. But I don't think I am so far from the reality. (And some of other devs here know more about these file than me, but didn't released the file format, common guys It's better together : D (no I don't play minecraft)

if there is a real together perhaps but we are on epvpers glandu feel free to share everything but i won't it isn't hard to read these structures^^ Except nfm which is a little bit harder but if you read the captainherlock.h closely it isn't that hard.

[glandu2]

Well even obvious things takes time to discover BTRF was much harder to understand and the sframe.pdb & .exe didn't help me much (in fact I just used files). I know that on epvp, there are not so much devs here (active devs at least), but what I would want to see is something like
That's not minecraft that is important here, but the fact that many things of this game are known and written there. I don't plan to make a wiki but hey, post fall far away in the depths of the forum .. (The search function as long as you remember what words where used to describe the thing you want to find)

(and I post that since I had difficulties to find where I saved that information on my disk several years ago ...)

[ismokedrow]

Glandu if I remember correctly the QPF store all FieldProps that can be clicked or interacted with, such as portals or flowers/rocks/mushrooms/treasure chests on the ground.

P.S.

You're right glandu, if the people with the ability to sort out/dissect and/or improve what's going on in the client/server just start sharing their work then not only will all be easy to find, but progress will begin. Massive improvements/developments + hopefully a single place with treasure troves of information will be made (e.g. the wiki)

As far as "losing" things from your hard-drive, just a better reason for us all to upload our work to docs.google.com (he won't lose them)

P.S.S.

Thanks for the help with the QPF viewer again!

[eziorav]

Thanks glandu
i got a simple question
since this format is for c++ and im not familiar with this language how could i use it in c# ?

[glandu2]

I don't know very well C# but here when I write:

struct Root {
  int integerField;
  float otherField;
};

I mean that the file contains 2 value, the first is a integer (4 byte) and the second is a float (4 byte).

Root is just the name of the structure and does not appear in the file, as for integerField and otherField.

when a write field like that:

int anArray[50];

It means that there is 50 int values and I call that array "anArray".
When the type of this array is a structure, that is a array of structure, I write:

struct Root {
  int numberOfTheStructureField;
  struct TheStructureField {
    int something;
    float otherThing;
  } structureData[numberOfTheStructureField];
}

which mean that in the file, there is an integer numberOfTheStructureField which contain the number of structure TheStructureField (because of [numberOfTheStructureField])
TheStructureField is the type of the structure (like a class) and structureData is the field name.

It's equivalent to:

struct Root {
  int numberOfTheStructureField;
  TheStructureField structureData[numberOfTheStructureField];
}

struct TheStructureField {
  int something;
  float otherThing;
}

Where the structure content is defined outside the main structure.
A file that use this structure can be:
{4, {1, 4.123}, {2, 3.23}, {5, 42.123}, {123, 4123.1}} (where number without dot are integer and number with a dot are floats, keep only the numbers and you have what you would have in the file)


also:
char aDescriptionText[size];

is just a string of length "size" bytes (not less, not more), in C#, it's something like:
string aDescriptionText;

(if I remember correctly)