Good ol' Days

[x-ta-c]

I've created an IRC channel for now. Hopefully this will help kickstart some development, or at least help organize our ideas into one area.

server is: irc://slashnet/TRPG

or Irc.slashnet.org  and then /join #TRPG

Would be nice to have all the active players hanging out at the very least, so everyone should connect! I'll keep the server up for a week or so, and see if anyone uses the channel. Hopefully everyone uses it as it's intended, or at least as a community hub where we can share ideas, and just generally discuss. If it ends up being dead this whole week or two, I'll take the channel down. Hopefully that won't happen, as it would be great resource to keep the community tied together. See ya there.

[Antecedent]

After talking to Bovidi and rj on IRC and poking around the 1.40 client, I was sufficiently satisfied with the client (Fast loading times, GUI files as raw script rather than compiled, etc) but not with the tools available for content creation.  rj expressed a desire to have a heightmap importer for terrain tiles and so I began taking apart the .ted files, which contain the terrain data.

.ted actually turned out to be a renamed zip-like archive (read: You can open it with basically any archiver), each containing a mapName#0.dtb and mapName.dtf.  .dtb is the file with the actual tile itself (I suspect one tile per .dtb, hence the #0), while .dtf seems to be some sort of meta/organizational file that handles the .dtb and references a .dml.  Supporting this is the mission editor, in which Terrain objects have a field for "Grid Files" where a .dtf is referenced.

Ultimately, the flow (in a .mis) seems to be:

• Load the .ted as a SimVolume.
• Load the .dtf from the .ted via the Terrain object.
• .dtf inherently loads .dtb.

The following is a 010 Editor template for .dtf, but it is currently very simplistic due to time constraints:

Code: [Select]

//--------------------------------------
//--- 010 Editor v3.2.1 Binary Template
//
// File: dtf.bt
// Author: Antecedent
// Revision: r1
// Purpose: Read Tribes 1.40 .DTF files.
//--------------------------------------

typedef struct
{
    SetBackColor(cLtGray);
char gfilSignature[4]; // == GFIL == Grid File(?)
uint gfilFileSize; // Number of bytes remaining in file.
uint gfilUnknown1; // Seen only as 1.  (Number of DTBs?)
    SetBackColor(cLtBlue);
uint gfilDmlRefSize; // Number of bytes in DML file name.
if(gfilDmlRefSize > 0)
{
char gfilDmlRefFile[gfilDmlRefSize]; // DML file name.
}
} DTF_FORMAT;

DTF_FORMAT format;
Tomorrow will see me actually modifying the files to figure out the non-obvious stuff.  I will also look at setting up a wiki for these sorts of information if we don't already have one.

[EVIL_INC]

Im kind of useless in this part. I am computer illiterate when it comes to the fiddly stuff and have only ready made code/models that I have already donated that was given to me. Top notch stuff but I dont know how to integrate/adjust any of it. I'm only an ideas man on background and fluff and stuff to have at the end but know nothing about how to get it there. My computer is outta whack and I dont even have sound anyway. Hopefully soon after I get moved outta my house, I'll get another one.

[Bovidi]

If you get any further on the terrain stuff let me know...I have been working on and off figuring out the terrain for a while now and can't get very far.

My knowledge of this so far is this:
Tribes either using QuadTrees or Octrees (I think they actually used octrees in this case)
In editor mode there are a few little tricks that can give you a bit more stuff.  exec(editor) - press f4, type in ted::window(mainwindow), you can get extra information about terrain...1.40 is more stable for terrain editing but doesn't contain all the ted stuff...btw ted stands for terrain editor.

For the dtf file...this is where I don't have enough patients but I will tell you what I know
dtf data structure at a glance reminds me a bit of a vol file (the old 1.11 types), but different.

Initially it starts with char[4]=GBLK, then what I assume uint file size, uint unsure, char[7]=block-0...from there I have no clue
dtf files seem to be compressed, as flat map (not completely flat, ranging 0-8 in height) produce a file size of 182kb and from what I see no real pattern, while a truly flat map (all value 0) produces a file size of 60kb and a slight patter emerges...still working out what each block is though.  If I had to guess the portion is pin/flag info, next is the height maps, material information, then after that there is no pattern so I can't even guess what is being stored in their...maybe terrain rotation data or something.
From what I know about tribes the compression is either lzh or rle...haven't bothered figuring out which yet or even if they use something else

If you want the files that I used to test this stuff let me know

[Antecedent]

.TED research remains ongoing.  A timeframe is hard to place on these sorts of things, but at least a little more understanding is gained each day.

Tribes either using QuadTrees or Octrees (I think they actually used octrees in this case)

They may actually be using quadtrees.  It is worth noting that Andrew posted some linkage supporting the use of quadtrees (see here, the original site is dead), and that TGE also uses quadtrees for its terrain.  Unfortunately, it seems Andrew's method of obtaining the heightmaps was just to dump them from memory where everything is stored simply, which does not help with the file format.

dtf files seem to be compressed, as flat map (not completely flat, ranging 0-8 in height) produce a file size of 182kb and from what I see no real pattern, while a truly flat map (all value 0) produces a file size of 60kb and a slight patter emerges...still working out what each block is though.  If I had to guess the portion is pin/flag info, next is the height maps, material information, then after that there is no pattern so I can't even guess what is being stored in their...maybe terrain rotation data or something.
From what I know about tribes the compression is either lzh or rle...haven't bothered figuring out which yet or even if they use something else

They are definitely doing something wonky while storing terrain data as a file.  Changing the height of a single point causes nearly a tenth of the file to change, and comparing that version of the terrain with another version where that same point is changed again also results in that same tenth being changed entirely.  However, it is worth noting that while adding a flag causes that same tenth to change entirely, different versions of that same terrain with various flags at that same point only show minor (read: two byte) differences between each other.  I also noticed the same trend you did where simplified terrains take less space, especially after relighting a flat terrain such that it has no shadows.  My next tests will probably involve aspects of the terrain other than the heightmap in the hopes they will be stored more simply or at least provide clues.

[dionecron]

I just sent this message to a dead PCRPG.ORG email account.  I figured I would not post it here just because Im totally new to this community but I do remember the good ol days of pcrpg and was wondering if the server was down...?  I hope to be playing some pcrpg some time soon and would love to know about what else this team is working on.  Thanks for your time, if anyone reads this that is.