Grid for New Documents

Hello,

Aseprite doesn’t remember my choice for “Not visible Grid” in new documents :frowning:

It usually checks that checkbox again and again, no matter how many times I uncheck it (it does it usually when I restart the program). Its really frustrating ^^U

I’m on Windows 7 64-bits, and my aseprite version is: imagen

1 Like

That’s strange, I’m testing here (but on macOS) and it does work :thinking: I’ll give a try next week on Windows. At the moment, could you please check your aseprite.ini file inside your configuration folder and see if you have this [show] section with grid = false:

[show]
grid = false

And that you don’t have:

[grid]
visible = true

:point_up_2: if you have that one, remove the visible = true line.

1 Like

Thanks for the help! :slight_smile:

I have checked aseprite.ini inside of my AppData /Roaming/Aseprite but I didn’t have

[grid]
visible = true

I had only the other two lines.

I’m thinking that maybe the problem could be that I have several Aseprites installed, is that possible? (in the past I had to install several versions at the same time, because some of the old versions didn’t have some bugs that the actual ones had).

I have (at least) these versions installed:

  • Aseprite_v1.1.13
  • Aseprite_v1.2.0-beta12
  • Aseprite_v1.2.9-x64
  • Aseprite_v1.2.10-beta4-x64
  • The present Steam beta version (v1.2.12.1-x64 now)

Still, is very strange, because (to my knowledge at least) I always open the Steam version (using a shortcut icon on my taskbar, so I don’t need to open Steam each time I want to use Aseprite), so the preferences file should be located at the same place, isn’t that right?

Are there other places where the preferences file could be located? If so please tell me and I’ll try to search & delete them, just in case.

Edit: Just to clarify, the problem happens sometimes, I still haven’t been able to locate the exact moments, and right now I couldn’t replicate the problem ^^U

If you are using portable versions of Aseprite, there might be an aseprite.ini file in the same location the portable aseprite.exe file is. You should check those aseprite.ini file too (if you remove the aseprite.ini file, it will use the one from AppData).

It might be related to the different versions. I don’t remember when I changed from [grid] visible to [show] grid, but if newer versions find [grid] visible=true then it will migrate the setting to [show] grid=true and remove the [grid] visible. But [grid] visible=true should appear only if you set the property from an old version.

2 Likes

Thank you very much, I’ll check those .ini files :slight_smile:

I’ve deleted all the portable aseprites and its .ini files, but the grid appeared again ^^U

I’m using now only the last Steam version (v1.2.12.1-x64), is possible that the bug is caused by the file “pref.xml”?

I’ve found the following (suspicious) line:

  <option id="grid" type="bool" default="false" migrate="grid.visible" />

I’ll try to change it to something like:

  <option id="grid" type="bool" default="false" migrate="grid.invisible" />

Or:

  <option id="grid" type="bool" default="false" migrate="grid.transparent" />

Or something else. Please tell me if you know the correct one XD

The pref.xml file is not used on runtime so it doesn’t affect the execution if you modify those values there.

I’m not sure what could be happening, I’ll take note about it if I can reproduce it just in case.

1 Like

I just want to add a +1 to this on windows. I’m not sure what causes it but this setting appears to toggle itself on regularly. I never turn it on myself, yet have made a habit of “ctrl+h” whenever I open documents to get rid of the grid.

It’s not every time, but often enough, and will persist for multiple documents that I open in the same session.

Currently using the steam version of Aseprite, latest build with beta enabled. I remember this issue also existing in previous versions of the app.

2 Likes

I might have found something related to this bug.

tl;dr version: In Aseprite v1.2.16 we’ll simplify the behavior of default docs settings: if there exists a .ini file storing the preferences of a sprite (in the preferences folder / files/.ini location), the defaults settings for that sprite are not modified.

Long version: If the global setting for the visible grid are changed (e.g. View > Show > Grid menu option is selected when there is no document opened), then that change could set the default of the other sprites (even when the sprites were already opened in the past so they have their own preferences set). This is more visible in the File > Export Sprite Sheet preferences, e.g. if we create a new sprite, export a sprite sheet from it with the “Trim” option checked, that option is saved as the default option for future files, but if we open an old file that we’ve exported but it doesn’t specify the “trim” option (not false nor true), the new default will be copied, so the trim option will be enabled for a sprite that was exported in the past with the trim option unchecked.

