Rhindon - yes it is because of that, but only the Y is dead centre (since this is not using X).

using the height seems the simpler of the two to put into effect. you could use x, just setting similar margins to the sides of both sprites and testing for when the player.x (plus margins) is on the x of the drbox/enemy.x plus margins. just seems a tad fiddly in my mind.

i would advise not using a set number of pixels to add though (DrBox.y+50 pixels) and instead something that will change with your characters (should you choose to change their height).

it is not necessary of course but will save a lot of tedium in case you decide your character is too big or small. or for copying and pasting bits of code to apply to other sprites (which i do a lot). and, as i was advised, if you do code something like a characters attack range versus a lot of enemies (for example) if you have to go back and change that in all the code (instead of setting an instance variable for range) it would again be tedious.

(drbox.y - drbox.height) - instead of (drbox.y - drbox.height/2)

• this is assuming the origin point is at the very base of the sprite image

compare the Y of them, the height instead of their horizontal whereabouts might be more applicable?

so (this is without looking at your capx and assuming both have origin points in the middle)

system - compare two values -

> (mrstick.y + mrstick.height/2) is less than (drbox.y - drbox.height/2)

        > no damage taken

> (mrstick.y + mrstick.height/2) is greater than (drbox.y - drbox.height/2

        > damage taken

• plus half his height to give the y of where the bottom of mrstick is, so if his feet are higher than the top of drbox - no damage, if his feet are lower (greater in y) than the top of drbox than he can take damage.. adjust as needed

*** if i've mixed up the up and down of the y axis just switch the plus and minus signs.

yes, i got one of the beta releases to look at another user's capx

scirra.com/construct2/releases

AhemExcuseMe - i tried doing this some time ago (trying to make legs that walked) but was very unsuccessful due to the odd workings of physics and revolute joints.

i tried to make an example of this using physics and joints but after fiddling with it for some time i decided that simulating a hydraulic joint was much easier than trying to get the picky revolute joint system to work. sometimes the joints of the arm piece would get "pushed out" of where its joint was (attached to the base), and when changing the height of the arm it didn't push the upright piece like i had thought it would.

here's what i came up with:

dropbox.com/s/7cv9qr7910xaoh8/hydraulicarms.capx

if you want to try and fiddle with it, remove the pin behaviour from the arm1, add physics back and update the event sheet to reinclude revolute joints. maybe you will have some ideas that i did not!

i did learn a new expression that may or may not help with my legs project though <img src="smileys/smiley36.gif" border="0" align="middle" />

every random seconds needs to be random(1,5) instead of a dash (random1-5) makes them spawn like crazy. also the spawn event random((12,1024, 1200) that Y coordinate is spawning them off the bottom of the screen - change to 0 if you want them up at the top.

for easier debugging you can try setting your background to invisible and your squares to visible, it helps a lot when setting up your event systems.

gamekill - i made an example. i figure this could all be simplified using families but i don't (yet) have a license for C2 so this is another way to do it without using families. there are notes in the capx about families.

hope this helps!

dropbox.com/s/cw24j2xnngc24ub/sizeclicking.capx

the centre is probably snapping to the finger because thats where the origin point is, is it possible to set an origin point for each corner say and then pick the closest one for dragging?

mrtumbles - very nice solution, this actually might even help me on a game idea i put on the back burner - cool! :D

under your collision event sheet change "sword - on collision with beebot"

to "sword - is overlapping another object (beebot)" and it works.

to help with debugging i noticed that the top right bee would only die when being struck with the very tip of the sword. so if the player is right on top of the bee and swinging there is no collision to detect, the sword spawns already on top of the bee.

tiled background:

scirra.com/manual/118/tiled-background

Or if your background remains the same it can be on a layer separate from the elements that will spawn and (presumably) scroll and therefore you wouldn't need it to repeat.

Random spawning:

gamedev.tutsplus.com/tutorials/from-scratch/build-a-canabalt-style-infinite-runner-from-scratch

It's not for construct, someone posted it the other day, the same principles can be translated over to construct though. Instead of platforms you could spawn objects or enemies.

if you have families this may be able to solve it that way, since you would be able to pick the top/bottom of the family, yes?

or without families perhaps you could create a condition with sprite1 is overlapping sprite2 and then find a way to get the behaviour you want with that filter. would something like pick top/bottom sprite1 OR pick top/bottom sprite2 work?

depends upon the game type i think. you can make it "unlimited" by creating events that randomly spawn objects (or obstacles in say a runner) and having a tiled background i believe.