.ini files can hold as many variables as have been declared in the .ini file its-self.

[Groups Are Declared Like This]Items_Like_This = value

[This Is Another Group]

Items_Like_This = differentvalue

More_Items = value[/code:3t8la607]

You should be able to work the rest out through the relatively self-descriptive Construct events.

Firstly, your .cap is officially hard to navigate. Also, it's going to be hell if you add levels later on and want to make changes that permeate throughout all of them. You're better off including one (or multiple, for readability sake) event sheets that handle things in a more generic manner. That way if you want to make a change that affects multiple layouts, you only have to do it to the one event sheet.

You can add event sheets not tied to any one layout by right clicking on the "event sheets" folder in the "project" bar. Then, in any layout's specific event sheet, right click and "include" the event sheet that the layout needs to use the events from. This will tidy up your event system, making it much easier to read, as well as facilitate modularity later on.

As for your specific problem, in the properties of your civilian object, scroll down to the "container" option. "Add Object" and select PRE_shirt and PRE_hat or whatever the shirt and hat objects are called. This will tie the hat and shirt objects to each NPC individually --> multiple NPCs could have different shirts and hats, and if the controlling object (in this case, the civilian) is destroyed, so will the hat and shirt particular to him (but no others). I tested this, and it seems to be an improvement, you should be able to work out the remaining bugs from here (you'll probably have to change the flow of the events so that it takes this into account)... Still, if you have any further problems, shouldn't be too hard to fix.

Your game looks pretty cool, at any rate. Good luck with it.

Edit: I just worked out what one of the causes of a bug would be. Whenever you create a shirt or hat object, it also creates a civilian (because a container object is also contained by the object it is containing?). My suggestion is to not create the hat and shirt objects, but rather run the events that change their appearance on the creation of the civilian its-self. There are some complex problems associated with containers, and I fear you'll have to modify quite a bit to utilise them. Which is why generic event sheets are awesome!

Second on the list from Aus.

Why don't you just use particles, and have the x, and y randomizer set to screen width, and screen height?

I guess it would depend on what you'd want to do with the explosions. If you wanted them to, say, interact with other objects in the game, particles wouldn't cut it. Also, I don't believe particles can have animations.

Edit:

This is probably more efficient. Still, add the scroll offset as Stargoat (lol) said.

What's funny?

An alternate (and, in my opinion, better) method to have them occur within the bounds of the current screen is to use...

+ System: Every 3000 milliseconds
-> System: Create object Sprite on layer 1 at (ScrollXLeft+Random(1024), ScrollYTop+Random(768))
[/code:1ag7n1xa]

This will make sure the objects only spawn within the bounds of the screen. Lost My Keys' method will work, but it's not as efficient, and much less so as the layout gets larger. (Plus, there's no guarantee that the objects will actually spawn on the player's screen).

The "create object" command is found in system, and "ScrollXLeft" and "ScrollYTop" are also found in the "system" properties.

Edit: For a more pleasing effect where each explosion is also randomly offset in time, try something like... [code:1ag7n1xa]+ System: Every 2000 +Random(1000) milliseconds
-> yada yada[/code:1ag7n1xa]

This will have each explosion go off at not only a random part of the screen, but also a slightly random time.

> How do you get more than one frame in Construct?

>

If by "frame" you mean "layout" then you right-click on the Layout folder in the Project bar and select "Add layout."

The topic is clearly about animations.

Although it may not be optimal, playing the sound in a channel of its own should work.

Edit: here's a .cap showing this. Press "space" to play a shooting sound. When you release space, it stops the sound, but those in the background do not stop playing.

You might want to turn the sound down, because the ones in the background could be quite annoying. Just sayin'.

With the animation bar open, select the animation and angle you want, then in the list of angles, right click. There are two main options that you'll use "Add Frame" and "Import Frames".

Add Frame lets you add (or draw) a single frame. Use this if you have lots of individual images.

Import Frames allows you to load a whole set at once, in the form of a sprite sheet. Once you select the sprite sheet, you give parameters such as the grid to cut along, and Construct will slice the sheet up for you. It's very handy.

Note: When importing frames, you'll need to specify transparency on each individual frame unless the sprite sheet is using "magic pink" in all of the areas of transparency (alpha channels will not work). In RGB, Magic Pink is 255R, 0G, 255B.

> Sorry to wake up this thread but i have been trying to do the same thing and having the same problem. The top layer is hidden and the bottom is fubar.

>

Did you enable 3D Layering in the layer properties?

Hah. It took a while, but we got there in the end.

Keep in mind that there may be situations where an object may look to be stationary, but it's really moving with a small velocity (say, .2 pixels per second). I think with the physics behaviour, (and correct me if I'm wrong) a situation where a previously moving object is completely stopped could be rare.

Considering this, having a range of speeds that are considered as "stopped" (say, less than 1 pixel per second, greater than 0) may provide better results.

I think most of the "movement" related behaviours should have a velocity property.

Here's an example using the "custom movement" plugin.

+ System: Sprite[CustomMovement].Speed Equal to 0
-> Text: Set text to "do a thing"
[/code:2l3a9vac]

This is using the "Compare Value" system command - it can be found at the bottom of the list of system actions. There are three parameter fields, specifically, the first value being compared, the comparison function (eg lesser than, greater than or equal to etc.) and the second value being compared. When entering the value in the first field, double clicking on the sprite's icon will give you a list of parameters and values. Clicking the "custom movement" tab at the top will give you properties specific to custom movement, one of which is "get speed".

You can probably work the rest out from here.

Using the custom movement plugin, simply "accelerate" (through the custom movement --> set speed action) towards whatever point you want. It's possible to simulate complex gravity behaviour (eg, multiple points of gravity) with this method.

Edit: Here's an example where using families, you can achieve this:

+ System: For each spaceyobject
-> Projectile: Accelerate speed : spaceyobject.Value('Mass')/((distance(spaceyobject.X,spaceyobject.Y, Projectile.X, Projectile.Y))^2) towards spaceyobject 
[/code:2mq84cok]
Where you can have multiple objects with the family attribute "spaceyobject". The projectile will accelerate towards "spaceyobjects" according to the equation: (mass (arbitrary private variable held by all spaceyobjects))/(distance from projectile to object^2)

Because this occurs for each spacey object, you can achieve quite realistic (within reason) behaviour. You'll need "mass" values of somewhere around 25,000.