Can only say what i avoid ...

the do nots ...

Use the picture editor to do graphic work. U need it to import and to set image points.

Delete the object holding a the first loaded sprite. Feels to me like all the other object sharing that sprite, refer to this base one. And deleting the first one feels buggy. Spared me a lot of crashes.

Copy layouts, move layouts, change the events sheets coupled to a layout. Dont.

Delete private variables, change private variables text/number.

Delete image points.

Make triggers and conditions in 1 event. The triggers should be always on top of the tree, the conditions should be sub events.

If you access private variables using families, make sure the private variables are at the same position in each object.

Copy objects between layouts.

Undo on switches in the layout editor. With switches i mean things that are there or not. Like bringing back a deleted behavior. Undo a deleted object. Undo deletion of a variable. Undo deleting/adding.

Copy and object to another layer, and delete the original object.

Change layouts in an event with a zero time.

Leave 's p a c e s' in objects names, layer names, even behavior names.

Now if you track all this back to what all this has in common. Then you will notice most is about The events not updating with changing objects in the layouts. Or the other way.

To see this work.

Change an objects name in the layout editor, go to the events editor, and see the name is changed there too.

In other words, the events sheet updates towards changes made in the layout editor.

In some situations this dont happen. And that will be a crash.

And i think, besides the upcoming bug reports about last release, thats about it to be CAREFULLY with. Since last release construct seems very stable.

I say: go ahead. But accept that events and actions still can change. Meaning, a events sheet could still be not compatible with a next release.

Have fun.

Can not use a the tiled background object in Physics. Its what the name says: a background.

Use a real object, as in this fixed .cap. And everything works as expected.

If u really need the tiled background, then use it as a face,

but dont give it physics,

in stead, use a invisible Box object with the same boundings to act as colider.

Hope this brings back confidence in construct.

....

Ty for sharing the .cap.

Always nice to see how people make there games,

and without the .cap i would have never found the Bomb to fire.

If you use sounds, then u have to share the sounds together with the .cap

Sounds are, unlike the sprites, not contained in the .cap.

I have not much to comment about the Events. They are pretty straight forward.

Besides that i wonder why you destroy the 2nd boss gun 3 times.

Everything is presented by the right conditions. Line after line.

Although i miss some organizing.

Its a very nice example for how to use particles, they are done very nice.

But about playing the game, or lets say this level, it dont charm me much.

Sorry for beeing honest.

There is no way to escape the boss, or to use strategy in killing it.

But thats of course personal, needless to say i dont like "just click" games much as can be find in "shoot them ups" .

To return to your questions.

1/ No you dont need to set up very big layouts for this. The solution to this you did already. Create the objects outside screen. And call them to the screen on the right moment. Or make different layouts to represent levels, as you did already.

2/

You can warp the stars and bring them to normal speed, dont matter wich solution you go for.

3/

You should name your objects. Anyway. The Ship object is moved by an '8 direction' behavior.

What happens is, you force the ship to move away from the edge of the screen, while the behavior keeps pushing it back to the edge. And that feels like sticking.

So to keep the Ship from moving outside the screen, you have to communicate directly with the "8 direction behavior". Not do things behind its back.

To do this, just place a colider on the right and left of the screen. Make them "solid" in the groups/attributes properties. And the behavior will not intrude those, or put in in other words: keep it on the screen

This for your questions.

Another thing about "waves of objects". The events you build now, mainly control 3 objects and a bunch of particle objects. They are all different objects.

To keep a wave under control, you will need to learn to go along with instances, and the events to control instances.

I wrote about those, towards beginners, from out the eye of a beginner. Well thats what i still am.

You can find them here:

Enjoy constructing. : )

uhh, do you really want comments on a in a .exe packed thing ?

Just how am i supposed to do that ?

Sowwy you had to re-code the .cap. I can attempt to give an explanation for the way the variables behave in your events. But Even then, the good solution would be: Re-code.

Its impossible to give a *concrete* and fulfilling explanation. I have an idea what happened. Or should i say "a feeling".

Allow me to start with pointing to the way Construct is reading and storing variables.

Take this as the illustration.

There are only 2 objects. RedOne and GreenOne.

Both are member of the family "Items"

Both have 2 private variables.

But ! Look at the private variables, and notice that they are not added in the same order.

In the RedOne, 'variable_1' is first. In GreenOne 'variable_2' is first added.

