Function names, layer names, layout names.. breaking changes

So I was curious, why are different ways for storing names in construct 2 used?

Variables can be named and referred to by that name. You can change the name and the change is reflected across the project.

Layouts are the same - you can only reference them by name and changing the name changes the project references to that layout.

But groups, function names, and layer names... When referencing these things you get a handy autofill (which didn't used to exist for some things) but nonetheless, if you change anything about these guys it will not change your original references to them... you'll have to go through the project and make sure the changes are reflected when you call them.

Its no big deal... I think coming up with group and function names and sticking to those names is a simple organizational exercise with a smidgen of foresight... But layers are hard to name and keep in the same order for the duration of the project. I always find myself realizing that I would like an extra layer inbetween these other layers, or something.

Since you can refer to layers by name, it doesn't matter for actions, but expressions refer to the layer by number! One could set up a system of constants and just refer to the constant, but that seems like the sort of thing construct should already be handling. Its a pain to be half way through a project and realize you need to completely re arrange layers to support some fancy blending mode you realized you couldn't live without. Then you have to go back and manually change all layer expressions

Am I missing something?

You can use the layer name in expressions instead of the index. So something like LayerOpacity("Layer 1") would work. You can also do the same thing with imagepoints, either use an index or the name.

You can use the layer name in expressions instead of the index. So something like LayerOpacity("Layer 1") would work. You can also do the same thing with imagepoints, either use an index or the name.

Right, But then those references are prone to being broken if you change the name right? They also don't auto complete unless I am mistaken. I'm not saying its an un winnable situation, just slightly sub optimal. I never notice it until I get into heavy layer usage, which typically I try to keep to a minimum and in locations I can easily change later if I have to reorganize.

True, and no they don't auto complete from expressions. If you change it I guess the easiest current way would be to search for the old name and then replace every occurrence with the new name. Another idea I've seen others use is make a constant global that they set to the layer name, then whenever referencing the layer with events just use the constant. That way if you rename the layer you only have to change the name in the constant, and in turn you could rename the constant.

I guess it's a missing feature. But because you can use any dynamic expression, it can't guarantee that 100% of references will be updated. For example if you reference

"Layer" & Sprite.LayerNumber

then rename "Layer0" to "Main0", it can't update the reference to "Layer" there.

I guess it's a missing feature. But because you can use any dynamic expression, it can't guarantee that 100% of references will be updated. For example if you reference

"Layer" & Sprite.LayerNumber

then rename "Layer0" to "Main0", it can't update the reference to "Layer" there.

Oh, I didn't even think to a dynamic expression like that!

I was thinking of using constants... probably tied to a global object... I sort of tend to avoid global variables, it doesn't work with me or how I work doesn't play well with them... you know what I mean?

Yeah, I think some people use that as a workaround. If you put in a global constant name then if you rename the global constant it updates everywhere.