re: Omens Of War .TER File Format

[gustav]

This is a response to a thread I found in the archives, here: http://www.eqemulator.net/forums/showthread.php?t=15876

For my own purposes, I've been working on parsing some of the EQ files (mesh data mostly). It's kinda fun to try to figure them out, anyway I've made a bit of progress on the TER file beyond that listed in this thread, and figure I'd share it, in case anyone wanted to know. I will use the syntax of the original thread (C style), although I'm coding in Java myself. The salient points follow:

1) At this time there are 3 versions of the file format, with Header->version values of 1, 2, and 3.

2) After the Header is a section of Strings, and then a segment which the original thread was not able to figure out. I figured it out. :) Here's how to parse it:

Seek from the end of the header an additional Header->list_length bytes. This gets you at the start of the object list.
The name list is a series of null terminated strings.
In a loop for Header->object_count times, you will find:

struct ObjectHeader {
uint32 index; // A non-unique number assigned to the object entry. Unsure how to interpret at this time.
uint32 name_offset; // Name of the object, as offset from start of the name list. C convention uses null termination on Strings. (e.g. rockGrunge)
uint32 other_name_offset; // Another name offset (e.g. Opaque_MPLBump2UV.fx)
uint32 property_count; // Count of object properties to follow
}
Following each ObjectHeader, in a loop for ObjectHeader->property_count, you will find:

struct ObjectProperty {
uint32 name_offset; // A name offset for the property name
uint32 type; // The type of the property
uint32 value; // The value of the property
}
Based on the ObjectProperty->type, one interprets the ObjectProperty->value as a 'float' when 0, a name offset when 2, and an uint32 (RGBA value?) when 3.




At this time, outstanding items include:

Why do ObjectHeader->index values repeat. I do note that they tend to start at 0 and work their way up 1 at a time, and then reset to 0 or 1, and continue the progression. Rinse/repeat.
Sometimes there appears to be duplicate object entries out there. Perhaps this is related to the above point. There could be a higher level structure about this list of objects I'm not seeing.
I've not noticed a difference between Version 1 and Version 2 files, but I've not looked hard yet.
Version 3 files include additional data after the polygon list. I've not yet tried to figure out what it is.


For an example of the object data, I am able to extract the following information from the westkorlachb.eqg/ter_westkorlachb.ter file:


Object 0: FailsafeShader
Effect: Opaque_MPLBasic.fx
Properties:
e_TextureDiffuse02 = grid_standard.dds
Object 1: Material #1
Effect: Opaque_MPLBump2UV.fx
Properties:
e_TextureDiffuse02 = Di_korlach_cave_wall01.dds
e_TextureNormal02 = Di_korlach_cave_wall01_16n.dds
e_TextureCoverage02 = ab_WKB_bot_ov01.dds
e_fShininess00 = 12.0
Object 2: Material #2
Effect: Opaque_MaxWater.fx
Properties:
e_TextureDiffuse02 = rc_cavewater_c.dds
e_TextureNormal02 = rc_cavewater_n.dds
e_TextureEnvironment02 = ra_watertest_e_01.dds
e_fFresnelBias0 = 0.2
e_fFresnelPower0 = 8.0
e_fWaterColor13 = 0xff000a1c
e_fWaterColor23 = 0xff003a2b
e_fReflectionAmount0 = 0.2
e_fReflectionColor3 = 0xffffffff
e_fSlide1X0 = 0.02
e_fSlide1Y0 = 0.02
e_fSlide2X0 = 0.03
e_fSlide2Y0 = 0.03
Object 3: Material #3
Effect: Opaque_MPLBump2UV.fx
Properties:
e_TextureDiffuse02 = Di_korlach_cave_wall01.dds
e_TextureNormal02 = Di_korlach_cave_wall01_16n.dds
e_TextureCoverage02 = ab_WKB_top_ov01.dds
e_fShininess00 = 12.0


gus

[gustav]

For version 3 files, I was mistaken about there being additional data after the polygons. It appears there are an additional 12 bytes per Vertex. Something more like:


struct Vertex {
float x, y, z; // Vertex location
float i, j, k; // Normals?
uint32 unknown1; // New field in V3
float unknown2, unknown3; // New field in V3
float u, v; // Tex coords, clamped to [0,1]
};


Not sure what the additional data is for.

gus

[fathernitwit]

just to make sure, you have looked at the code from openeq right? I suspect that it has more detail than the linked thread (ter.cpp/ter.hpp)

[gustav]

Hadn't check out that particular project. I shall. thanks.

[gustav]

The SVN repo listed in the archives for openeq appears to be dead, so I cannot find the code. It would also not appear to be hosted on sourceforge for eqemu, which is why I never found it before, and went forum archive-diving and subsequently posted this thread. Too bad, sounds like they made some great progress on understanding the game files.

[fathernitwit]

here is the latest that I have:
http://www.projecteq.net/fathernitwit/OpenEQSVN.tgz

[gustav]

The .ter parsing in this code is based on the original thread's understanding of the format. Everything I posted is an improvement upon that understanding. I've yet to determine if there's additional things done in the parsing, there does look to be something going on with triangle textures with pointer -1. This code should provide me with some insights on interpretting the file formats. Thanks for sharing! --gus

[KungFuHamster]

Prophecy of Ro and The Serpent's Spine do not use .TER files. Instead, it appears that a new file structure, .DAT, has surfaced. Arguably this may be of little interest to you folks, since they're not included in Titanium, so not supported yet by the emulator.

If you use S3DSpy to look through the .EQG files, you'll notice there are no .TER files in the PoR and TSS EQG's.

I post this merely as an FYI, in case anyone might proactively start looking at the new files and deciphering their structure.

[Pawzz06]

So can we now gather items from PoR or not yet?

I mean can we install the PoR xpansion will i still be able to see the servers and will i be able to gather the gear that i summon??

[mattmeck]

So can we now gather items from PoR or not yet?

I mean can we install the PoR xpansion will i still be able to see the servers and will i be able to gather the gear that i summon??


No you cant