I essentially want a platform object whereupon a character can jump from underneath and not collide (platformer character goes through it), but when you are jumping from above, it collides with it, stopping you from falling.

Is this possible without having to pull up my sleeves and create my own plugin?

I get that it's probably possible with events on a single-player game, by turning off the Solid behavior when the character is under it, but it would affect the other sprites that are on top of it, no?

This is not actually urgent; it's more of a curiosity of mine.

Cheers.

There are ways to do it with workarounds (possibly by using UID), but I think it'd probably be best to wait for families to come out.

Alternatively, you could create your own ID-based system, where you have each having an instance variable (ZombieHead.Number and ZombieBody.Number), then check the number of the head when it's destroyed, and subsequently destroy the body which contains that same number.

a game where you punch and kick the bad guys

To answer #2, you can actually go into the source code and remove all values of deltatime, and then release it as a separate plugin. It shouldn't really be that difficult.

I'm not really sure about the scale rate, though. I haven't used it overmuch, but I haven't seemed to have trouble with it.

You are going to have to do collision detection manually in events, which is quite annoying.

Essentially, you should do some reading about how collision detection works, but basically it detects whether an object has collided with another, and then checks if that object has a solid attribute, and then pushes it back to the last position it was at. Alternatively you can calculate whether or not the next movement will collide (in the next frame), and have the main character not move in that direction.

You can confirm the sprites are where they say they are? Perhaps try copying them to another folder, then adding them back in manually.

Apologies for not searching in the past few days on the forums, Ashley.

I agree that you can use separate sprites and used the collision on those (which works), but it just doesn't seem to have the 'finesse' that multiple collisions on a single object would be. Also it gets messy when you duplicate a single object lots of times (though that should be solved with Families).

I wouldn't imagine the UI would be finicky at all; it'd be very similar to the ImagePoints window, where you can create a new one, give it a name etc. The major problem, however, would be behind the scenes (does this collision stop on Solids, etc).

It'd probably be pretty processor-intensive if used ridiculously, but I think there's a real market for having multiple collisions on sprites, but be able to 'tag' the collisions (or at least give them numbers), so a collision check can be made by a collision's number or tag within a sprite.

For example, in a fighting game, you would want a general collision box around their body, then individual ones (hands, feet, torso, head), to check what part of what person attacked the other.

At the moment, doing that check manually is pretty brutal.

I think it might come in handy for lots of projects, and wouldn't be growing on the current collision system that much.

Note: I don't actually need it for a project I'm currently working on, so don't stress yourself. It's just a friendly suggestion.

Yeah I figured as much. I think it's just to do with the fact that at such small scales, individual pixels matter.

I looked through the code to see if I could make it more forgiving to obstacles, but it was more like I was stabbing around in the dark. I'll just make the resources bigger.

Anyway, thought I'd let you know about the limitations (if it can even be called that).

Thanks.

Edit: I got it to work really well by speeding him up. That's really all you need, at the end of the day; speed.

Hey man, don't knock the 4850 and 4870 series of cards; they were the cards back in 2009. They're still not terrible by any means.

I think it's perhaps because Chrome doesn't utilize the GPU as much as it possibly could that leads to this problem.

I think it happens when you are pressing a direction, and the frame skips, and it 'remembers' that movement state, and keeps walking in that direction.

I have the same problem on a 4870.

The way to fix it in-game is quite simple; walk in the direction your character is walking, and it will reset.

To fix the actual bug? I'm not so sure.

The capx is probably not really needed, because it's just using many of the default behaviours (Platform + Solid)

Here is a quick game that I mocked up to show the problem.

And the .capx to show how it was done.

The problem is when the main sprite goes on an angled platform, which gets him 'stuck'.