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