Skip to content

Using fromFrame and toFrame in app.command.SaveFileAsCopy() doesn't overwrite existing files in folder #5413

@AurochChris

Description

@AurochChris

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

Labels

Type

No type

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions