Yeah, I'd rather not post the entire project file out in the open. Sounds like it's not necessary anymore anyway, but if you still want to double-check with the actual capx, let me know and I'll PM you a link.

[quote:1nnqxpn5]It's by design that if you set a layer to global, it overrides the objects on all the other layers with its own content. However due to the architecture of the editor the overridden layers can't be displayed on the other layouts, so their content will seem to disappear. This is still by design at the moment.

So that means the global setting wipes any objects assigned to same-name layers on other layouts as long as it's in effect? Makes sense that the runtime throws an error then.

[quote:1nnqxpn5]However the OP alludes to a runtime error but does not specify how that occurs. Can you describe some more about that? Can you still get it to happen even if you pretend the editor doesn't allow you to modify a layer which has been overridden?

If I try to set layers to global on the 'startup' layout in my own project I get this error message during preview:

'Savestate_Lab' is a global object I use to keep track of some variables during the first section of the game. It's meant to minimize savestate size and I destroy it when outside that first section. I also destroy and re-create it each time the game is restarted, including on first-time run. The 'Savestate_Lab' object itself exists on the first layout that gets switched to after the 'startup' layout (on one of the layers that get over-ridden). And the events below happen on the 'startup' layout right before switching.

[quote:2lennoso]However, I can't see a family of four sitting in their living room looking like the borg

lol

Hello.

As it is, sprite animation frames are compiled on export into optimized sprite sheets which is great for saving video memory. It's very nice to be able to import individual frames and just let C2 handle the arranging into sprite sheets later. But graphics change and revisions tend to get made to sprites during development. This can range from simple color tweaks to complete replacements of sprite gfx.

You might for instance want to create a character B that shares most behaviours/animations with character A but has a different visual look, so you copy the sprite with animations and all and replace the graphics while keeping width/height and image points for the animation itself. Or you're just not happy with the colors you've used for character A's sprite and want to tweak them a bit. In those cases, it can get very time-consuming and tedious to go through all the animations in the image editor and delete-copy-paste sprite frames one-by-one, especially when you have frames in the hundreds or even more!

If we had a way to compile sprite sheets in the editor and then access those sprite sheets directly from within the editor, large-scale changes to graphics could be made in no time at all compared to changing every frame individually. Need to tweak colors? Okay, just copy the entire sprite sheet from C2 into your graphics package of choice, make the color adjustments and paste it back into C2. Same with updating/replacing sprite frames, it would be a bit more work than just color/contrast-type tweaks of course but being able to access entire sprite sheets at a time would still be *way* faster than changing each frame separately.

I created a couple of mock-ups below to illustrate what I mean. I imagined the editor to reference the sprite sheet internally if one exists and just do what it does now if a sprite sheet hasn't been compiled yet.

Image Editor - Regular view:

Image Editor: Sprite Sheet view:

I understand this could mean a pretty major re-working of how the C2 editor works internally when it comes to sprite arrangement and the whatnot, but it would be a great time-saver for artists who need to make cosmetic sprite changes to entire sets of animation frames.

[quote:2k8p4xsd]Ashley hates these as they can't be reproduced.

I bet! I would too.

I also get this when shutting down C2 right after following the steps in my previous post:

---------------------------

Construct 2 Check failure

---------------------------

Check failure! This is probably a bug:

Object texture leak: a texture is still loaded when cleaning up an ObjectTexture, check all textures released properly

Condition: gl_instances.empty()

File: Projects\ObjectTexture.cpp

Line: 33

Function: __cdecl ObjectTexture::~ObjectTexture(void)

Build: release 181 (64-bit) checked

Component: Construct 2 IDE

(Last Win32 error: 0)

You are using a 'checked' release of Construct 2, intended for testing, which causes certain errors to be reported this way. Hit Ctrl+C to copy this messagebox - it's useful information for the developers, so please include it with any bug reports! Click 'Abort' to quit (unsaved data will be lost!),'Retry' to turn off messages for this session and continue, or 'Ignore' to continue normally.

---------------------------

Abort Retry Ignore

---------------------------

[quote:3feowtcm]Edit; You online have 1 sprite on layout two. Must I add the other?

Nope. There are supposed to be two there, one greenish-blue and one purple. The green one is on Layer 1 and the purple on Layer 2.

If you start up the capx and go directly to the Layout 2 tab you should see em both. Then, if you set Layer 1 to global on Layout 1, the green one will vanish from Layout 2. At least that's what happens here.

Yeah, but what happens if you try to set one of the local layers to global on Layout 1 with my capx? Do you still see both objects on Layout 2?

Updated with capx link

Problem Description

Setting layers to global in the startup layout causes all other objects on all other same-name layers to disappear (editor displays zero objects for the layer in question and runtime will complain about missing instances of objects being referenced). Trying to add new objects to a layout that had objects go missing threw the error message below. Seems to have been a one-off thing, I'm not getting the error message anymore, though layout objects are still missing. Setting the startup layout's layer back to non-global restores the objects in other layouts.

---------------------------

Construct 2 Check failure

---------------------------

Check failure! This is probably a bug:

Adding instance to layer with wrong layer owner

Condition: instance->GetLayer() == this

File: Projects\Layer.cpp

Line: 109

Function: void __cdecl Layer::AddInstance(class std::unique_ptr<class WorldInstance,struct std::default_delete<class WorldInstance> > &&,bool)

Build: release 181 (64-bit) checked

Component: Construct 2 IDE

(Last Win32 error: 0)

You are using a 'checked' release of Construct 2, intended for testing, which causes certain errors to be reported this way. Hit Ctrl+C to copy this messagebox - it's useful information for the developers, so please include it with any bug reports! Click 'Abort' to quit (unsaved data will be lost!),'Retry' to turn off messages for this session and continue, or 'Ignore' to continue normally.

---------------------------

Abort Retry Ignore

---------------------------

Attach a Capx

https://dl.dropboxusercontent.com/u/705 ... rsBug.capx

Description of Capx

Simple capx with two layouts. Layout 1 has 3 layers and so does Layout 2. Layout 2 also have two objects, one on Layer 1 and one on Layer 2.

Steps to Reproduce Bug

Set layer 1 or layer 2 on first layout to global. Watch layout 2 objects on same-name layer disappear.

Observed Result

Objects disappear/get disabled both in edit-time and in runtime.

Expected Result

That objects don't get disabled

Affected Browsers

• Chrome: Don't know
• FireFox: Don't know
• Internet Explorer: Don't know Node-Webkit: Yes

Operating System and Service Pack

Windows 7 Service Pack <at least 1>

Construct 2 Version ID

r181

Cool, good to hear

[quote:ifqycgqd]Keep in mind that node webkit will not only disable webGL on XP and Vista, but hardware acceleration in general.

Is there any way to get around this? There seems to be so many hoops for end-users to go through to get webgl/hardware-accelerated rendering going on otherwise capable systems. It's worrying.

[quote:1q87ziqp]I guess it comes down to: do you want a dream UI with everything, but after a long time, or for slow and perhaps painstaking updates to the existing editor, but arriving sooner?

I'd rather have the dream UI after a long-ish time (not talking years I hope!), because I imagine a total re-write would both be easier for you to do and would get us a much better UI in the long term. There are so many little problems with the current UI and band-aiding them all into submission might take even longer than just re-doing it all and get something that's more flexible to expand? I dunno, it's all complete guesswork on my part of course, I have no clue what it would take

[quote:1q87ziqp]- search functions - highlight your search query in the text and being able to search across multiple even sheets

This is a big deal for larger projects especially. I'm missing it more and more.