that is just because once the energy = 0, the life is lost

BUT you need to set energy = 100 for the new life!

or the counter will keep loosing lives if energy = 0,

so it will go: lives 3 -1, 2 -1, 1 -1, 0, and you will only see 3 -> 0

where it says "if the life counter is ON, lose 1 life, turn life counter OFF"

add: *set global variable 'energy' to 100*

but then what happens is, you lose a life,

the counter shows 2, and energy 100, but no plane!

because you destroyed the plane a forgot to create it again!

you can either spawn a new plane at XY, or just move it XY and not destroy it.

btw, i redid the layout and it seems to work just fine now,

thanks again

oh, silly me, i misunderstood you and kept checking for families,

i switched to the solid attribute, and though it didnt work on the current project, i tried reacreating it in a new file, and it seems to work.

i've uploaded the new example - dl.dropbox.com/u/45834687/wallgun.cap

btw what is the practical difference between attributes and families?

anyways, thanks tulamide, always so helpful!

do you mean families?

yeah i have the solid objects into a "solid" family.

and what i did was:

bullet on collision with solid, destroy.

but it still destroys all other instances, did i miss something?

on the bullet expressions i only get compare speed, exceeded range, and step

alright,

so i have wall mounted guns / cannons,

which shoot at given time intervals.

i want to make them so that when they hit a solid object, the bullet will destroy.

it works, but it also destroys other instances of the bullet,

how can i avoid this?

and make it only destroy the instance that is overlapping/"collisionig"?

thanks

hey, i added the life meter.

dl.dropbox.com/u/45834687/lifemeter.cap

i explained what i did and how it works in the event sheet.

i used a tiled background instead of a sprite,

it repeats vertically and horizontally, so you need to keep the height normal, and take the normal width, and multiply it by the number of lives.

at first i added a check to see if you had more than 0 lives, but at the end i dont think you need it, but i forgot to remove it.

what you need to do is make the plane respawn after dying.

i think it should work

if you have any questions let me know, <img src="smileys/smiley2.gif" border="0" align="middle" />

resurrecting the dead for justice

Great! i think that works perfect, thanks!

what i dont understand however is, once spawned how is the bullet object moving forward. as for everything else i think i get it.

So I have a "cannon", that shoots a laser-like ray, so instead of shooting various "bullets" it shoots only one long ray.

The "cannon" spins on its own axis. And and the ray rotates along with it, like the dials of a clock.

Now, i have some wall-like obstacles, that i want to obstruct the path of the ray.

Is there any way to do this? so that when the ray rotates on the axis of the cannon, make it not go past (in terms of radius) once it hits a wall, in the same manner that when light hits an opaque object it doesnt move through it and you have a shadow on the other side.

OR instead, how would this be done: ray is object A, and wall is object B, whenever B overlays A, intersect A's collision mask, so that the part occupied by B isnt accounted for?

hope any of this made sense.

When organizing events and event sheets, i tend to have each layout just include individual sheets, and create for example one for input, movement, collision, animations, etc

and then when the layout starts just have it load whichever sheets needed,

so each sheet affects every layout that uses it, and you only have to edit that one sheet. within sheets and layouts it's good to organize with colored comments and groups. - i dont know if that was the kind of tips you were looking for.

as for collision, i personally have some nuances with it, but i use the sprite.left/right/top/bottom/x/y expressions instead of sensor srites, in order to detect it.

hope some of that helps

It will not collide perfectly because your sprite will move more than 1 pixel per frame, ex. if your sprite is 1 pixel from the object to collide and your FPS is 60 than, 120*1/60 = 2 pixels, it will move 1 pixel inside the collision object, with lower FPS is even wrost try to put it fixed aroud 15 fps and test, try it on unlimited too and you will see it work perfectly because it will move lower than 1 pixel per frame.

The way i discribed, using loops, will always move the exact pixels before collide with the object.

The "is moving" i mean to be your way to detect this, in your case you have to do "On keyboard: Left button is down", move to left, and so on...

Hehehe, i thought so, i felt dumb thinking there was an "is moving" event that i'd skipped over! anyways that question HAD to be asked <img src="smileys/smiley36.gif" border="0" align="middle" />

anyways, are either fixed or unlimited FPS recommended? i thought v-sync was optimal.

I had tried it on unlimited, and collision-wise it worked great, but i had that sprite tearing almost, that i reference before, like for example, if the sprite is 32x32, it'll show up as that size, but within its own 32x32 bounding box, it'd be moved say to the right, and the left border would be drawn into the X0 and X1 columns, weird.

and i thought fixed FPS was supposed to hinder your TimeDelta

i'm looking forward to implementing a loop as you suggested, it looks like i'll have to clean up the game structure first, in order to replace it neatly hahahaha <img src="smileys/smiley4.gif" border="0" align="middle" />

as for now, while i'm restructuring it, i got around the collision enough to work with it with something like this:

B pick closest to A.left\right\top\bottom

+ if A.left\right\top\bottom >\< B.left\right\top\bottom -\+ speed*TimeDelta

-> then move at speed*TimeDelta

etc

extremely summarized but in essence that's what i got around to enough for it to work until applying loops, if it helps anyone in the future.

XD

I really can't understand what you intended to do with this:

In these conditions you set the Sprite object to move equally to right, left,top and down. Of course nothing will happen...

lol, i know, it's meant to represent individual movement on key presses,

i just skipped over the key press events when posting it.

the reasoning was something like:

• if key down

+ sprite is not overlapping object

-> move in given direction

however there's going to be a moment, where it isnt overlapping, but will move once more, and end up overlapping,

so i tried with an offset, but still sometimes stop before colliding, and at random occasions really, against the same wall it may or may not collide perfectly XD

For the collision problem you have to use "For Loop" and make like this:

Sprite is moving

>    + For 0 to ceil(120*TimeDelta)-1

>       + If Sprite is moving right

>         + [negated]Sprite is overlapping at offset ((ceil(120*TimeDelta)-LoopIndex),0)

>           -> Sprite move (120*TimeDelta)-LoopIndex at 0 Degrees

>           -> Break

>       + If Sprite is moving top

>         + [negated]Sprite is overlapping at offset (0,((ceil(120*TimeDelta)-LoopIndex)*-1))

>           -> Sprite move (120*TimeDelta)-LoopIndex at 270 Degrees

>           -> Break

>       + If Sprite is moving Down

>         ....

>       + If Sprite is moving Left

>         ....

>        

Do it to the four sides.

To make conditions for diagonal angles is a bit more complex.

cool, i'll try it out, however i do not see any "is moving" events,

thanks.