GR2 Editor/Viewer/Extractor/Importer

[TheDarkWraith]

Originally Posted by gap

First test report:

the problen with the export process being hung up by unmanaged events (window minimization/file overwriting request) is still unsolved, but this is a minor flaw.

really? Then there is something I'm totally missing here How do I make this problem appear again?

Originally Posted by Targor Avelany

Btw, there are still problems with updating names/bones in any of the submarines. The only version that it is working on for me is 1_1_230_1

What exactly is the problem and what do I do to make the problem appear?

Originally Posted by Ekmek

I see it. But looks like the decompressor is still disabled. Keep up the great work!

Yep. It's disabled due to not finished coding in these special datatype definitions I found. They play major part in the vertex data.

[TheDarkWraith]

ok I think I finally see why you would still be having that problem gap. I was not enclosing any new objects created in at least try...finally blocks where in the finally I would dispose of the object. I was rather disposing of the object at the end of the function BUT there were chances the function would return before the end of it was reached (the finally block ensures the code contained in it will be executed before the function returns) Lots of changes to make...

[gap]

Originally Posted by TheDarkWraith

really? Then there is something I'm totally missing here How do I make this problem appear again?

Export a mesh, and when requested to specify file name and location, choose to overwrite an old obj file. A window requesting you to confirm the overwriting will pop up, but you won't be able to select neither 'yes' nor 'no':
you can resume working on GR2 Editor, but the mentioned window will remain in memory, and if you force its closing, the main process (GR2 editor) will be closed as well.




On a side note, I have checked a maginified tree in game. This is how it looks:



Some copies of it look okay, while others are cut in diagonal.
Evidently at least one of the 4 faces got screwed. Now I need to discover if someting I did in Wings 3D screwed it, or rather GR2 Editor is misreading its information.

Stay tuned

[gap]

Originally Posted by TheDarkWraith

ok I think I finally see why you would still be having that problem gap. I was not enclosing any new objects created in at least try...finally blocks where in the finally I would dispose of the object. I was rather disposing of the object at the end of the function BUT there were chances the function would return before the end of it was reached (the finally block ensures the code contained in it will be executed before the function returns) Lots of changes to make...

As I told you, this bug is not such a big problem, as far as we remember not to save over existing files. Take your time on it TDW

[Targor Avelany]

Originally Posted by TheDarkWraith

What exactly is the problem and what do I do to make the problem appear?

In regards to the editing submarine gr2's:

Open any of the Uboat gr2s (VIIA for example).
Try renaming a bone.
Try saving:

Error comes up:



Also, if I rename en-mass via 010Editor, after which try opening in more recent version: it obviously comes up with the checksum error, I click to fix it, it fixes it, but when I try to save: same as above.

In version 1_1_230_1 - no problem with either.

Also, of course, in the newest version, can't open any of the uboats.. Because of the error "Section 6's mixed values count calculated != file size in bytes"
I assumed that it was due to you disabling any loading of gr2s with mixed values.

[TheDarkWraith]

Originally Posted by gap

Export a mesh, and when requested to specify file name and location, choose to overwrite an old obj file. A window requesting you to confirm the overwriting will pop up, but you won't be able to select neither 'yes' nor 'no':
you can resume working on GR2 Editor, but the mentioned window will remain in memory, and if you force its closing, the main process (GR2 editor) will be closed as well.

On a side note, I have checked a maginified tree in game. This is how it looks:

Some copies of it look okay, while others are cut in diagonal.

Evidently at least one of the 4 faces got screwed. Now I need to discover if someting I did in Wings 3D screwed it, or rather GR2 Editor is misreading its information.

Stay tuned

Easy way to determine if my app is causing the problem or not. Export the tree without making any changes to it. Re-import back into app. Save file. Exit app. Check in game. If renders fine then problem is not with app.

As far as the export problem you reported I finally got the app to do the problem. The problem is now fixed for good You can export to an existing file without hanging anymore. That was an odd problem because it wasn't the apps fault - it was an OLE problem with the SaveFileDialog box running in a thread I spawned off

