GR2 Editor/Viewer/Extractor/Importer

[gap]

Originally Posted by TheDarkWraith

Give me link to files and what you did so I can try and reproduce and figure out why

Originally Posted by gap

I will. I am now seeing if I can reproduce the problem

So, open the GR2 file contained in this package, right click on the first unused material (i.e. standard_13) and select 'delete'. Even after being deleted, it will keep being listed among the other materials. You will know that it is actually an empty name because, if you try deleting it again, you will get the message:

"Can't delete material because it doesn't exist!"

Save the file now. Everything is apparently fine, and the deleted material will be removed from the list of available materials, but if you try deleting the next unused material (material #985), you will get a "Collection was modified; enumeration operation may not execute" exception, and the file will close automatically due to corrupt memory

Files or memory getting corrupt while deleting materials is a very common error, and it dates back to v 1.1.374.1 (or even older), even though I don't remember if in the past it showed the same way as it is now.

[TheDarkWraith]

Originally Posted by gap

So, open the GR2 file contained in this package, right click on the first unused material (i.e. standard_13) and select 'delete'. Even after being deleted, it will keep being listed among the other materials. You will know that it is actually an empty name because, if you try deleting it again, you will get the message:

"Can't delete material because it doesn't exist!"

Save the file now. Everything is apparently fine, and the deleted material will be removed from the list of available materials, but if you try deleting the next unused material (material #985), you will get a "Collection was modified; enumeration operation may not execute" exception, and the file will close automatically due to corrupt memory

Files or memory getting corrupt while deleting materials is a very common error, and it dates back to v 1.1.374.1 (or even older), even though I don't remember if in the past it showed the same way as it is now.

Sounds like an easy fix. Looking into it now

[gap]

Originally Posted by TheDarkWraith

Sounds like an easy fix. Looking into it now

Excellent! I like keeping my files as clean as possible

[TheDarkWraith]

Originally Posted by gap

Excellent! I like keeping my files as clean as possible

Yep, it was an easy fix

The problem was when I went to delete the map references. In that function it determines what the new ExtendedData blueprint needs to be for the material and checks to see if one already exists. If one doesn't already exist it fails and sends back a cancel message. Well that cancel message just corrupted the file because it had already started deleting the material. This did expose something I'm adding: reason why it can't continue with deleting the material.

Now in this instance where we are deleting a material we could care less about changing the ExtendedData blueprint and thus I fixed this so it doesn't do this check when deleting a material.

[gap]

Originally Posted by TheDarkWraith

Yep, it was an easy fix

The problem was when I went to delete the map references. In that function it determines what the new ExtendedData blueprint needs to be for the material and checks to see if one already exists. If one doesn't already exist it fails and sends back a cancel message. Well that cancel message just corrupted the file because it had already started deleting the material. This did expose something I'm adding: reason why it can't continue with deleting the material.

Now in this instance where we are deleting a material we could care less about changing the ExtendedData blueprint and thus I fixed this so it doesn't do this check when deleting a material.

Another small suggestion for improving your Editor: when, from the 'Textures' tab, we set a new texture path for one of the existing textures, the texture of all the material maps using that texture is updated. At least this is what I can see from model's render preview and from Materials tab' tree view ('Texture' field). Yet, if I right click on one of the updated maps and I select 'Edit', I can clearly see that its 'bitmap' and 'File Name' ExtendedData properties still point to the old texture path/name. In my experience, updating those fields manually causes the file to get corrupt, so the only way to make them pointing to the right texture, is exiting from the ExtededData editor, right click on the 'Texture' field in Materials' tree view, select any other texture among the ones available, and finally re-select the wanted texture.
Is there any way that you can fix that?

[TheDarkWraith]

Originally Posted by gap

Another small suggestion for improving your Editor: when, from the 'Textures' tab, we set a new texture path for one of the existing textures, the texture of all the material maps using that texture is updated. At least this is what I can see from model's render preview and from Materials tab' tree view ('Texture' field). Yet, if I right click on one of the updated maps and I select 'Edit', I can clearly see that its 'bitmap' and 'File Name' ExtendedData properties still point to the old texture path/name. In my experience, updating those fields manually causes the file to get corrupt, so the only way to make them pointing to the right texture, is exiting from the ExtededData editor, right click on the 'Texture' field in Materials' tree view, select any other texture among the ones available, and finally re-select the wanted texture.
Is there any way that you can fix that?

I'll look into that tomorrow

v 1.1.452.1 released. See post #1
Fixes problem gap found with deleting Materials

NOTE: deleting unneeded Materials needs to be THE LAST thing you do to the file. Reason being I 'grab' the ExtendedData blueprints from all the materials in the GR2 file. If you change a Material and the app needs a different blueprint for the Material and it doesn't exist then you're screwed. I was lazy and used the easy way of grabbing the ExtendedData blueprints from the existing materials

[gap]

Originally Posted by TheDarkWraith

I'll look into that tomorrow

v 1.1.452.1 released. See post #1
Fixes problem gap found with deleting Materials

Take your time

Originally Posted by TheDarkWraith

NOTE: deleting unneeded Materials needs to be THE LAST thing you do to the file. Reason being I 'grab' the ExtendedData blueprints from all the materials in the GR2 file. If you change a Material and the app needs a different blueprint for the Material and it doesn't exist then you're screwed. I was lazy and used the easy way of grabbing the ExtendedData blueprints from the existing materials

In other words, we always need to keep a safe copy of our GR2 files ready for release with all their materials on, just in case we decide to add a new material?

P.S: have you read that?

Originally Posted by gap

I want the character to go back and forth from the loophole to the radio station, acting appropriately to each station. I also want him to use different objects while at the radio than he is using while on watch. Do you know if the SetBodyPartVisibility command used in u-boat crew scripts also works with secondary characters?

Any suggestion?

[TheDarkWraith]

Originally Posted by gap

In other words, we always need to keep a safe copy of our GR2 files ready for release with all their materials on, just in case we decide to add a new material?

P.S: have you read that?

I would definitely keep a backup copy of the GR2 file just before you delete all unwanted Materials

Not sure on whether SetBodyPartVisibility works on those characters or not. You're gonna have to try and see what happens.

There is no re-inventing anything.
Read all verts into a buffer and so on.
My program is a hack to over come your importer problem.
It is a simple problem to over come.
Buffer things then import.

[tonschk]

Thank you very very Much TDW

Originally Posted by TheDarkWraith

v 1.1.452.1 released. See post #1
Fixes problem gap found with deleting Materials

[TheDarkWraith]

Originally Posted by gap

Another small suggestion for improving your Editor: when, from the 'Textures' tab, we set a new texture path for one of the existing textures, the texture of all the material maps using that texture is updated. At least this is what I can see from model's render preview and from Materials tab' tree view ('Texture' field). Yet, if I right click on one of the updated maps and I select 'Edit', I can clearly see that its 'bitmap' and 'File Name' ExtendedData properties still point to the old texture path/name. In my experience, updating those fields manually causes the file to get corrupt, so the only way to make them pointing to the right texture, is exiting from the ExtededData editor, right click on the 'Texture' field in Materials' tree view, select any other texture among the ones available, and finally re-select the wanted texture.
Is there any way that you can fix that?

v1.1.453.1 fixes problem reported above

I looked into this and had another moment!
I forgot to code in the changing of the Material's ExtendedData type if whatever you did to it caused it's ExtendedData type to change. This has been fixed in v1.1.453.1. Don't be surprised if you get some errors now when changing materials and there's no ExtendedData type found in the file for the new ExtendedData type required. There is a solution coming for this though if you encounter it...just not done coding it in

v1.1.453.1 released. See post #1

Something HUGE is coming soon...when writing the code for the changing of the material's ExtendedData type missing above I had an epiphany...a rather LARGE epiphany

[gap]

Originally Posted by TheDarkWraith

v1.1.453.1 fixes problem reported above

Originally Posted by TheDarkWraith

Something HUGE is coming soon...when writing the code for the changing of the material's ExtendedData type missing above I had an epiphany...a rather LARGE epiphany

[tonschk]

Scientific breakthrough , I like that

Originally Posted by TheDarkWraith

I had an epiphany...a rather LARGE epiphany

[urfisch]

Originally Posted by gap

Not exactly. We can already import in game brand new GR2 units. We cannot create GR2 files from scratch, but we can clone the stock ones by renaming their bones, and we can import any 3d model in them.

The one substantial limitation still standing, is the number of separate meshes we can have (we can replace the meshes of the GR2 file used as template, but we cannot create new ones). This forces us to plan our unit carefully, and to choose accordingly the GR2 template where we want to import the unit (it should have a number of meshes equal or bigger that the number of separate parts that we want our unit to be composed of).

But, if you ask me, the main obstacle to the creation of new GR2 ships and planes by SH5 quality stabdards, is the time required to do it and the lack of man power.

thx for that, gap!

[Targor Avelany]

An observation from the latest GR2 Version (also observed in some previous ones) (finally was some free time):

There are 4 bones in a GR2 file that I'm taking as base for my little project. I'll just call them for simplicity 0-1-2-3. The structure is also simple:
0 (root bone)
|
-- 1 (main mesh bone)
|
-- 2 (main collision bone)
|
-- 3 (secondary collision/dmg bone)

I honestly still have no clue why this was done for this particular object, which was taken as a base (chrysler building). But I do know that I cannot move 3 bone out and try and use it on its own or switch to bone 2 as collision. Just telling you - it does not work. The bone specs are actually very very different. At least it looks that way.

There are 2 meshes. Call them mesh1 mesh2.
Mesh1 is by default sitting on bone 1 (bone bindings).
Mesh2 is by default sitiing on bone 3 (bone bindings again).

If I change the bindings, which should in turn thange the name of the bone to the bone I'm changing the binding to, it does not happen.
Furthermore, the mesh/bone will somehow ALWAYS be bind to the bone/mesh that it was ORIGINALLY bind to.
So here is a particular example to stop my sluring

Going back the the above described mesh:
Let say I want to change things and use bone 3 somewhere else. I still want a collision object/mesh and collision bone. That would mean that I would bind mesh2 to bone 2. Theoretically speaking, now mesh2 and bone 2 should be linked, united, two parts of one, etc (being silly here, but you get my idea). So from that, if I change the name of bone 2, the name of the mesh2 should also change and vice versa.
But that is not how that works. Changing name of the bone 2 will do nothing to the mesh2 and changing name of mesh2 will CHANGE NAME OF BONE 3.

It's not the biggest issue. Just something worth noting.