That all depends on what kind of game you're making, and what you need the hitbox to do, and what you need the player to do, etc.

Sweet . This is really coming along. Awesome job.

I don't really think the clouds fit in with the rest of the pixel style though. But overall it's pretty slick looking, and plays well.

When you create a new layer it's auto named 3, but its actually layer 2.

Confiirmed. Looks like a bug, you should report it. It also might be responsible for some of the troubles I've seen that people have had with referring to layers by their number... maybe?

You're using a System compare. That won't pick the object, it's just a generic equation comparison.

Use the perushyvismelee object's own "Compare private variable" condition.

Also... Megaupload? Bleah. I have to enter captcha, wait 45 seconds, AND look at pop-up ads? You should get yourself a willhostforfood account. It's free, and you can get direct download links.

If hitbox is in family and is contained with sprite, then the contained sprite will be picked whenever the hitbox is picked. Or so it works in theory.

According to my own experiments, not quite...

If you have two (or more) objects in a container, then you have to refer to one of the objects in that container directly in order to pick the others. Since you can't put a Family into the container, you might get weird results.

So you can do a lot of general stuff to your hitboxes by Family, such as setting the speed, angle, test collisions, or whatever... but if you want the Container picking ability you will need to define your condition by using an actual object that is in the container, and not by a Family that any of those objects might belong to.

Hope that makes sense. And of course, now that the subject has been broached I'm sure some dev will pop in and say "Fixed for next build"

This invisible hitbox and visible sprite method just seems like a hack.

I suppose I'm just used to it. I came to Construct through MMF, where it's common practice to do it that way.

At any rate, I read somewhere on the forum recently where one of the developers said they were planning a custom hitbox feature. So who knows, it might be here soon.

And honestly I don't think it's that hacky of a practice. While Game Maker allows you to manipulate the hitbox directly for the sprite, it's really just a matter of convenience (I'm not aware of any other game making software that has that feature). Defining the hitbox with a separate sprite in Construct is the same sort of practice... and has the same reasoning behind it. It's just that it's not as convenient because it happens to be a separate object. In traditional programming it's even more abstracted... you have to define your collision box based on math rather than a visual representation of a box. But essentially you're still making a box, even if that box is made of a few individual coordinate checks.

I can't edit the first post. Am I blind?

You are not blind. There is a time limit on editing posts.

...but first I must finish watching Chobits

Animes? Ugh, David...

Makes difficult things more difficult?

And unpleasant things more unpleasant. And cold. And wet.

Grrrr SNOW!

Awesome

Glad to see this hasn't been abandoned!

Hard to say. As nice as video demonstrations are, you can't really tell too much from them. It would be easier to see your .cap.

Mu guess is that you have the health bar on a different layer that has different scrolling settings. If not... well, like I said, it's hard to say.

Clickteam have pushed me just a little too far this time around.

What was it they did to you?

Bah, humbug. I hate snow

We've had below-freezing temperatures here every night and I'm sick of it. I can't wait for summer. And some day I'm going to live somewhere that's warm all year round, maybe in a volcano or something.