How do I, if there is a way to, keep my layers' settings consistent thru layouts?

Imo the most robust and flexible way would be fairly similar to how objectType templates work: you can set something as a template layer and you can set another layer as a replica of it (could just be that any aditional layer with the same name is a replica), then on that replica you can disable copying of specific properties, effects and for a more completete came maybe we could even choose if sub-layers and content should be copied (in that case it could supersede global layers).

The exact meaning of "first layer with the name" scares me in the context of existing projects if they go with that.

yea, that wasn't the best suggestion. The template layer should be the layer you set "semi-global" on, similar to global layer, with a context menu option "open original template layer layout"

If project-wide changes based solely on the layer name with no ability to select specific layouts was acceptable, that would be a quicker and easier update and therefore more likely and possible to come sooner

That sounds pretty good? Would that work for you Tokinsom?

Adding the notion of a template layer is massively complex, on the surface it seems straight forward, but I can already foresee it being an endless source of bugs.

Mainly because it would need to "just work" with regular layers, global layers, sub layers, all their combinations and an indefinite level of nesting.

I don't even want to think about the kind of setups that could be made, like a template global layer which is also a sub layer of another template, or something to that effect.

yea it can get complex, though a layer can not be a template/replica and global layer at the same time imo.

They are just normal layers, though. The only difference is they inherit their properties and order from a master layer elsewhere.

These "complex scenarios" don't exist, the request is not beyond anything Construct already does.

I almost feel like we're talking about different things here?

Our feature request guidelines have a section titled "Please do not try to claim your idea is simple or easy to do". Even much simpler features can end up proving surprisingly difficult. There are parts of Construct that look lovely and simple and straightforward, but internally it is dealing with a great deal of complexity. That's really Construct's job - it often does a lot of heavy lifting internally to provide a simple and straightforward interface. Even we struggle to work out what will be easy and what will be hard, and on the outside it is even harder to properly understand what a feature would entail. Claiming something is easy to do is not helpful and will probably just make people get more frustrated.

We don't know for sure how easy something will be until we do it, customers use the finished version, and decide it is suitable. Before that point we have to rely on our many years experience developing a complex piece of software, using our familiarity with the codebase, to make an educated guess what it would be like to develop. On this I must agree with DiegoM - template layers sounds like a nightmare to implement. The "sort-of-like-a-normal-layer-but-not-quite" approach actually causes no end of difficulty and complications, as it violates long-standing assumptions in thousands of lines of code distributed across the codebase, which is more or less the same reason why global layers proved to be a nightmare. It probably gets even worse if you want things like a template layer to be an override of a global layer - that sounds like the kind of thing that ends up so messy and complicated it ends in development hell and we basically never get it right, then users end up abandoning the feature because it never works properly. So I think there's a real risk your dream of a nice simple template layers feature actually turns in to a nightmare.

Batch changes to a project sounds a lot easier though. It basically amounts to repeating a manual operation across multiple layouts. It would be much more straightforward to implement and is much more likely to just work in a predictable way. So this is one of the times where our experience developing Construct is leading us to suggest a different feature that should still do the job, but is much easier for us to develop and support, and more likely to actually turn out to be a success.

Our feature request guidelines have a section titled "Please do not try to claim your idea is simple or easy to do"

I do know you have that in the guidelines and I completely agree with it. That is why I was pretty much already apologizing for saying that. But I said it because, as Tokinsom also stated, maybe you just weren't understanding what we wanted. But yeah, sorry.

It probably gets even worse if you want things like a template layer to be an override of a global layer

As we've stated before, layers wouldn't be global and a template/replica at the same time, it makes no sense.

Please do realize still that something to solve this is needed, as it makes it a nightmare to develop any game with multiple layouts as multiple levels or anything like that, which seems to be the intended workflow.

The batch changes idea I've already given my opinion on, but of course, and fortunately, I'm not the only user of Construct.

One quick suggestion:

Why not allow us to add layer effects at runtime? This would be a lot easier, I've done engine hacks in the past that let me do it, and it would completely skip the whole problem if we can just setup all the layers at runtime manually.

Right now what makes this impossible is:

- we cant change what effects are on a layer at runtime (i mean add/remove from dynamic/static layer, not just enable/disable effects)

- a few of the layer params (namely 3D params) are still impossible to change at runtime

This IMO would actually be the simplest smallest possible version of that feature because then you could just write a few events that handle it at runtime based on layer name for litterally anything you might need, and then we can create the sprites on them either using recreate from layout or using templates.

Ok so if UI is not allowed to be changed, how can we solve the problem of making batch changes to layer ordering?

It sounds like that's also what they want, not just syncing layer properties.

in theory if you follow a good naming convention, only layers that need to be synced would share a name, and so you could say "for every layout that has a layer named X and a layer named Y, move layer X to a given position relative to layer Y"

Same would go for renaming, removing, adding or editing.

This would be kind of a pain to set up the first time for existing projects where the naming convention wasnt made with this feature in mind, but for everything else in the future you could in theory do it that way.

I also agree that layer templates sound like the best way to design the feature in an ideal world, but I would rather have a simple batch edit feature than an over engineered half broken new layer system that takes 4 years to get right.