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.

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.

You can load a specific release from the releases page. If you browse to editor.construct.com it will always serve the latest stable release.

Right but if you "Install C3 as a desktop app" as detailed in the manual, this becomes a problem because it forces the latest version. It asks me once, then ignores my answer and automatically updates upon reloading.

Sure we could install a dedicated version URL but updating that might be a pain? I'd have to play around with it. I swore uninstalling wiped the UI, installed plugins, etc. but this latest time there was a prompt asking if I want to delete that or not.

When a new version of C3 is available, it asks if I want to update to it. If I say no, the popup disappears and I stay on my current version.

However, upon reloading C3, it automatically updates to the latest version and asks if I want to see the release notes.

This is very problematic for my team, as C3 updates can make some pretty major changes internally that affect files in source control, etc.

Switching to the LTS is an option we will probably do, but, you know, we like updates too, just when we're ready for them!

(None of us use C3 inside the browser, so we can't just stick to a version URL. We "install" editor.construct.net which should recommend the latest stable but not force users to it!)

Hey Ashley and DiegoM. I would like to discuss a long-standing issue I've had with Construct, and hope to resolve once and for all. In all my time using Construct engines the only solution I've found to this is meticulous planning, brute force, or utilizing an external level editor, but I think it's worth seeing how it can be addressed internally instead.

Scenario

Say you have a level-based game with a ton of levels. Demonoire is a good example, although a full-scale game will have magnitudes more!

Each level is a layout.

Each layout has a set of essential layers: background, tiles, objects, foreground, etc.

...But now you want to add, delete, move, or rename one or more layers.

Existing Solution

Your only option is to do this, by hand, for each level. Every single of them. Every time you want to refactor your layers in some way. Potentially hundreds or thousands of manual operations.

Close-But-Not Solutions

Global Layers are a way of solving a similar issue, where you want a static set of objects to appear in multiple layouts, like an HUD or Pause Menu. They do not, however, serve as a template to organize, manage, or refactor layers on a grand scale.

Actual Solutions

Recently, the layers bar was updated to display a global layer's sub layers, but they are grayed-out.

Funnily enough, allowing us to place objects in those grayed-out layers, while leaving the master layers empty, would be a legitimate solution here.

With this I'd be able to establish a global "LEVEL" layer, with background/tiles/objects/foreground as sublayers. Simply adding this "LEVEL" layer to each of my layouts gives me my template, and it can be easily refactored by adjusting the master layers.

Of course, I understand that the layers are grayed-out to prevent unexpected behaviors. I only present this as one possible solution that utilizes the existing global layer system.

Soooo maybe we can either...

A) Keep everything as it is but give global sublayers an option to not be grayed-out in other layouts. An "only do this if you know why" kind of thing.

B) Introduce an alternate type of global layer...perhaps a "Template Layer" that functions like a global layer but does NOT inherit the objects from the master layer, and whose sublayers are not grayed-out in other layouts.

Ideally we'd still be able to, in any given layout, add a unique layer into this "template." This way you can have your basic level template but allow special cases where needed.

Final Thoughts

Of course there are maybe other solutions, I'm just trying to think within the box of existing systems. As noted, Global Layers are very close but serve a different purpose. I am not trying to inherit objects here, I just want a sort of Layer Template/Set that I can easily manage and refactor on a grand scale, saving me literal days of arduous work in some cases. Thanks for reading and I look forward to your response!

Listing all templates is also an interesting idea, but I think it's a slightly different use case. Should all those templates be in a separate section of the Project Bar? If so, there's still the problem of what happens when you drag in a new instance from the Object Types folder. Should templates appear as child items of object types in the Project Bar? If so presumably you can still drag from the object type itself, and the same problem comes up. So while I think that may well be worthwhile as well, it's probably best thought of as a separate addition.