Or to translate this to what it really is about.

They are on different positions. In Redone 'variable_1' is at position 1 int the list of private variables. While its on position 2 in the GreenOne.

So what you say ? Well read the events sheet, its kinda straight forward.

It dont need explanation.

And yet, when you run it. You well see that Reading out the variables using a Family is not working as you expecting it would.

Reading the private variable by addressing the object with its Family name, will read out the private variable on position(x) in the list of private variables for that object. NOT by its name !!!!!!!

Do you see this ?

Now well when this is true for families. Its also true for reading out AND storing any private variable, how ever you address the object.

So what construct really does is this.

You make an event/action that reads/stores a private variable, and construct will translate the name of the private variable to a number representing its position in the list of private variables for that object. And make the calls by that number.

This is done on the moment you make the event/action.

Those calls to positions (in the events) will update if you change (in the layout) things in the private variables.

But at this moment, i hope due its still beta, you can force situations that will NOT update both, the positions the variable gets called by in the events AND the private variables as presented to you in the properties list in the layout editor.

Now funny, and thats always the same, those situations are usually forced by beginners like you and me. Because we trial and error more then advanced users.

Try this. Make an object with 3 variables. Use the 2nd and 3th variable in some events.

Then go back to the Layout editor.

Delete the 1st variable.

Realize that was wrong to do and press UNDO (CTRL+z)

The variable returns.

Now SAVE the .cap.

Then run it

And or enjoy a awful crash, or have a .cap with messed up variables.

Like this

Now how you trial ed and error d to come to the position you was in. I have no idea.

And, you must realize by now, that all traces to what exactly triggers the situation are gone.

Ashley, i hope you take that serious, even when its just coming from me.

.....

Nicely commented. Ty.

Sorry if i confused by trowing a ".cap in construction", i figured : Rather trow you something then let it be and go to bed.

Simplified a boomerang curve, you can state:

It travels a certain distance, leaving the pitcher and coming back to the pitcher, with decisions to make at certain points in the traveling distance.

At distance = 0 .. it leaves the pitcher at a angle of -30� (right handed)

At 1/3 of the distance it will turn 90 �

At 2/3 of the distance we just tell it to return to the pitcher

At distance completed it should come to rest.

Since Distance in all this is a key variable, i made that whole construction with pressing space bar and make it look like energy gets build up. But in fact i just choose a distance there.

But "distance" is not really controllable.

So well, i translated it to "time". Like you trow a boomerang and look at it holding a stopwatch, and when you know the total time that its traveling, you can say ..

at 1/3th of that time it turns 90�

at 2/3th of that time it returns to the pitcher.

'time' is growing with every tick.

Thats all the object "GoodBoom" is dooing.

Now event 20 and 21 was an attempt to make the 1st turn less "instantly". The angle the bullet behavior is facing is changed in steps to +- 90�.

If you make "GoodBoom" visible, you will see that it comes close to a Boomerang path.

But, i was not happy with the "cornysquary" path.

And since i had collisions and bouncing in mind between the BadMouse and the BadBoomerang, i made a Ball behavior for another object (Badbullet) to follow the object that makes the boomerang path.

Resulting in a smoother path, and later more options to make things bounce.

If you make the reactions of the ball behavior faster, it will follow the bullet more close.

Now the point to return ? Guess thats up to you.

I think there are 3 options.

1/

Or it returns to the pitcher, and the pitcher is able to move while the boomerang is moving. But yes thats not really a boomerang path.

This is what it does in my .cap

2/

It returns to pitcher, but we denie movement to the pitcher while the boomerang is moving.

The path is closer to the path of a boomerang. But i dont know if its ok in your game concept to have the player vulnerable to attacks while trowing.

3/

It returns to the point it started. The player can move. But will have to pick up the boomerang to be able to trow it again.

The conditions in sub events are tested if the conditions in there *top event* are met.

plz define "it"

[quote:uma781gr]Re: Gravity Comparing

by Ashley on Thu Jul 03, 2008 11:06 am

Should be out today, pending a few problems with the picture editor.AG.

i have a feeling that this is what he pointed to.

No sprites ? dude how many free ware paint programs do u need ?

Construct even accepts 32bit masked targa's.

Its impossible to be stuck on this. Less you uhh .. well .. well lets not assume.

https://www.clickteam.com/web-shop/

—