-
-
Notifications
You must be signed in to change notification settings - Fork 7.4k
Description
Hi there,
I am unsure if this intended behaviour, but thought I'd report it:
When using the API's app.command.SaveFileCopyAs
with fromFrame
and toFrame
range arguments alongside a file format containing {frame}
, the resulting file frame numbers will start from the last frame number present in a file at the export path.
For example, if I have a sprite with 15 frames, the first export will result in Sprite_001 ... Sprite_015
, and a subsequent export will create files with Sprite_016 .. Sprite_030
For API use, I would expect the existing range Sprite_001 .. Sprite_015
to be overwritten instead of being appended to , and this does happen when using the tags
argument alongside a {tag}_{frame}
file format.
For a use case, this would help exporting frames where the resulting save parameters are frame specific. E.g. in my use case, I am trimming the resulting image to that sprite's visual bounds, which I believe requires using app.SaveFileAsCopy() in a for loop to provide the proper bounds
argument.
I am aware this might be very specific use case, please disregard this report.
Metadata
Metadata
Assignees
Type
Projects
Status