Originally Posted by Targor Avelany

In regards to the editing submarine gr2's:

Open any of the Uboat gr2s (VIIA for example).
Try renaming a bone.
Try saving:

Error comes up:

Also, if I rename en-mass via 010Editor, after which try opening in more recent version: it obviously comes up with the checksum error, I click to fix it, it fixes it, but when I try to save: same as above.

In version 1_1_230_1 - no problem with either.

Also, of course, in the newest version, can't open any of the uboats.. Because of the error "Section 6's mixed values count calculated != file size in bytes"

I assumed that it was due to you disabling any loading of gr2s with mixed values.

You should've been able to open most of the sub files still. I'll look into the problems you have reported now

[gap]

Originally Posted by TheDarkWraith

Easy way to determine if my app is causing the problem or not. Export the tree without making any changes to it. Re-import back into app. Save file. Exit app. Check in game. If renders fine then problem is not with app.

Yep I wanted to run exaclty this test, but didn't get time to do it yet

Originally Posted by TheDarkWraith

As far as the export problem you reported I finally got the app to do the problem. The problem is now fixed for good You can export to an existing file without hanging anymore. That was an odd problem because it wasn't the apps fault - it was an OLE problem with the SaveFileDialog box running in a thread I spawned off

[gap]

Originally Posted by TheDarkWraith

Easy way to determine if my app is causing the problem or not. Export the tree without making any changes to it. Re-import back into app. Save file. Exit app. Check in game. If renders fine then problem is not with app.

Okay TDW

I did as suggested by you, and I can confirm that GR2 Editor in not the culprit. Similarly, I can exclude Wings3D: I took the object generated by your app, I imported it in Wings and I exported without making any change. The tree, imported back in vegetation.GR2, showed correctly in game

Whatever was wrong, it had to be my mistake. Probably when I split one of the base edges in Wings, I broke object's geometry

[gap]

Tree update:

after several tests, I can declare that nothing was wrong with my scaled trees, except for the fact that they were... too big

Seems that SH5 trees can't trespass a given size. The fact that during my first test, where I had changed just one mesh, some trees were looking okay and some others were cut diagonally may depend on the fact that SH5 randomizes the size of each tree, for adding variety. Probably only the bigger trees were corrupted.

The good news is that we can reuduce their size at wish and by any percent with no adverse effects

[Trevally.]

Originally Posted by gap

The good news is that we can reuduce their size at wish and by any percent with no adverse effects

[TheDarkWraith]

Originally Posted by Targor Avelany

In regards to the editing submarine gr2's:

Open any of the Uboat gr2s (VIIA for example).
Try renaming a bone.
Try saving:

Error comes up:

Also, of course, in the newest version, can't open any of the uboats.. Because of the error "Section 6's mixed values count calculated != file size in bytes"
I assumed that it was due to you disabling any loading of gr2s with mixed values.

There's actually many reasons why the app was giving you problems with these sub GR2 files. It has nothing to do with mixed values (except for the Type II). Once loaded it has many broken chains which is causing all the problems.

