RobBaer wrote:MTKnife wrote:I that that would work, yes. However, the asset downloader doesn't do anything like that, so either way you're going to have to do something manual to make it work.
I know you tend to be a big asset downloader. Do you think material name collisions are common now or likely to become more common in the future as the database gets bigger? I guess the question is really whether this is a "one off" or a design flaw that should be handled more formally somehow. Assets are supposed to get unique uuids, but unfortunately material texture names are harder to handle in this manner.
This is the only one I know of, so I hesitate to say it's as systemic problem. (OK, actually I think it happened one other time, when punkduck uploaded a red Ponytail01, and I renamed mine to fix that one--so, weirdly, this one filename has been involved in both examples.) However, it's possible it would have happened more often if people hadn't been careful to avoid the collisions; the most prolific contributors are probably also the same people who are most aware of what's in there already. But as the database gets larger and larger, it will become more and more difficult to do that from memory. In this case, I had to go back and double-check, looking at details of files, to verify that most of the "new" assets were actually old ones that had been updated: before that, I thought he was colliding with multiple materials (his own, as it turned out), not just the one that he'd collided with before.
Looking at things from another perspective, a better way to fix this problem might be to do something that would be more generally useful: add a search function to the asset site; a simple exact search would be quite useful, but something that used a slightly more sophisticated algorithm, like Levenshtein distance, would be any better (and if it were in Python, I'd volunteer to do it). OTOH, the code that would allow the asset downloader to detect collisions would also allow it to detect updates to existing assets, which would, again, but more generally useful.
In the case of dariush86, I suspect half the problem is he isn't reading this, just as he didn't read the last time I mentioned the issue.