-
Notifications
You must be signed in to change notification settings - Fork 5
ENWF
ENWF is the magic header of data format used in some of the chunk and zone layers.
It describes collision data for the game world.
It is present in all versions of the game we have access too.
The current assumption is that ENWF is short for ENtropy World File, with Entropy being a name used for the physics system shared between the client and server (which in turn uses Havok as its library).
To our current knowledge the ENWF format can be summarized as:
ushort version
ushort revision
uint id
physics material ids []
vertex storage items ([])
indice storage items ([])
material storage items ([])
mopp storage items ([])
havok binary tagfile
See the CollisionGeometryLayerData parser in this 010 Template.
When loading, the client logs "Loading chunk file v%u.%u (code built for v%u.%u)". Version and revision values are passed into this message, hence those names are accurate.
Version is 3 and revision 2 in modern clients.
The parsing requires version to be 3 and revision to be less than 3 in order to parse.
We don't know if id is correct, but it seems to be a unique value based on analyzing all of the chunk data in 1962. (TODO: Double check).
The material ids and storage items are all named from clearly indicated error messages present in the client.
Storage items are not present in revision 0. They are present in revision 2. (TODO: Research when the revision changed)
The rest of the data is in Havok Binary Tagfile format. It is a format of serialized class data that describes different collision shapes.
The root object appears to always be a hkpListShape.
Because the root object is not a hkRootLevelContainer, you cannot open this tagfile with Havok Content Tools.
Instead, using AssetCc2.exe from Havok SDK, you can convert this data to .xml.
The format is used for 4 different layer types in the zone and gtChunk files.
Within chunks, the format is used to parse 3 different layer types (names pending):
-
CHUNK_COLLISION1(0x040101) -
CHUNK_COLLISION2(0x040105) -
CHUNK_COLLISION3(0x040103)
These layers only appear on SubChunks of LOD 3 and at most once per SubChunk.
Each SubChunk on this LOD always has the CHUNK_COLLISION1 layer.
This layer appears to contain the primary collision data for the world.
Within the Tagfile hkpExtendedMeshShape entries, Triangle Subparts and the UserData field reference the vertex and indice blocks.
Some SubChunks also have CHUNK_COLLISION2 and or CHUNK_COLLISION3 layers.
These layers seem to not provide any vertex and indice blocks, relying on the materials and the tagfile shapes.
CHUNK_COLLISION2 seem to be related to water surfaces as it defines shapes where the water would be.
Not sure about CHUNK_COLLISION3, it has previously been thought to be used for trigger or blocking volumes for example around spawn closet areas.
Within zone, the format is used to parse layers of type ZONE_WORLD_CHUNK_IMPORT (0x20900).
This has not been investigated deeply but it seems that not all zones contain such a layer and those that do only contain one. The data within appears to also be related to water areas, seemingly using only box shapes.