Cloning layout doesn't copy events.

Cloning a layout doesn't copy events to cloned layout.

It's very annoying if you're making game. Also, bar at up doesn't have working Add\Remove layout buttons.

I hope it will be fixed in next version <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />.

I'm not sure cloning a layout *should* copy the events. Then you end up in the situation when you have 10 levels with 10 copies of your game code - if you find a bug in your events, then you have 10 times as much work to do!

A much better solution is to clone the layout, then in the second layout's event sheet, just include the first layout's event sheet. You can then add any custom events that are solely relevant to that layout (eg. a special enemy/powerup), without having to have copies of all your general code like shooting.

Yes, that would kind of ruin the idea of event sheets. However, it could ask when cloning layout, whether the user wants to include event sheet into the cloned layout.

I can't copy events <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" />. I am selecting event, clicking copy and pasting. Nothing happens.

Ctrl+C doesn't seem to do anything, but clicking Copy on the ribbon bar works.

Doesn't works for me. It work only in one layout, i can't copy event into another layout.

Ctrl+C doesn't seem to do anything, but clicking Copy on the ribbon bar works.

Fix my favourite combo : CTRL+C, I'm dieing. I have to script 20 weapons' shoots all similar so it's really boring to press and press with mouse. Ctrl+C is faster.

[quote:2ynlw7uy]Doesn't works for me. It work only in one layout, i can't copy event into another layout.

It doesn't work for me too. Fix it or else I can't make other levels!

I have an idea for the Interface that may help with sheets and layouts:

http://i202.photobucket.com/albums/aa130/ChrisDines/constructidea.png

An extra part of the projects panel for showing event sheets.

In the Event Sheet Editor, you could even have the ability to drag a sheet from this panel onto the Event Sheet you have open in the Edit Area, and when you let go it would appear as an include where your mouse is.

The idea is that you have normal event sheets, and 'private' or 'local' event sheets. Normal ones are just includes, and local ones are level-specific. You have just one local one per Layout, and it can't be included by another sheet.

So for instance, in the above picture, we have some includable sheets that I've named:

• Loader Sheet

+ Custom Movements Group

-- Player - On Foot

-- Player - Driving

-- Player - Flying

In addition, there's a 'My Groovy Layout Events' (MGLE) sheet, which doesn't appear in this list, because it belongs to the 'My Groovy Layout' layout.

If I have code which is level specific, like 'enter the cave and the entrance collapses', this would go in the MGLE sheet. This sheet is local to that layout, a bit like a private variable.

This is also where we define any includes that this Layout will refer to.

Of those includes, I've (in the above example) chosen to have one include that handles all the others. So I've created a sheet called 'Loader' which determines what other includes will be refered to. So for instance, if there are no drivable cars in the level, it'll not bother to include the 'Player - Driving' sheet.

This could quite easily get around the problem of cloning events with layouts. When a layout is cloned, perhaps its private event sheet is cloned too. This would keep all your 'include' references intact, and would allow TGF users to use the methods they've got so used to.

But for the rest of us, it'd save us re-including the same sheets for every new level

Yes, that would kind of ruin the idea of event sheets. However, it could ask when cloning layout, whether the user wants to include event sheet into the cloned layout.

Seconded. It's a simple, yet effective solution.

Though I do like Dine's idea for an Event Sheets tab too.

Yeah, Dines' idea is leads to most "logical" and structured system. Actually, I was going to suggest something like this too <img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" />. First, I didn't like that the system is so strict that you actually can't include layout-specific event sheets to anywhere else, I just wanted a system which makes the structured arragement and management of events and event sheets easy; now the "additional" event sheets are like hidden in project's properties, which they shouldn't be.

Now that I think it, including event sheets from "just" another layouts (not from the "centeral structure") is kind of bad habit, like GOTO in program code. So, I think that Dine's system is pretty good. It has it's benefits, it kind of forces users to use more structured and effective ways.

Now, only thing that concerns me, what kind of UI would be good? I didn't fully get the Dines' picture... <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz" />. Is the upper panel the Project bar? Maybe those funky words, pretty and groovy are just messing my thoughts... so groovy... <img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" />

And btw, what's the purpose of Resource bar? There surely is some resources, but it feels somehow only half-necessary... I think that Resource bar could be integrated to the Project bar. Under the "Application" main node, there would be the layouts, as a part of the project and other resources.

