I fully agree with a full template helping other modders. The problem is you can't exactly write a full template due to the way the pointers work. You can't define the materials section until you know what all the pointers for the materials are doing. This is because some materials can have textures, no textures, or reference another material. I ran into this block when updating the template trying to define the materials. I couldn't write a 'template' for them that worked because I needed to know what the pointers for them did :x I had a template for the materials section that worked on one file but when tried on another file was totally hosed. Reason is due to not knowing what the pointers for that section said.

There is another problem with writing a full template and that deals with the art tool info section. All the names listed in the art tool info section is not the full list of names. Duplicate names are not put into this list BUT the pointers for the art tool info section will reveal that multiple names are being used. Hard to write a template for that.

These GR2 files are dynamic in nature, they are not static like .dat files. One can write a parser that reads a .dat file from start to finish very easily. This is not so with the GR2 files. There is a defined structure (that is dynamic in nature from file to file) in the GR2 file.

Yes, your template that I have seen will work correctly only with one file... may be, and then only partially.
You did not use all the features of scripting language of 010 editor...
Yes, the scripting language of editor is limited (limited analog of C), but it's enough to write a template... i think... and you absolutely did not use commands of going over... as FSeek and so on... and you must define and use all info of file header and not only...
and, at last, you have excellent Granny Viewer! :yep:
There is nothing supernatural... Did you write program in C? Yes... therefore, all as always... i think.
:salute:
Good luck.

And there's 1794 GR2 files in SH5 with no Mods installed.

http://i108.photobucket.com/albums/n...GR2-Finder.jpg

This will let you see what I'm doing so far: http://www.gamefront.com/files/20880...nny_SubSim_zip

This is a C# code file for my AntiGranny class. You can include it in a project of yours to use it and see what it does. You'll have to remove all my references to the GR2EditorViewer class as this source file is used in my GR2 editor/viewer app currently. The AntiGranny class currently has two functions - ReadData and WriteData. Both of those functions take a string that denotes the filepath to the GR2 file (the same string should be passed to both).

I've defined write pointer data at beginning of file so that the pointers read in will be written to a text file after you call ReadData and WriteData with the filepath of the GR2 file.

After the call to WriteData it will write a GR2 file composed of the info it read-in from the GR2 file specified. This GR2 file (and the pointer data text files) can be found in \app path\GR2Testing.

