app.command.MoveMask error when wrapping with a value higher than sprite width

For context, I’m using Aseprite v1.3-beta5-x64 from Steam in Windows 10.

Hello! I’m working on an Aseprite script that uses app.command.MoveMask for shifting pixels in a selection and having them wrap around the selection boundary.

However, I found that, if the amount of pixels to shift for (labeled internally as quantity) is higher than the image width, rather than wrap the pixels around, it will instead just “paste” the new image while leaving the rest of the pixels “untouched” (that is, not repeated, not wrapped, but instead completely unaltered). Undoing the action will also break the original image by only restoring the original image partially, and leaving a section completely untouched.

Included below is an image that hopefully explains the bug and its results:


1 Like

It’s beyond frustrating that a legitimate bug has gone entirely ignored for a month and a half. I understand most “regular users” wouldn’t ever encounter it, but it sucks to be spending my own time as a script developer, trying to expand the features of Aseprite for the rest of the userbase, and then go entirely ignored when reporting a problem with the software that directly affects my contributions to the community, especially when I know as a programmer that such a fix would be quite trivial (I’m absolutely sure this could be fixed in the application with a simple modulo operation). Just disappointing.

1 Like

Hi @kidmarscat, we’re going to include a fix for this in the next release thanks to @behreandtjeremy. ( the contributed fix Floor Modulo in Shift Image Mask by behreajj · Pull Request #3004 · aseprite/aseprite · GitHub ).

Sorry that we cannot keep track of all reported bugs but there are so many bug reports & feature requests that sometimes several issues will be ignored for some time until we notice them.

1 Like

So a solution was implemented and proposed a month after this report by someone else, and yet it wasn’t incorporated to Aseprite until now.

The community guidelines say I can’t criticize people, so I won’t. I’m just gonna state this again: it took a whole year for the solution to be implemented in Aseprite.

1 Like

You can check the release notes to see in what we’ve been working on:

Sorry if we didn’t put a high priority to this bug and fix, but generally we focus our time in more general bugs/problems/crashes that are being experienced by larger audiences. Generally scripting API is not the most priority stuff (and the API was still usable as it was, even without this fix).

Whether or not the scripting API should be a priority or not is highly debatable when considering a lot of those “larger audiences” are also using user-created scripts to extend Aseprite all the time. Even my scripts, which I don’t promote in the community for multiple reasons, still get thousands of downloads from users in that “large audience.”

Still though, I’m not here to debate that, because I don’t care anymore, especially after a whole year. I abandoned the add-on I was making a long time ago, because I never heard anything back, not even a courtesy “we will look into it later, thanks” reply. I just wanted to highlight that maybe a whole year to implement a simple fix that could potentially affect “larger audiences”, or at least giving even just one acknowledgement of the issue, is not a good thing, and maybe it should be more of a priority.

In any case, again, I don’t care anymore. I already gave up on this around October of last year.

1 Like