These special GR2 files are a freakin nightmare. One thing they allow is embedded strings to not have to follow an alignment value (they only need 1 null termination character) but the sections still have to fall on a multiple of 0x4. Each section's alignment is also different - most of the sub's section 1 is set to 0x20 where this is usually 0x4. This obviously will cause problems if you try to add an embedded string that is not a multiple of 0x4 (including it's null termination character) because all the following sections will not be aligned to a 0x4 multiple anymore. My solution was to add 'filler' in the linked list to align these sections back to a 0x4 multiple and it works. I'm just working through some other problems noticed with these special GR2 files.

[TheDarkWraith]

Here's version 1.1.332.1 for testing: http://www.mediafire.com/?bgni4keov4ngq4w

What it will not allow:
- any GR2 file with mixed values
- any GR2 file with trackgroups
- any GR2 file with animations

What is enabled that is new:
- decompressor (remember that you have to have a specific version of the Granny Viewer installed on your computer for the decompressor to work!)

The problems with the subs (changing bone name and error from it) has been fixed. The problem gap reported of 'hanging' when exporting has been fixed. Many, many other problems I found by accident and from trying to load/modify the decompressed Augustus.GR2 file have been fixed also.

Starting with this version and forward the app will check for broken chains on file load and before saving. If any are found when loading the file it will close it (because it failed to read it in correctly). If any are found when trying to save it will refuse to save the file (because it's more than likely corrupt in memory). Let me know if you encounter any files with broken chains and send them or post a link to them here.

If you decompress a file I ask that you view it in Granny Viewer to ensure it opens correctly AND also reopen the decompressed file with the app to ensure the app reads the file correctly.
All decompressed files will be placed in app path\Decompressed\filename. Inside of that folder will contain all the decompressed sections and the actual decompressed GR2 file that the app made. You will also find another folder called Old. Inside that folder are the previous decompressed section files (if you chose to move them when decompressing).

NOTE: any file that has duplicates of anything (mainly extendeddata and extendeddatadata) will cause broken chains if you delete the main object that the duplicates are based on. I do not provide you this information in this version. The only way you will know this has happened is the app will report broken chains when trying to save. I'm coding this part currently for the next version.

[gap]

Originally Posted by TheDarkWraith

Here's version 1.1.332.1 for testing: http://www.mediafire.com/?bgni4keov4ngq4w

The problems with the subs (changing bone name and error from it) has been fixed. The problem gap reported of 'hanging' when exporting has been fixed. Many, many other problems I found by accident and from trying to load/modify the decompressed Augustus.GR2 file have been fixed also.

I will test the fixed features asap

Originally Posted by TheDarkWraith

What it will not allow:
- any GR2 file with mixed values
- any GR2 file with trackgroups
- any GR2 file with animations

This excludes guns GR2's that I was messing with a while ago, but for the moment I will live with it

Originally Posted by TheDarkWraith

What is enabled that is new:
- decompressor (remember that you have to have a specific version of the Granny Viewer installed on your computer for the decompressor to work!)

which version? I have v 2.9.1.0, is it okay?
moreover, it didn't come with an installer, how can I tell your app where to look for granny viewer's exe?

Originally Posted by TheDarkWraith

Starting with this version and forward the app will check for broken chains on file load and before saving. If any are found when loading the file it will close it (because it failed to read it in correctly). If any are found when trying to save it will refuse to save the file (because it's more than likely corrupt in memory). Let me know if you encounter any files with broken chains and send them or post a link to them here.

yes, vegetation.GR2's: I can open vanilla ones, but if I tell your application to add the missing strings to them, when it tries to write the changes on disc a warning message pops up saying that broken chains were found in section 0. Files saved with previous versions of GR2 Editor can't be opened at all (same message on opening them)

[Targor Avelany]

yay! Very nice, TDW!

Will be testing later today.

btw, it is hillarious to attempt and figure out replacement of mesh on an existing animation. Some funny stuff happens.

[TheDarkWraith]

Originally Posted by gap

which version? I have v 2.9.1.0, is it okay?
moreover, it didn't come with an installer, how can I tell your app where to look for granny viewer's exe?

yes, vegetation.GR2's: I can open vanilla ones, but if I tell your application to add the missing strings to them, when it tries to write the changes on disc a warning message pops up saying that broken chains were found in section 0. Files saved with previous versions of GR2 Editor can't be opened at all (same message on opening them)

You'll have to send me v2.9.1.0 so I can RE it to find out where to inject my code and where to tell my code to install it's hooks.

I had a feeling that I was unknowingly corrupting GR2 files with previous versions I'm still learning this file format to this very day.

Just adding missing strings shouldn't be causing you any problems. Have you tried this on a stock unmodified file?

Originally Posted by Targor Avelany

yay! Very nice, TDW!

Will be testing later today.

btw, it is hillarious to attempt and figure out replacement of mesh on an existing animation. Some funny stuff happens.

The next version should discern between ridig and non-rigid (deformable) meshes in the meshes list box. This should help with that.

Working on the mixed values now so I can remove that file limitation on the next version.