can we finally get C3 to save and load our layer visibility and lock settings?

Post reply
Not favoritedFavorited Favorited 1 favourites
  • 6 posts
From the Asset Store
Custom Loading Icons
$3 USD
Custom Loading Icons to Enhance Your Loading Screens
Cosmic Lotus's avatar
Cosmic Lotus

  • can we finally get C3 to save and load our layer visibility and lock settings, in a future update? it's a basic feature that's been lacking for years, and it makes a big difference in productivity. the funny thing is that sometimes some layouts DO save these settings, but others don't. so the better question may even be: what determines when a layout saves those settings or not? how do i make it be that every layout always does? thanks

  • Construct does save layer visibility and lock settings. I just tried it and it does work as I thought.

  • The confusion likely comes from the fact that .uistate files are only updated when the project is saved, and possibly only for layouts & event sheets that have been modified since the last save (but I'm not certain on that.)

    I made a feature request to resolve this ages ago but it didn't gain much traction.

    Ashley It maybe sounds inefficient but ensuring all .uistate files are updated upon saving and also when closing a project or Construct itself would resolve this potential issue and is in line with expected behavior I think - having to make actual changes to the relevant layouts & event sheets when doing "clean up" should not be required.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Writing to every .uistate.json risks causing saves to progressively slow down the larger your project gets. Construct currently only writes to files that have actually been modified, which means save performance scales well - you can have an arbitrarily large project and saving will tend to only affect a small number of files. Saving every file every time means if you have 1000 layouts, Construct will write at least 1000 files every time you press save. If we do that someone will probably then turn up and say "your latest update made Construct saves much slower for me".

  • Sounds like the ideal solution is to treat anything that would affect the corresponding .uistate file as a project change to be saved then. As it stands there is a bit of a discrepancy between project files and .uistate files, despite both utilizing the save function to update.

    Alternatively all "editor changes" flag the corresponding .uistate files to be updated when the project closes, decoupling it from the save function entirely.

  • Sounds like the ideal solution is to treat anything that would affect the corresponding .uistate file as a project change to be saved then.

    This means enabling the save button if you change things that only affect the UI, like reordering tabs. I don't think it's typical for software to do that - usually the save button is only enabled for meaningful content changes. As an example of that, if you use source control and ignore .uistate.json files (which is recommended), then such changes will enable the save button, and subsequently saving will cause no change to the project files on source control. So overall I think that is also a kind of confusing or unusual approach to take.

Post reply
  • 6 posts
Index icon Return to board index
Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)