I'm looking for patterns currently in the pointers and some can be seen. There is some form of pointer that defines a new section. I'm also trying to understand what all the pointers do (some you'll see are just plain pointers and some are pointers to data). Of course how I've defined what a style of pointer is could be entirely wrong. I'm just looking for patterns/associations currently to understand the file structure.

You'll notice that some arttool info data is not written into the new GR2 file (DocumentContents, Headers, etc.). This is because I'm not sure how those ever get read in. There was no pointer to that data in the first section's pointers. There was one pointer to the start of that data and that pointer reads in 3D Studio MAX. How it reads the data after that I haven't a clue.

Hopefully this will spur more interest and maybe somebody will see something I'm totally overlooking/missing :yep:

Let's see if we can get some open source type thing going on here :yeah:

There is some good info in that source file. I've figured out more of what's in the info header and in the sections header at the beginning of the GR2 files.

And yes I know the code file does not use properties for variable access and that one shouldn't pass every parameter to functions as references (ref) and so on and so forth. This was put together for information gathering/testing purposes and is in no way a final draft.

Unfortunately someone else's code (in classical form) does not stimulate any interest ... every "goes mad" by own way... by interesting may be only program tricks, who solve non-standard situations rationally.

Thanks in any case. :up:

I really should learn C# someday but C and C++ is good enuff for me right now.

Here's some info I figured out working on the Quick GR2 Finder for another Game.

typedef struct { // Sectionsinfo
UINT Not_Sure<comment="Always seems to be zero">;

This is what it should be:

typedef struct { // Sectionsinfo
UINT FileSectionFormat<comment="0 = no compression 1 = Oodle0 compression (No longer used by RAD Game Tools but may be found in older files) 2 = Oodle1 compression">;

The Granny Change Log is full of useful information for filling in the Unknowns.

SH5 does not use compression that I have found.
But I've not checked all 1700+ files so I won't swear to that!

I may add this check to the GR2 Finder as an option at some point.
:hmmm:

There was something else I figured out looking at those other GR2 files but I forget what it was right now.

C# is like C in many ways. You'll be able to read a C# source file quite easily.

In the template's section header there's an unknown we had marked where the value is always 0x4. This 0x4 is an alignment value. It specifies the alignment of the file. Being 0x4 then everything is aligned to 4 byte boundaries. You see this in the text embedded in the file. I could never figure out why some text had 1,2, or 3 null characters (0x0) after them until I figured this alignment value out. Now it makes perfect sense :yep:

Here are some excerpts from that C# code file dealing with some unknowns we had defined in the info header and section headers (the comments denote what I have found dealing with SH5 GR2 files):

// are comments in C#

here is the file header:
internalByte[] magicstring;
internalint fileliststartoffset; // from start of file
internalint unknown1;
internalint unknown2;
internalint unknown3;

here is the info header (not sure if rootobjecttype is correct in it's definition but the rootobjectoffset is correct):
internalint fileformatrevision;
internalint filesizeinbytes;
internalint crcvalue;
internalint bytesfromoffsettostartofsections; // from offset
internalint numberofsections;
internalint rootobjecttype; // defines which section root object is in ?
internalint rootobjectoffset; // defines offset from start of section above where root object is located ?
internalint unknown1;
internalint unknown2;
internaluint tag;
internalint[] unknown3; // 8 (bytes) of them

Here are the sections (compressed size and uncompressed size may not be in correct order - haven't found any SH5 GR2 files that are compressed):
internalint unknown; // always 0
internalint sectionfileoffset; // from start of file
internalint compressedsize; // compressed size and uncompressed size must be equal
internalint uncompressedsize; // compressed size and uncompressed size must be equal
internalint alignment; // usually alignment is 4 (everything aligned on 4 byte boundaries)
internalint startofdatafileoffset; // offset + sectionfileoffset = location
internalint startofdatafileoffset2; // offset + sectionfileoffset = location
internalint pointersfileoffset; // from start of file
internalint numberofpointers;
internalint pointertounknown; // usually points to end of file
internalint unknown2; // always 0

so in my sections where does this FileSectionFormat fall (is it unknown or unknown2) :06:

So far 6 people have downloaded the source file....no one has any comments/suggestions/ideas?

I think no need to write about known things here.
... better to write personal messages...
Your "fantasy" look pretty funny...
Here we have to publish ready-made solutions - templates... i think.
:woot:

@privateer... you are right... but name must be more shortly.
e.g.:
enum Format : int
{NoCompression = 0, Oodle1Compression = 2};
... The names of the parent objects are complementing this short name.
...
@ TDW... your verbosity is tedious and poorly translated.

What fantasy? You call it fantasy to try and understand something. Please Anvart not even you know the GR2 format. I'm showing what I'm doing in trying to understand the GR2 format. Maybe others will benefit from it.

What known things are you talking about? You don't want to share information with everyone? The sharing of any information regarding the GR2 format will only benefit everyone.

And what important information am I ignoring?

Found a little interesting discovery:

The first pointer in a GR2 file points to the first string in the embedded strings (which is usually 3D Studio MAX in SH5 GR2 files). I never found out how it reads the additional strings after that up to 'General'. But I think I found out how: the second pointer is an unknown of 0x6 and has an offsetinsectiondata of 0xA0. 0xA0 is 160 decimal. 160 decimal / 8 bytes = 20 and 20 is the exact amount of additional strings that need to be read in. Coincidence? Maybe but don't think so. Works on all SH5 GR2 files I've tried so far.

With that piece solved I can now dynamically write out the strings in the GR2 file (allowing user to change the strings read in).

ran into a little trip up.....was writing the embedded strings into the new GR2 file dynamically (vice from pointer info read in to allow user to change the strings read in) and ran into problem of when multiple strings are being referenced by one string. I was just blindly writing the embedded strings into the file from the pointer data but since changing to this dynamic nature it has exposed a problem. The problem is starting with pointer 62 and on from section 0 pointers the pointers aren't 'writing' embedded strings - they are attaching embedded string info to pointer locations in the file.....:hmmm:

fixed the problem. Needed to define a new pointer type that dealt with string references :up:

A new version of the C# AntiGranny code file can be found at post #1 :yeah:

:DL :woot: Amazing :salute: :D :sunny: TheDarkWraith :yeah::rock: :up:

It's not close to anything near amazing. I'm struggling trying to figure this beast out....but god do I love a challenge :yeah:

The art tool section (with it's embedded strings) seems to be the hardest part of this beast to tackle so far. I'm halfway through the art tool section now :DL

As I'm writing it now it will be able to create new GR2 files from scratch. If I can write a new GR2 file from scratch then editing existing ones should be a walk in the park. When I say from scratch I mean you feed it a dat file and it creates a GR2 file from it.

Look over my AntiGranny code file. Make changes to it, experiment with it. The only way to figure something out is to take it apart, make some assumptions, and test....

Aargh! I don't understand much of this but that sounds just about perfect concerning the imported ships! :D

it's still a long way from being able to do that :yep:

Walked away from the computer and sat down to watch a movie and it hit me that there was an error in my code for the dynamic writing. Had to fix it :DL New version of the code file at post #1