In future, when we have folder and separate file based file/project formats (you are going to do that for 2.0, right? xml format :)? ) there could be a feature to save a runtime state into xml file - like there's the current save state binary format - and import the object position, rotation, size etc. data to layout editor in edit time, or have simply a XSL sheet based tool which would effectively CONVERT that data into a layout xml file! That way you could position objects runtime and see them in the "wysiwyg" manner, and then have "what you see" as a layout file.

(Btw. separate xml layout files would allow also runtime layout loading! And that you could make your own level editor, and have it to export xml file, and import in construct's level editor! And and and... many kind of things :D)

Did I already tell you that I love you all?! With these news, I'll be happy even if the future builds won't have Spag Bol support. (Those who have been lurking here long enough, may get it ;D)

Well, I was celebrating with my IRC friends, we arranged a meeting. We drank, but not too much. (Instead, few weeks ago I drank more than ever; first time in my life I couldn't remember the end of the night :P)

No, it wasn't me, if it was, why would I present my own essay as somebody else's ;D

There's other finns too. (I know you are there, you bastards, since I always lurk here, although I seldom post >;3)

Only third page on Google Finland :I But check this:

https://oa.doria.fi/handle/10024/42982 and https://oa.doria.fi/bitstream/handle/10024/42982/Nevala.Erkka.pdf?sequence=1

A finnish guy from some university of applied science apparently made an 32-page essay paper about Construct :D "Construct as a tool of game development"

Actually, that essay serves pretty well as an user manual :D... And it has an english summary too, go ahead and check.

They said that 2.0's file format would be xml-based... I wonder if it also means that layouts could be natively exported into separate files and imported in edit-time or even runtime... It would help greatly with this sorts of things, and of course, with collaboration.

Christ, talk about cheesy....

If I want to talk about cheesy, I talk about american comics ;>

Hahahaha :DD I see it now. Aren't we Construct users cruel >:D.

What :D? Did I say something funny?

I should work, at least it worked when I did it :P.

To make it clear: The action you are going to perform with sprite, should be done with the sprite itself. The destroy action should be done to the family. (Or the other way around, but it's easier this way)

This is because the sprite and the family have separate List of selected objects. When you are talking about family, construct no longer has the exact sprite you chose in the condition, picked.

Another way to manage picking is to use families. Include objects you want to destroy in a family, and destroy the family in that event.

Have you heard about NearlyFreeSpeech? ( https://www.nearlyfreespeech.net/ ) They have a little different pricing policy; you only pay for what you use. It's best for little sites, because usually hosting packets have way too big limits, (and thus, way too big price) So, it scalable.

Their prices are bind into their own hardware and transfer expenses, so it shouldn't be too expensive. Check it out.

(Hm, it may be that this site's transfer rates are so high that NearlyFreeSpeech isn't very good choice :o)

DreamHost is also pretty well-known and good provider... ( http://www.dreamhost.com/ )