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

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

<img src="http://i202.photobucket.com/albums/aa130/ChrisDines/Picture5.jpg">

I is all kinds o fine, wiv mah big hair, an' mah sasseh grin. Mm yeh. Yous all wants mah hair.

Yeah, the Construct event system is a lot more powerful than MMF's, with more advanced functions and loops, and you can do subevents.

Are you an MMF user already and just trying Construct as an alternative, or are you trying to decide between the two?

MMF has the obvious advantage that it's finished, has a lot of users, a lot of examples and a lot of documentation already out there. But that's not a benefit of the software, per se, just its age.

Construct also has an awesome physics engine being grafted onto it. While similar plans are underway for an extension in MMF, I don't see how it will be as powerful (because it has to be a plugin, whereas Construct can handle it a bit more directly).

Doesn't stop him playing with Barbie though <img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" />

LOL. Sorry, couldn't resist! <img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing" />

A few things that'd be nice for the Physics Movement:

Being able to position a physics object to a non-physics object.

So for example, positioning an object to the mouse coordinates, so you can make a brick follow the mouse, and move/slow down with the force of the mouse. So you could use the mouse to pick up an object and wack other objects with it.

I suppose you'd do it by checking where the mouse is, and where the object is, and working out how much force it would need to have moved to that position.

EDIT: Also, with hinges, there seems to be a problem with the Stiffness variable. It crashes if I try and edit a hing-to-object action, and the stiffness value always appears as 0 in the main event sheet editor.

Out of curiosity, did you ever make maps for Age Of Empires II?

That had an event system which works the same way as Construct.

The basic gist is thus:

Selection Conditions

Construct has a list of conditions and actions (the event sheet editor). It scans this list from top to bottom, then scans it again, then again, and again, every time a new frame is drawn. The most basic condition is:

Always

This condition will trigger on EVERY pass of the events. So if we drew 100 boxes and did this:

Always

---Set X position of BOX to box.xpos + 1

...It would move the boxes to the right by 1 pixel on every frame.

In addition, Construct assumes by default that you mean ALL the boxes. So EVERY box will move.

If we want to set specific boxes to move, we have to narrow Construct's 'object focus' down using other conditions.

So we could do this:

X position of BOX > 320

---Set X position of BOX to box.xpos + 1

The condition basically says 'Is X position of BOX greater than 320 pixels?'

It scans EVERY box, literally asking it 'where are you?' and then it strikes off the list all boxes that don't match the criteria you gave it.

So when it comes to process the action, only the objects with an X position of 320px or more will move. You'll basically see the objects on the right-hand-side of the screen move, and the left will stay where they are.

You can enhance this further with more conditions:

X position of BOX > 320

Private Variable 'Health' > 20

---Set X position of BOX to box.xpos + 1

This narrows its selection down, first selecting only those on the right-hand side of the screen.

Then, OF THOSE OBJECTS STILL SELECTED, it checks whether their health is greater than 20.

So now when it processes the action, it only moves the ones on the right that have a health value of 20 or more. Weaker boxes, even though they're on the right, will not move.

This concept is ultimately like using a database. I don't know if you've used databases much, but it's a bit like having a list of names and saying

"Select all names, where county is 'Surrey', town is 'Caterham', 'Street' is 'Beggars Green'"

It's that kind of thing, but with objects.

This way, you can decide whether your code will apply to just one of many objects, or to a group of objects, or to all objects.

Trigger Conditions

These conditions are a teensy bit different. Normally, Construct just processes the event list from top to bottom, then does it again, then again, then again.

However, some conditions can be Triggered. These include:

'On Function' and 'On Start of Layout'

We can have an event like this:

On Function 'Move'

X position of BOX > 320

Private Variable 'Health' > 20

---Set X position of BOX to box.xpos + 1

And it will normally be skipped by Construct as it scans the list (because 'On Function "Move"' has not been triggered).

However, we can trigger it from inside another event by doing this action:

Run Function 'Move'

Then suddenly, it pauses everything and looks for all the events that start with 'On Function "Move"'. It will process them all, in the order they appear in the event list.

When it's done 'em all, Construct goes back to where it was and continues as normal.

So this way, you can run loops and functions and stuff from within other events, and they will be processed instantly.

That's basically how it all works. You use Trigger Conditions, to make sure something is only tested when you want it to be. And you use Selection conditions to narrow down which objects will be affected by this event. Then you define actions that will happen.

Would it be possible to set the frames in a time speed instead, or have the option to do that?

Because if you use a system for slowing the frame rate depending on the system's performance, animations will go slower.

I could build it, but my main problems are with the image editor, so I can't really create new sprites for the object types and stuff.

But Construct's noticably better than it used to be!

Cos of my system, I can't really use Construct much yet, but I was playing with the physics and had an idea someone may wanna make <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

You start in a scrollable platform-style area, and you have a set number of people (e.g. 6). You also have various building components, like bricks, collumns, blocks, rafters, etc.

Your objective is to build a structure around the little people, to act as their castle.

However, it must be strong, and you must be quick, because when the timer ticks its last, all hell breaks loose, and the storm winds start coming.

The winds (basically invisible objects being blown at the walls from different angles) will knock at your walls, and you may get fire and brimstone too (the latter will burn any wooden materials you used). Or there may be an Earthquake (the floor shakes everything above it).

As the blocks fall, you can shore the building up (by placing a block to catch the roof just before it caves in, for example), but you must prevent your little people from dying.

You get awarded points on a per-person basis:

For each person alive, you're rewarded by:

• The length of time that person has survived

• How high he is (people stored higher up earn more points, because it's more dangerous)

You're given penalties for the death of a character, like -100 points or something.

The longer the game goes on, the worse the disasters become, so winds and earthquakes get stronger, brimstone is more common, etc.

In addition, you get special objectives. Like you have to store the people in a room with hay so they can weather the storm... which of course is a brimstone fire hazard. Or you get a special super-delicate mural which you must protect at all costs.

Or you're building a monastery, and you must segregate the nuns and the friars, various little challenges and rules like this, which force you to design the building in a certain way.

Or one may require you to build the structure over a huge gap, which obviously could cave in with the earthquakes.

I'd love to have a go with that!

So, in summary, the threats you'd have:

• Wind (changing direction and strength)

• Fire from heaven (can burn wood)

• Earthquakes

• Meteorites (come down with great force, and risk knocking large objects away)

Still getting bugs and crashes, most of which I think are related to my VRAM issues. If possible, I may try it on a work machine, which is better.

But it's SO MUCH BETTER THAN IT WAS! I love the changes to the interface, especially the selection of actions and conditions.

Been playing with physics and it's lovely!

You could, perhaps more simply, add a feature a bit like extensions, where Construct can look for a plugin which explains how to convert an old file format to a new one. So in a simple example, if the file header now includes a bunch more stuff, the plugin would read the old file format and reorganise it into the new one.

I'd have thought you could use your file-reading code from the old version, and file-saving code from the new version, to lift everything into memory, then shove it into a file using the new routines?