Let's say you have a fighting game like Street Fighter (although this would help with TONS of things). You would need two hitboxes: 1 for the player who can get hit and 1 for whichever part of his body is attacking (to register hitting the opponent). Now, to get that accurate, you have to use an image point or create a sprite for each part of his body or an invisible collision sprite for each part of his body. All of these things feel like work-arounds to me.

I propose being able to create more than one collision mask for an object. Extra collision masks would help with melee attacks, complex hit boxes (eg. headshots, bodyshots, etc), or any time you'd want different parts of a sprite to do different things.

You could add a box/option for collision/overlapping events to edit which collision mask you want for "On Collision" and "Is Overlapping" in each case and things like the Platform Behavior could just use the main collision mask (or whichever one you set it to use if that option would be useful).

I don't have time at the moment to create some images and more examples to explain this better and show how useful it would be, but I think anyone could see how this would save a LOT of trouble/time/etc.

If you're swinging a sword in an arc, how about you make a pie-shaped detector like so:

<img src="http://i46.tinypic.com/hvrxmv.png">

Leave it there for the duration of the sword swing animation and check collision against that.

Hmm, that looks like it would work.

Edit: Also, any "Hit before the sword reached enemy" type problems would be solved by making the animation fast (kind of a given) but also delaying seeing the results of the hit until after the animation is finished. It'd be like in an anime where some guy slashes an enemy and then a few seconds later (much shorter in this case) you see him get cut in half.

Edit: Deleted your duplicate thread.

Oh, thanks. I clicked submit then it said I had to sign in, so I thought it didn't post the topic (it went straight to the "Create a Topic" thing again).

So it looks like I have a few options:

1) Use an image point. Good for simple, small sprites.

2) Create a second sprite for the weapon.

3) The animation is just for show, but distance determines if it hits.

I'm liking number 2 the most as it seems like it would have the most "correct" collision (hitting when the weapon actually hits), but I don't know how vsync affects things. Would "Is Overlapping" solve vsync problems as it would be overlapping for a longer time than just a single collision detection?

Edit: What if each frame of the animation is held twice? That would give it a better chance to register right?

Edit 2: Would setting a fixed framerate help with the vsync thing?

I've been wondering lately how to do melee weapons. In Castlevania, the weapon (during the attack animation) has its own hitbox. I'm sure I can't have two collision masks on one sprite at the same time, so do I have to make a seperate weapon sprite? That sounds like a lot of extra work to make them look/work like one sprite and all that. Any help is appreciated.

I don't think you'd even need to rotate the player for slopes. I think the normal method is to simply have the player sprite overlapping the slope slightly without changing angle. It is simple and effective.

Construct 2 will probably not be out (in a usable semi-stable beta version) for years huh...

I want him back so he can help with my platform woes

I was referring to the 3D box bug where boxes that are not overlapping or contained in the original screen resolution area do not appear but can still be interacted with.

I think people should focus on learning the software as it is and making good games, not getting blinded by shiny things.

The software isn't even finished and besides, adding new things is not necessarily a bad thing. If everyone should be learning the software as it is, does that mean people should not have created new plugins/features? Plenty of new features have been added to Construct and they are extremely useful. There are quite a few third party plugins too. They only make Construct better. What about all those Effects? Are they so bad?

3D is not just some shiny thing. It could save people a lot of time in many cases. That time could be reinvested in higher quality gameplay. VRAM is a real issue too. Some things really ARE limited by VRAM. Besides, a better looking game will always be taken over a game that is not as good looking if their gameplay is the same. 3D objects would open up countless possibilities to make better gameplay too.

For the record: some big expensive commercial 3D games do have problems with moving platforms.

I've seen lots of jittery elevator sequences, for example in EA's Mirror's Edge you kind of sink into the floor while going up. In Pandora's Box (using Epic's Unreal Engine 3) there's a terrible bug where if you're doing over 60fps you go through the floor of the elevator right at the end of the game. There's lots of them so it seems there is no widely known perfect solution.

2D is entirely different than 3D. I don't think you can really compare them with something like this. I'm thinking more like 2D Mario.

Edit: Just remember I'm not a programmer...

What kind of fixes were being included?

Have 3D boxes been fixed?