Publicado originalmente por Vintage:

Oh, I just thought you did something to make it delete anything before the last / or \

I tried, but my string scanning is a bit rusty and it's nice to have at least a portion of the directory naming intact. I also decided it wasn't worth the time for a better fix once I actually found something that worked.

Publicado originalmente por Vintage:

Publicado originalmente por SMarioMan:

I just modified the truncation method in your script myself.

In what way(s)? *Is curious*

I used my basic understanding of Python to truncate all but the last 50 characters or so of the datablock's name instead of the first 63 bytes. It's a dirty fix, but it seems to work properly for my purposes. It's not hard to do either. Python scripts can be easily modified in a text editor.

I just modified the truncation method in your script myself. Better that it work with all of the models than having to modify each and every SMD. Thanks for all your help. It's working great now.

Publicado originalmente por Artfunkel:

Very long datablock names are now truncated with a warning. This means that all materials on the model this thread is about will end up being the same, but trying to be clever about fixing it didn't seem appropriate.

Thank you so much for fixing this!

Edit: Spoke too soon. Now the script assigns the same material for everything by default, since the textures are in the same general directory and now take on the same name.

Thanks everyone for looking into this. It seems my best best is to simply use an older version of Crowbar. Thanks for all the help and the development of such useful tools.

Publicado originalmente por Vintage:

I've had this happen with a Team Fortress 2 cosmetic or two before (but not many), however I think it's more a fault with the decompiler than the Blender Source Tools (although I admit I didn't check the affected cosmetic meshes in Notepad++, so it could be either).

Hmm. Could be. It's just that Crowbar decompiles the model quickly while Blender Source Tools takes forever to run the script on problematic meshes.

First of all, thank you for maintaining such a helpful script for the Source engine. It seems that there is a bug in the import script that causes separate material slots to be created for each polygon in a mesh instead of one per actual material in the mesh. I am trying to use this script with Titanfall models. Here is what I'm seeing: http://i.imgur.com/sPzahS6.png
I'm not the only person with the issue. Here is another user that posted the same problem with this tool, likely when importing meshes from a different game: http://blenderartists.org/forum/showthread.php?307815-Remove-1000-materials
Any help would be great. Thanks for reading my post.