You know what would be nice? External event sheets. Sure we can call python scripts and stuff, but event sheets are still limited to the construct program. Wouldn't it be nice to use Construct's native event sheets as external text files to be imported at runtime?

To be able to include a custom level template along with the EXE... and have this feature be native to Construct, would really beat the hell out of INI files and python scripts. In your games, you could write functions that could be called by a modder through external events. Want the space background instead of the water background? Change the line of code in the template, and have the layout's events build the level per your commands for that choice.

You're precisely right. I'm glad you made me think about it again at this stage in development. I might has well design my objects and names with the intention of outside expandability, if only for the organizational improvements. I'll report back in two or three days.

I've been considering that. It would certainly be cool to allow users to create custom levels without having to use Construct. The only thing that might hinder that is the way the thing currently handles copy-pasting events as text. There's no easy way to getting things first INTO a text file without copying every individual event individually solo and all by its lonesome individual self. Unless my inability to copy multiple events as text at once is yet another bug.

Once again you come through for me, Deadeye. More cookie for you.

Shouldn't be very difficult at all to modify this to remove the random functions and create the specific encounters I have in mind. This whole thing has taught me a lot about containers, and I'm really enjoying the concept.

New dev journal and example caps coming soon. I'll be sure to recognize your contributions.

A visual example:

<img src="http://www.strouperman.com/Special/screen/test1.png">

<img src="http://www.strouperman.com/Special/screen/test2.png">

<img src="http://www.strouperman.com/Special/screen/test3.png">

Well, for each and all are fine when the intention is to work them in batch. I will still use containers for that purpose, in fact. However (and I haven't played with any tests yet), I also need to be able to create and manage individual containers on the fly. To do this, they need to have some form of separation, as shown in the pseudo code above. Let's say I create two new Enemy containers, but I want them to place their movement waypoint objects on separate sides of the screen, proceeding to meet up with them later. That's the intended effect.

Create new container, number it, perform actions on it individually if I want, all the while letting the containers do what they do best as far as batch commands go. Laser hits enemy container #4, destroy it. Special instructions to that container will simply be ignored, allowing the remaining instances to go about their tasks.

That is absolutely spectacular! I'm extremely impressed by the planet in the background. Wouldn't mind having my hands on your nebulous starfield bg either. Haha, I can only imagine how this would play in construct. Lots of use of the zoom feature, I'd suspect. Very snappy UI, too.

Okay, thanks. Sorry I missed that. At least I'm not going nuts.

Can anyone else confirm hotspots and image points cannot be set in this version? Seems like such a silly thing to be rushing to the bugtracker for.

Attan, two words for you. Ridge Racer.

I've been mulling this over for a day or two. The idea is to give each enemy container a unique ID number. This allows me to selectively activate individual containers for predetermined actions and movements.

For instance, for my game I have each level broken down into "encounters." Instead of everything being time critical, encounters allow me to set up challenges for the player and seamlessly string them together no matter how quickly the player completes his task. If, say, encounter 24 spawns two enemy containers I need to have full control over each to give them individual movement waypoints and firing instructions.

The way I'm considering doing this is using a global variable to create unique IDs, and assign them to each container on creation, then ++ the value.

[Begin Encounter]

+ Encounter == ##

• Spawn Enemy at (location)

• Set Enemy.ID to 'UniqueID'

• Add one to 'UniqueID'

(above will be more precise than simple add 1)

• Spawn Enemy at (location)

• Set Enemy.ID to 'UniqueID'

• Add one to 'UniqueID'

+ Value Enemy.ID == specific number A

• Set location of Waypoint to X.Y

• Set angle of movement toward Waypoint

• Set Enemy.speed to 30

...rinse and repeat for other instances.

So, does anybody have a better way of doing this that I might be overlooking? Is there a function of containers like this that is yet undocumented?

Thanks again, guys, gals.

And here's a better, more in-depth read on the subject:

http://maradydd.livejournal.com/374886.html