Halfy has just clarified for me - this is just when no frame number is
listed - not for cases where the # is present :-)
Cheers,
Alan.
On 1/15/07, Alan Jones <skyphyr(at)gmail.com> wrote:
Hi Halfy,
> This was more intended as a convenience thing, so that the full-on template
> path wasn't required. It covers the most-often used cases. I simply didn't
> consider that I'd have to anticipate a hackaround for an "interestingly"
> written 3rd party plugin.
Well I'd say adding robustness to error catching is most certainly an
interesting feature. Seeing XSI has no way of saying where it died (or
even if until recently) during a render. The problem isn't this
functionality from within the interface (not saying I think it's a
good idea still), but that it does is from xsibatch.
Kim, while I could catch it and change the paths there still is the
potential for missing information. For instance, the user may have a
different amount of padding for one pass than the scene render
options. From what I can see there is no way to ensure this wouldn't
be lost when converting to the [Frame] variable.
Though I still don't see how returning something different from what
is stated in the field is ever a good thing. What's the point of being
able to set something if the program will at it's discretion replace
or omit it? Even worse is that this has created a scenario where
you'll get a different outcome from in previous versions - so bringing
a scene forward will potentially give different results in something
as basic as the name of the file it writes to.
Cheers,
Alan.
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