Yup. Whaddaya think?

Lol, it's basically exactly the same as construct now, just with an extra box on the 'Project' panel.

Hm, I thought Dines' system some more. I realized it lacks some flexibility - if the included event sheets are specified in that additional box, you can't arrange how the includes are in the layout main code. In some situations the run order of the events does matter. However, the events separated into different sheets don't usually have too much relations, so does the order matter so much?

As you might read from my previous post, I had some kind of vision of "unified" Project bar. It could have the layouts, the resources and the "general" event sheets there. And event sheets could be included in the event editor, like now. Maybe there could be a restriction, that the layout-specific event sheets couldn't be included, I dunno about that.

Edit: Oh, and I have a questions for Ashley: Is there need for global objects? (Or, what I really want to ask, is there need for non-global objects <img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" />) What they actually are in Construct? How they differ from normal objects? What I'm thinking, global objects are some kind of relic of "thinking in MMF", I think that every object should be "global" so that there wouldn't be hundred and one types of objects which actually are the same, copied to different frames.

Or is it only my who is thinking in MMF <img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" />? What does globality mean in Construct?

Edit 2: Apparenly, it was only me <img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" />. Did some testing and in two different layouts it considered copyed sprite as the same. So objects are global in a way. But what does the "globality" in Construct mean then?

And is there some GUI for inserting objects from the other layouts, except for copy&paste? And what about objects without "body", like Keyboard and Mouse?

One idea may be that for the project panel, you could simply have folders like this:

Layouts

• Jungle Madness 1

• Jungle Madness 2

• Street Rage 1

• Street Rage 2

• Create New...

Event Sheets

• Loader

• Player Movements

• AI - Monkey

• Create New...

Objects

• Player - Default

• Player - Cool

• Player - CyberSuit

• MY MONSTERS

-- Bullfrog

-- Lizardman

-- Chinese Person

-- Polish Martian

• BACKGROUNDS

-- NORMAL

--- Grass

--- Sky

--- Tree 1

-- SNOW

--- Grass

--- Sky

--- Tree 1

• Create New...

Subfolders, etc, would be created by the designer. So it'd be up to the designer to determine how things are organised internally. But perhaps subfolders could be changed at runtime? So an event to find all textures in 'Backgrounds\Normal' and change the active path to 'Backgrounds\Snow' would instantly load the snowy equivalent?

This idea's only rough, but at least it'd help organise stuff. At the moment, I think it's too heavily centralised on the Layouts.

i second dines idea, it's actually more organized that way. in addition to allowing developers the option of creating custom folders have an option to create default common folders as well.

I really like this idea, but I should mention a few things. Firstly there are still a lot of bugs in Construct, so a fairly major thing like a new bar should probably wait until after 1.0, no matter how good an idea it may be (I do want to take event sheets further).

Secondly, the original plan for event sheets was:

• Each layout has an attached event sheet. You can see this in the layout properties (eg. Event sheet: Layout 1).

• Adding a layout adds a new event sheet so the layout has its own attached one. This is a metaphor for "private" event sheets, but you can freely choose in layout properties which is the attached event sheet.

• In application properties you can freely add more event sheets for things like global events, collections of functions etc. and include them where needed. Eg. you could have a 'Menu events' sheet for your menu layouts, and a 'Game events' sheet for your levels.

I think this system can achieve everything you need to do with event sheets, just instead of private sheets, layouts have a default sheet.

I like the project bar integration idea best over a separate bar though, Dines' idea is good: under 'Application' would be 'Layouts' and 'Event sheets', listing both.

In response to Drasa: Construct is designed solely on a global object system. Every object is actually global. You can't have two different objects named 'Sprite' on two different layouts. But by default when a layout ends all its objects are destroyed - ticking 'global' in object properties just stops it being destroyed, so it's still in the next layout, and is still affected by any events the second layout is running. Also when you clone a layout, you should end up with more instances of the same object types on the second layout - this fits in nicely with the event sheet includes, because you only need to write events for one set of object types (families also work correctly across included event sheets).

Finally I didn't actually write the event sheet system, and it's too broken to be useful right now, and the devs who wrote it have as you know bailed out, so I'm a little stuck - I'll try to do my best though.