[Burnum]

I decided to play with making a texture from scratch in MXED and discovered I can't directly edit the Name field, though I can select it. Then after saving the texture I discovered that it uses the file name for the name, ok, that works... But, it seems to have bugs, for example my texture name 0.847" Aluminum Flex (A).mxm is a perfectly legal file name in Mac OS X. But in MXED I see the material is now named 0. It seems to take the first delimiter of . and drop everything else rather than drop the last and keep everything else?

Next I proceeded to change the file name (not sure what name to use that is as descriptive yet) but it still opened with the material Name of 0, and crashed after I tried to re-save the file. (the first time) I'm not sure why...

[JDHill]

That is not a legal file name on Windows. If it's not legal in Windows, then you can't use it on OSX either, and vice-versa, since both Maxwell and the files it writes are cross-platform. On the dot-separator issue, I do think Maxwell (or more likely, the Qt libraries underneath it) currently has a problem with file names which use more than one period. Here, that would mean that it thinks you have a file named 0, whose extension is 847" Aluminum Flex (A).mxm. That wouldn't explain any crash, but it might explain the material being named 0.

[Aji Enrico]

Interesting issue, enough for me to make a test example for my self

filenametest.jpg

That can easily be fixed using QFileInfo::completeBaseName instead of QFileInfo::BaseName and leaving the QFile::suffix as it is.
Don't know if that will break Mac or Linux but in Windows it works well.

I must mention that making this "easy" change might produce a lot of bugs elsewhere in the code, but it is doable non the less.

Cheers!

[JDHill]

Thanks -- that is interesting. Just to be clear, the above was speculation on my part. I do know that I've fielded a couple of bug reports in which Maxwell (Render, not MXED in those cases) was unable to locate an MXS file when its path included folders with dots in their names. As you say though, while it is surely a fixable thing, file paths are a much more complex topic than they appear to be, especially when you factor in saving/reading files from multiple OSes, along with networking issues.