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 :yep:

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 :up:

Excellent! I like keeping my files as clean as possible :smug:

Yep, it was an easy fix :up:

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? :hmm2:

I'll look into that tomorrow :up:

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 :88)

Take your time :up:

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? :hmm2:

P.S: have you read that?

Any suggestion?

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

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.

Thank you very very Much :salute: TDW :sunny:

v1.1.453.1 fixes problem reported above

I looked into this and had another :eek: 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 :D

:up:

:o :D

Scientific breakthrough :yeah:, I like that :rock:

thx for that, gap!

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. :dead:

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