This was found with a re-design of the Export Sprite Sheet dialog and thanks to @KashouC for reporting the bug :pray: and I guess it’s related to this bug too.

Commit fixing this (supposedly): https://github.com/aseprite/aseprite/commit/002abc92452d89dabe601af0bfedf81e3e2ab0fd

2 Likes

So the fix in v1.2.16 caused more problems. Now I’ve fixed these problems (to be released in v1.2.16.3) but I might have found the cause of the original issue in this thread.

I’ve created a test case, where it shows a possible problem (this line):

  1. Imagine that we set the default grid to 10x10
  2. We create a new document, show the grid, and save it as .png (with the default grid settings, 10x10)
  3. The we close the document and change the default grid to 64x64
  4. After we re-open the sprite from step 2, should we see a grid of 10x10 or 64x64?

Answer: As we never specified the grid size, the saved preferences for the given sprite will not contain the grid size (now .aseprite format can contain the grid size, but imagine that we’ve saved the sprite in a .png file, so this information was lost), the sprite is expected to use the default grid size. So if we change the default grid size, after re-opening the sprite we will see the new grid size (and not the grid size visible when the sprie was saved).

This situation is a little complex, but maybe there are some parameters that should be saved “as a group”. For example: the grid or the background settings. If you change one parameter that makes the whole thing (e.g. the grid) visible in certain way, I think all values should be saved in the preferences (in this case, if we make the grid visible for a specific sprite, we should save all grid parameters, size and color, etc. for that sprite, not only the changed values; the same should be true for the background configuration, changing just one parameter should save all parameters of the background).

What do you think about this?

2 Likes

I think storing Aseprite specific settings should, or could, be limited to the .aseprite file format. (project file vs image file)

And yeah, I’m not 100% sure what you mean, or with “as a group” I think, but I do think if we’re working with an .aseprite file settings should be saved. Grid size, background color, background grid size, what have you. Personally I don’t feel like it’s necessary to store all that kind of data for .pngs as they are generally the end product used for importing somewhere instead of something you actually work on. At least from my perspective. I also think default settings should be saved to the file right away and not just after they’re altered. Because otherwise, what if you have it set to what you thought it should be as default, then change the default later, and come back and then its now wrong in your old file because it didn’t get saved?

Hope it makes sense.

2 Likes

Hi! :smiley:

I’ve been thinking about this for the last couple of days, and I’ve rewritten this several times so I hope it makes sense XD

One option would be as @dacap said, saving certain small groups of parameters related to a functionality (for example, the “grid group” would save grid size, grid offset, snap to grid and grid visibility), and a second option could be using all the workspace configurations as a whole (although to tell you the truth I’m not sure of which parameters should be grouped here, and maybe it’s more complicated for users and also for development).

Now I’ll try to explain what I think that would be optimal behaviour, using a group of parameters, for “Grid Configuration”:

  • The Grid Configuration (from now GC for short) would save all relevant grid parameters (grid size, grid offset, snap to grid and grid visibility).
  • There would be a default GC, and also a custom GC for files saved within the file itself.
  • The custom GC would only be saved in .ase or .aseprite files. This setting should be saved when saving the file. If we have modified any parameters and try to close the file without saving, a warning will be displayed asking “saving changes to the sprite before closing?”.
  • Common files (type .png) would not have a custom GC, so they would use the GC by default.
  • There should be two options for saving the default GC: Manually or automatically. Users could their preferred one by checking or unchecking a box in preferences.
  1. Manual mode: To save the GC by default, after making the changes you would have to press a button inside “Edit> Preferences>SomePlace” or something like that. The user would probably also have to give the option of “load default GC” (I would use this manual mode for sure! ^_^)
  2. Automatic mode: The default GC would be saved automatically when changing any of those parameters.

What do you think? :slight_smile: