Global Layers and Global Objects

I've got bitten by a behaviour related to Global Layers and Global Objects and I wanted to open a discussion about understanding how these two work, especially in conjunction with each other.

My case is about making a GUI. In its simplest form, the GUI has a 'frame' and has 'buttons'. The 'buttons' are Pinned to the 'frame' and the 'frame' animates up and down; the 'buttons' being pinned, follow the 'frame'.

As recommended by the manual for GUIs, I make my GUI layer Global, and set things like Parallax, Transparency, etc, so that the layer settings carry itself to other layouts. The problem that arose, however, was that Objects inside the Layer were getting destroyed, and then recreated again. And that's a problem because all the Pinning setup I did at the start of the layout is broken because the Pinned UIDs all changed.

Then I tried making the Objects Global, too. But that wasn't correct either, because the objects started doubling up. The Global Layer kept on creating its objects, assuming that the objects that was on that layer was going to be destroyed, but they weren't, because they were Global.

So I switched off Global Layers altogether and manage everything as Global Objects.

However, this behaviour is a bit counter-intuitive for one reason. If Global Layers were going to recreate the Objects on the new layout, why destroy them in the first place?

(A.) I think it would have been better to separate the 2 features of propagating layer settings separate vs 'propagating' objects through layouts. In this way it is apparent to the user what is being 'persisted' in a Global Layer.

(B.) Like I said above, if Global Layers were intended to retain Objects then it is expected that those actual objects are considered global, in the same sense that Global Objects are global; they are not destroyed, and whatever parametric options attached to them are unchanged.

I could have lived without (B), but because of (A) Global Layers have suddenly become unworkable; I can't even use them for unifying Layer settings because the Global Layer wants to keep on recreating its objects. I can't turn off that behaviour.

However, if I'm missing something here, I'd appreciate any thoughts.

Thanks.

[quote:2th7iv4l]If a layer's Global property is set to Yes, then every layer in the project with the same name is overridden by that layer. The initial objects, as well as its properties, are used instead of the other layer's own content and properties. Then changes can be made once to the original global layer, and the changes will be applied project-wide.

The way I read it, a global layer is like an "include" for the layout editor, analogous to "include" for event sheets. It allows you to make layout editor changes for a specific layer that will be reflected everywhere in the project where the layer is included.

This is in contrast to the "global" object property, which simply prevents objects from being destroyed between layouts.

I can see how the naming can cause confusion, their function is significantly different.

If you are using events to set up your GUI global layer, you can have those events included in other layouts' event sheets as well. Generally speaking you shouldn't be referring to a specific UID where it would matter if the UID changes, but without seeing your specific setup I am unable to give any advice on how to work around this.

Thanks for replying, oosyrag

I can see how the naming can cause confusion, their function is significantly different.

If you are using events to set up your GUI global layer, you can have those events included in other layouts' event sheets as well.

I understand that their function is different as a matter-of-fact. However, I am emphasizing that though Global Layers have a generic functionality/behaviour, they were intended to solve a specific problem with GUIs. But the destruction of objects is not 'logical' from that respect of GUIs. Object destruction significantly narrows down the choices you can have in creating GUIs and using Global Layers to do so.

For example, if we were storing variables in these GUI items, you will lose them. You need to store values in a persistent object (e.g. Dictionary). Though this is a trivial example, the rationale is clear: Global Layers, meant to address the persistent GUI workflow problem, need to persist its data beyond the Global Layer settings or the mere existence of its objects. It needs to also retain the integrity of the data of those objects.

[quote:1eu4kl8y]

Generally speaking you shouldn't be referring to a specific UID where it would matter if the UID changes, but without seeing your specific setup I am unable to give any advice on how to work around this.

The best example is what I described in my first post: a Pin behaviour needs a UID, and that's behaviour-specific; nothing I can do about it. If my 'parent' is destroyed, the Pin is nullified. I need to pin again. By pinning again, I set up my GUI in the layout I just jumped into, which makes setting it up in a separate GUI layout pointless.

(Even if Global Layers recreated the variable data from the objects it destroyed, the Pin behaviour needs to re-associate the Pinned UID with the new object UID. And that route is buggy route; so why destroy objects in the first place?)

Therefore, it seems that the workflow/dataflow logic behind Global Layers is not designed thoroughly enough, unless there was a specific reason why objects had to be discarded.

My current setup has changed. I have no more Global Layers as its logic introduces more opportunities for inconsistent data. Global Objects are easier to manage on their own and I'm rolling with that. Because of this issue, my solution is simply limiting the number of layouts I have, so setting layer properties is workable.

(When the C3 Editor SDK was announced the first time, I really hoped it was an Editor SDK in the likes of Unity. It would have offloaded so many run-time issues by automating stuff in the Editor. Alas...)

Object's destruction is linked to how layouts are working.

Pin behavior doesn't need a UID. An expression of its do provide the UID of the object it is pinned to.

Otherwise, it absolutely does not need a UID to work.

If you did use hard-coded UID to set your pin configuration on start of layout this might be the whole reason you are having troubles in your project.

Add an instance variable to your objects, if they are reused elsewhere where they need to not be pinned, so that you will pick only the appropriate instances to pin.

Again, it would be easier to help out if you did provide the actual content of your project to point out where you might have gone wrong.

In the absolute, I understand your discussion and the point you are trying to make, but you are discussing it for a software that won't have new features at this time.

Also, the situation should easily be worked around as it is.

I invite you to open this discussion for Construct 3 if you feel like it.

Example capx of pinning objects on global layer, without using UID

Hi Kyatric thanks for taking the time to set-up a capx.

Object's destruction is linked to how layouts are working.

In the absolute, I understand your discussion and the point you are trying to make, but you are discussing it for a software that won't have new features at this time.

Yes, I understand that. I suppose it's a sort of a catharsis for me.

[quote:v045ys3w]

Pin behavior doesn't need a UID. An expression of its do provide the UID of the object it is pinned to.

Otherwise, it absolutely does not need a UID to work.

Add an instance variable to your objects, if they are reused elsewhere where they need to not be pinned, so that you will pick only the appropriate instances to pin.

The important thing to note about your capx is that you run the Pin operation (in esUI) every time you go to a new Layout, which you must do if you want the Pinning effect to remain. That is what I wanted to point out: that the Pin operation requires to be repeated, which is not logical in a workflow sense. However, I also understand that you are demonstrating a workaround for me, and I appreciate that very much. Thanks.

[quote:v045ys3w]Again, it would be easier to help out if you did provide the actual content of your project to point out where you might have gone wrong.

I really appreciate the helpfulness, however my content is a bit complex (and huge). I have used the Global Objets workaround because there is so much initialisation that's going on both external data and computed data that initialising the variables and relationships (ie Pins and others) everytime I change layout becomes too crazy and convoluted.

This post was partly just a rant. But like you said, there's no point, because C2 won't get that sort of change.

[quote:v045ys3w]I invite you to open this discussion for Construct 3 if you feel like it.

Might do; could do some good...

The important thing to note about your capx is that you run the Pin operation (in esUI) every time you go to a new Layout, which you must do if you want the Pinning effect to remain. That is what I wanted to point out: that the Pin operation requires to be repeated, which is not logical in a workflow sense. However, I also understand that you are demonstrating a workaround for me, and I appreciate that very much. Thanks.

In the way Construct is working, it does make sense.

The global layer is global in the sense that any modification you make to it will happen over all layouts you use it in, without having to go by yourself modify each of said-layers in each possible layouts in your project.

But again, keeping in mind that objects are destroyed between layouts (if they are not set to be global), initialising in each layouts does make sense from Construct's perspective.

In Construct, you need to do some initialisation on every layout.

It also allows you to make any modification for special case (imagine in Layout 3 you would want a different animation frame to display. Or to change some text, with this, you can and are not blocked to an UI you have set once and cannot modify afterward).

On the other hand, I understand also how you would like to set your UI once and not think about it anymore.

I'm not sure how to set it "easier" considering Construct is an engine that has to cover a lot of possibilities and minds at once.

TBH though, with included event sheets, it is working pretty OK.

If you add a new layout, all you need to do is add the proper layer and include the event sheet, and your UI is done for this new layout.

In the way Construct is working, it does make sense.

Sure, I understand, but I think it is a question of benefit; which is more beneficial/advantageous.

[quote:24rzefc8] It also allows you to make any modification for special case (imagine in Layout 3 you would want a different animation frame to display. Or to change some text, with this, you can and are not blocked to an UI you have set once and cannot modify afterward).

In the case of Layout 3: if Global Layers could persist (not destroy) objects, then the changes I would like to do for GUI elements will be executed under a Layer 3 event sheet. It's an 'additive effect' of applying changes to existing objects rather than recreating objects from scratch and then applying attributes again. The most clear and efficient place to make a change is the place where the change should happen (in the event sheet under the Layout that is executing it).

[quote:24rzefc8]I'm not sure how to set it "easier" considering Construct is an engine that has to cover a lot of possibilities and minds at once.

Sure, but I'm also a programmer, so I'm speaking more about how data being destroyed and how that even makes sense on an application design level.

Global Layers can be discrete entities in themselves, only concerned with the settings of layers. If Global Layers did not do anything with the objects at all then it would be fine. For example, if a Global Layer contains non-Global objects, then those objects will be destroyed, which is fine, because that's expected. But, it should not try to recreate it. Why? Because it allows me to be specific with what I want to be Global Objects. If I make them Global Objects, the Global Layer only cares about it being a layer, so it applies the layer setting but nothing else. So the result is I have a Global Layer with correct settings which contains Global Objects; all my data is preserved.

But what is currently happening is that Global Layer insists on creating objects that was put under it. If I set my objects to Global, the Global Layer will duplicate it nevertheless.

That's what I mean by 'application design'; the data handling is not neat or logical. I'm just discussing this as a matter of discussion only, because, like I said, I do 'application design', and I guess I'm still ranting.

[quote:24rzefc8]TBH though, with included event sheets, it is working pretty OK.

If you add a new layout, all you need to do is add the proper layer and include the event sheet, and your UI is done for this new layout.

Yes, I know the technique is sound and is elegant. But to be fair, I have tried that setup in other projects, but the one I'm doing is a different use-case with a lot of external data and moving parts. It was just too much data-man-handling to work.