Locked layer unexpected behaviour

Bug Reports
1

Brief:
When trying to apply following operations to a locked layer, Aseprite crashes without any prompt (let’s name this set of tools Toolset1):

  • Edit->Adjustments section tools;
  • Edit->FX section tools;
  • Edit->Replace Color tool;
  • Edit->Invert tool.

However, following operations go through locked layer status, and are actually applied (let’s name this set of tools Toolset2):

  • Edit->Rotate section;
  • Edit->Flip Horizontal and Flip Vertical;
  • Edit->Shift section.
  • Edit->Text tool.

Finally, “Insert Text” has its own peculiar thingy. It is possible to insert text onto a locked layer, and then successfully delete it if selection was not reset. Resetting selection after inserting text permanently applies it to locked layer.

Reproduction steps:

To reproduce buggy behaviour of Toolset1:

  1. Create a new document;
  2. Fill layer with some content (although, this occurs even with an empty layer);
  3. Lock the layer;
  4. Use any tool from Toolset1 either from menu or via hotkey on the locked layer;
  5. Aseprite silently crashes.

To reproduce buggy behaviour of Toolset2:

  1. Create a new document;
  2. Fill layer with some content (although, this occurs even with an empty layer);
  3. Lock the layer;
  4. Use any tool from Toolset2 either from menu or via hotkey on the locked layer;
  5. Observe Aseprite successfully applying correspondent tool to a locked layer;
    (Text tool only)
  6. (4) Use Text tool on the locked layer;
  7. (5) Transform with text in it appears, it is still possible to move it, or delete it, applying text with Enter edits locked layer pixels.

Expected behaviour:

If currently selected layer is locked, trying to use any tool on it should result in user warning. I also doubt it was intended to have a set of tools which can break through locked layer state.
Uncaught exception suspected in Toolset1 case. Or someone forgot layer locked state check in both cases, which is more probable.

Aseprite Version v1.2.5-beta1-x64, Steam, Windows

I was so surprised to see such an anomalous interaction :smiley:

2

Hi @WimeSTone, thanks for your time describing each scenario. About the toolset1, the crash is fixed for the next v1.2.5 (to be released on Monday if everything goes right). I’ll see what to do in the second case.

There are one main issue with these commands, mainly when they are combined with unlocked layers. For example, if we select three layers in the timeline, and one of them is locked (and it’s just the active one), we should make the commands available anyway (because they can be applied to the other unlocked layers). I have to think about a good solution for this case.

1 Like
3

More thinking about this one: There is a special case where flipping/rotation is used on the entire sprite (i.e. when there is no selection), in this special case (I think) we should ignore the locked status of layers and just flip/rotate the whole thing.

4

Some of these issues are fixed. There are some commands (like Shift pixels) that don’t work on a range of cels, but that will be for a future version (today I’ll see if I can release v1.2.5-beta2, and next week the final v1.2.5)

5

Thanks for fixing crash. :slight_smile:
Regarding Rotation and other tools, I guess it would be logical if:

  • sprite-wide rotation/flip goes through locked layer state, you would normally want to rotate all of your layers;
  • all the others cannot break through locked layer status.

What if “Text tool” would place text on a new layer named after text contents right above selected layer in hierarchy. Would solve this and a lot of other problems when dealing with text. Should I request it as a new feature?

Edit: just got beta2, you have my gratitude for fixing that.

1 Like