Exporting layers to separate files, same-named layers are excluded

Questions & Problems
#1

When saving out images from a project with the “Create File per Layer” option, only uniquely named layers get exported. Same-named layers are ignored.

777×416

Notice in the above image there’s two layers named “Layer 5”. Essentially, one of these doesn’t get exported.
There’s no overwrite warning when using Create File per Layer, so technically what I believe happens is the first “Layer 5” gets exported as a file, then the second “Layer 5” also gets exported but overwrites the first one.

Solution: just append “_#” to the end of same-named layers.

Why would anyone have layers with identical names? For me personally, the more layers I amass in a project the more likely it becomes that I may have same-named layers. Layers named something like “light” or “lines” may occur multiple times in my projects.

“Create File per Layer” is an awesome export option that has saved me tons of time when compiling artwork drawn in PMNG into Photoshop.
And it could be made even more robust if it handled same-named layers intelligently.

#2

I agree, PM NG should be consistent in this regard: either prevent having same-named layers in the application, or find a way to export them with re-adapted names — maybe, along the lines of how File Explorer handles creating multiple new files or folders, to which it adds " (1)", " (2)", etc.

Probably it would be better if PM NG prevent users from creating same named layers, and would enforce the above mentioned numbering scheme to layers for which the user is attempting to re-use an existing layer name.

This discussion also brings up the issue of how layer names are related to their exported files, i.e. if PM NG enforces layer names which have valid file name characters — e.g. a layer name shouldn’t be allowed to contain special characters like *$/\, which are not valid in file names. It seems to me that if layer exportation attempts to reproduce in the file names the original layers names that these types of restrictions should apply, in order to ensure that export and import operations won’t fail.

Another issue would be letter casing, since Windows file system is case insensitive; so PM should consider differently cased layer names as being identical (e.g. “Layer1” and “LAYER1”) and should also prevent this type of same-naming, for they would not be unique names when translated to exported files.

#3

Also, I would like to add that this type of enforced consistency between layers names and their exported file names would allow better automation processes, e.g. for plugins that could handle exporting/importing projects, or doing so via command line switches (if/when supported).

Command line automation can be a powerful resource, especially for those working in the video game industry, for it would allow to setup continuous integration and deployment workflows, and interact with other applications. E.g. it would be possible to use scripts to export images from PMNG and process them with tools like ImageMagick, which is a great way to create manipulated preview images to send to third parties (e.g. scaling them up, adding water marks, converting the to other formats, etc.).

#4

Good thoughts. As usual, you think much deeper into this stuff, hehe.

Just want to add one thing - personally I’d much much prefer to be able to name layers however I want, including using the same exact name for layers.
And when/if same-named layers pose an issue for automated processes and such, then let PMNG solve the problem at that time by adding characters, etc. But not before it’s actually an issue.
Preventing same-named layers completely seems like slicing bread with a chainsaw. :eyes:

True - characters not valid for filenames used in layer names is also a problem. Currently, PMNG simply substitutes an underscore for illegal characters.

#5

I agree that there are different needs at conflict here; on the one hand the rightful freedom to name layers without having to be subdued to file system restrictions, and on the other hand the need to ensure automation integrity (for those who do need the feature).

As long as PMNG is consistent with its way of handling invaliding characters, exporting shouldn’t be affected then. The problem would be the reverse operation though, for by re-importing exported layers that had their names tweaked to adapt to the file system needs would not be restored with their original names (PMNG won’t be able to reconstruct the original name).

There are some workarounds to this though, e.g. translating invalid characters to their ASCII codes or Unicode code points — which might result in ugly filenames though. If I remember correctly, this is the approach taken by Bash for Windows for handling Unix-invalid characters.

Ultimately, @jan.cosmigo could add a per-project options to enforce/disable strict layers naming conventions, thus allowing both uses.

I think that automation is an important feature for anyone working with pixel art projects on long-term projects, especially if he/she’s working with other team members (e.g. a graphic artist working with programmers). Being able to rely on a scripted toolchain to carry out common tasks dealing with projects manipulations, exporting to other formats, filtering, etc., is an essential part of any coordinated team effort, because it slims down time-wasting operations and allows unattended recurrent jobs to be run over a network.

Of course, ultimately it’s up to @jan.cosmigo to decide in which direction efforts should be invested, and these discussions are a good reference for they represent the various different needs of PM’s user base.

I’ve always considered Pro Motion the state of the art application for professional pixel artists who work in the field of video games; so I’m a strong supporter of all those features that push extending PM (plugins, an API, command line options to run background tasks, etc.), and especially so in the light of how collaborative participation in software projects has drastically changed in the last decade — version control via Git has now become wide spread, and there’s a plethora of third party services for continuous integration and deployment, benchmarking, bug tracking, and whatnot (you name it).

So, it’s inevitable that pixel artists today tend to demand ever more similar features, which allow them to better integrate their workflow with that of their fellow team members who handle programming, sound effects, etc. You’ll notice that today all major applications are investing in that direction, not just code editors, but also graphic and sound editing software, because team work and collaborative editing via Internet services is now becoming standard practice across the whole industry.

But of course, this might not hold true for many PM users, which also include independent artists and developers who are most unlikely uninterested in this type of interfacing.

Hopefully, PM could strike a balance that would not prevent one type of usage over the other. As far as this feature of layer exportation is concerned, it might be a good moment to make a decision that wouldn’t prevent either uses in the future.