[rdo2000]

I think I've encountered a bug with the 1.6 plugin. When I try to change the output image path in the Output settings, I get an error popup saying that the filter string is incorrect. I presume this is in reference to output_image_types.txt. However, I hadn't even created that file the first time this error occurred. I tried copying the rgb_image_types.txt file (for which I'm using the installation default) to output_image_types.txt, but that didn't change anything. Also, when I try to render, the log shows that the render aborts with an error that ImageOutputPath is not specified (there is one in the output dialog, and the plugin even verifies that I want to overwrite it).

JDHill, I could send you the assembly (~2MB) if it would help. Thanks

- rdo

[JDHill]

Don't bother to send anything, I can repeat it here. Here's the workaround:

- highlight the output path (a quick double-click in the text box works nice)
- hit Delete
- you can now browse for the file

The error message is coming from the browser-dialog itself, seems I'm feeding it a poorly-formatted output-extension-choices string. Btw...if you ever think you've messed up those config files...just delete them, the plugin will re-create the default versions next time it needs them.

Thanks for reporting,

JD

[rdo2000]

Thanks for the quick reply JD. It turns out that I'd already tried that, and while it does let me browse for a file, the input doesn't seem to "stick". The log still shows an error (ImageOutputPath not specified). Is there something else I need to do? Thanks

- rdo

[JDHill]

That one I can't duplicate. Can you please post the path you're trying to write to, as well as a few lines from the log viewer around the area that relates to the path not being specified? I should be able to figure out where it's going wrong. It's strange, because if there's a path in the entry field at export-time, it's going to try to use it - so far the only place I can find that would tell you about a missing output path happens only when there really is nothing specified. After you try to write the MXS, and you get the 'not specified' error, is the path you browsed to still present in the Scene Manager, or has it been erased? It's possible that you've specified an impossible path (or that it's incorrectly being seen as such), and it's being zeroed-out without really explaining why.

The other bug is due to adding support for a bunch of new formats pretty late in the game, I've already found what's causing it and corrected this for future releases.

Thanks,

JD

[rdo2000]

Actually, I think I got it working. Not quite sure what happened--it may have been because I was fooling around with the output_image_types.txt file when trying to solve the original problem. Somehow I'd gotten it into a state in which the field was populated with what it thought was a bad value and it couldn't change it. Deleting output_image_types.txt seems to have fixed it.

Thanks for the quick feedback

- rdo

[JDHill]

Sounds good, thanks again for reporting. In fact, due to the bug you found, if the output image entry is not empty when browsing, output_image_types.txt extensions will not be used - this is causing the error. In actuality, the nnn_image_types.txt config files aren't so much for user-customization as they are for allowing for possible future output formats without requiring re-compilation/re-installation.

Cheers,

JD

[rdo2000]

Got it. One suggestion, though--the image type defaults to .bmp for both loading and saving bitmaps (textures, output files, etc.), which isn't very practical. That is, when I'm browsing for a texture on disk, I have to change the filter type to .jpg or .tif or "All types" before I can see what I'm looking for. Might make sense to reorder the default filter list so that the "All types" entry is at the beginning. Thanks

- rdo

[JDHill]

I see it's picking up .bmp to start with when the path is empty, because .bmp is the first extension in output_image_types.txt - you can modify this behavior by editing the config file. But this only applies when there is a blank path to begin with...if there is a path, the browser will be pre-set to that path, and it should be picking up this extension, using it as the active one. Basically, 'all images' is always last because the active extension is context-sensitive. It's kind of a standard behavior that the most-general choice would never be the preferred one, when hints are available to narrow it down.

Of course, you can't see all of this logic at work, due to the bug you uncovered at the top of this thread. Still, for a bit of fun, you can hack the config file if you want to, i.e.:

.png;*.jpg;*.tga|.png|.bmp|.tga|.jpg|.tif|.jp2|.ppm|.pbm|.pgm|.hdr|.exr

This will be parsed by the function that populates the extension filter, and the first entry will be put in as-is. So it will show up like this, with the top entry being active when there's no path:

PNG;*.JPG;*.TGA Files (*.png;*.jpg;*.tga)
PNG Files (*.tga)
BMP Files (*.bmp)
TGA Files (*.tga)
JPG Files (*.jpg)
TIF Files (*.tif)
JP2 Files (*.jp2)
PPM Files (*.ppm)
PBM Files (*.pbm)
PGM Files (*.pgm)
HDR Files (*.hdr)
EXR Files (*.exr)
All Ouptut Files (*.png;*.jpg;*.tga, *.png, *.bmp, *.tga, *.jpg, *.tif, *.jp2, *.ppm, *.pbm, *.pgm, *.hdr, *.exr)

JD