Templates should probably have their own root folder as they could also contain hierarchies comprised of numerous objects that may already be organized in a variety of folders, or object permutations that are best organized in their own way. Also, personally, I don't want a hired level designer for example rummaging through standalone objects—they would almost exclusively use the much safer and curated templates folder for all available object permutations with brown highlights alerting me of any values they change. Of course this varies with dev teams but that's how I would do it.

I figured you'd want to leave the "non template default instance" alone in light of this solution. Yes it is a quirk, but the template folder is a way of solving it with templates as you wanted. The other template-involved method you suggested strikes me as a major case of crossing wires, especially with the likelihood of an upcoming templates folder. Perhaps I'm just not fully understanding it but it sounds confusing and doesn't actually address the issue because at the end of the day it's not actually changing the default instance, it's just creating a template called "default" and making it what is pulled from the project bar. This, again, will be extra confusing with actual templates in the project bar.

So then I would still argue that the the instance that is pulled from the property bar object type can simply be determined via a right-click menu option on the instance you want. Call it a "Root/Prime/First/Initial/Editor" instance or something instead, I don't know. Solves the issue right at the core though without bloat or new workflows or involving templates at all, and lets the user change it on the fly, to boot.

Ashley skymen

Thank you both for your insights. I'm glad we can have this discussion and I think we're on the right track.

After considerable thought, I think Skymen hit the nail on the head and everybody wins with his proposition.

None of this noise about default instances matters at all if we can just establish templates, default or otherwise, and have them all in neatly organized folders in the project bar.

-It is hands down the most intuitive, safest, and versatile option.

-It does not change or break anything for existing projects.

-It does not interfere with anyone's usual workflow, they can decide if they want to use templates from the project bar or not.

-There is no bloat or "hidden" functionality to it.

-Has the added benefit of pulling hierarchies from the project bar. Essentially prefabs as Skymen noted.

I'm fairly positive this is already a desired feature for many users, and it so happens to completely solve my longstanding "default instance" issue as well—in a very different way than I had expected—but one that is in fact actually better!

What do you think?

> B) Make it so new instances pulled from the project bar automatically become replicas of the "default" template if it exists.

This design makes it a bit of a hidden feature, and hard-codes an English string which isn't great for non-English users. What about a property to choose the default template name used for new instances? This seems like a good solution as templates are the feature intended to be used for determining initial properties.

I agree that "B" is not ideal, and would still much prefer "A". I think the feature you mention here is a welcome addition to the template/replica system, but it is not a good solution for this particular issue. Please let me explain:

My issue with your proposed solution is every single instance pulled from the project bar would then need to be manually set as a replica—an error-prone or easily forgotten step that my level designers should not be expected to do. I don't know that there is a suitable way to make that process automatic.

Furthermore, it forces object instances to become part of the template/replica system which, yes, gives a similar result, but is a completely unnecessary workaround!

Look, the "Default Instance" is already a real thing that Construct does automatically—It is not a new thing or new feature that I want. The problem is that it's ambiguous, most people aren't even aware of it, they have no control over it, and it's not explained in the manual. I am merely asking for a way to choose which instance it is.

As such, I find it hard to understand any reasonings against a very simple and intuitive "Make Default Instance" button in the editor category (or in the right-click menu), with a tooltip like "Makes this the default instance", and a manual entry describing—at long last—that the default instance is the one that all new instances get their initial properties from. I understand that there is a little bit of overlap with the template/replica system, but that is simply not what is being discussed here and it's fair to trust Construct users to discern the difference.

(For what it's worth, personally I think the template/replica system should be baked in to all objects, with the "default" template being the first instance, and the "default" replica being all instances that follow. This way we can easily determine and change the default instance, and automatically reap the benefits of the whole template/replica system. But that probably ain't happening!)

dop2000 Yes I agree the ability to copy JSON as plain text should remain. I propose this as an additional feature.

I didn't mean it was literally read-only! Just that its form in the debugger isn't exactly suitable for modification. I have edited the OP to prevent confusion.