LifeInAnEgg said:
You're getting a bit off topic, here is the code that I use (on frame 1 of the character_mc timeline:



r

Hope this helps

Holy dang, that's an awfully efficient language. Just the letter "r" does all your hit testing for you?

r

Hope this helps

Maybe I should also start with that.

http://www.harveycartel.org/metanet/tutorials/tutorialA.html
They know a way to do 'perfect' hitTesting, but it's hard as hell...
And about your issue, Chad is rite, methinx.

The vectors, they burn <_<. I really should try and get my head around them soon since I'm studying a games course at university XD

As for the shell clips, are you talking about how elements inside a MC have their own x and y coordinates with respect to their parent movieclip? And how calling the _x property of that nested MC will return the same value even if you move the parent MC?

You could always use the function localToGlobal to change the local x and y coordinates of a nested movieclip to global ones.

If that's not what you mean by shell clips, then ignore that

Keeping stuff in clips is a good idea, especially when you can hitTest for those shell clips, but NEVER move those shell clips.

Move root, then set your HUD to -_root._x. Well, have a rootX value (_root._x and _y seem to slow everything down if you're calculating or tracing them), do your calculations on that first, and then set _root._x to rootX and HUD._x to -rootX.

with (_root.enemies.enemy1) {
if (_root.lev.plat.hitTest(_x, _y, true)) {
stuff
}}

That's not the exact code I used, so if there's a typo, just ignore it.

I've read that hitTesting is not very CPU friendly, which really sucks because it's like the most used function in Flash (you know, besides stop() and play() ). You'd think they would've done something about that. And Nyubis, doing anything perfectly is hard as hell.

I figured it was something like the _x and _y positions is different if it's in a shell clip, but I wasn't sure.

So you say to move the root? That mean I would have to move my character, health meter, etc in the opposite direction as the level? And then put all the enemies on the root, right? That would be a change for me, since I like to keep everything organized, with everything in one clip, categorized into separate clips based on types. But if that's what I need to get it working, I can do that.

Don't move your shell clips, move your root. When you move a shell clip, the values of the stuff that's inside stay the same, but the positions are different. You would have to hittest _x + _parent._x (or something like that) to hitTest the correct point, but I wouldn't bother with that until you're REALLY comfortable with the concept of shell clips.

And about your issue, Chad is rite, methinx.

Or it could be you've got something very small and very far away inside the enemy MC making it's bounding box a lot larger than it should be?

I've always seen hitTesting as one area that flash fails epically in. That shape flagging thing seems to make CPU usage go through the roof <_<

I'm trying to code an enemy that's affected by gravity, but for some reason the hitTesting is way off. The way I have everything set up is one MC that holds all the level stuff including the enemies, a MC in that containing the platforms, and another MC in the main one that contains all the enemies. Then I move the main level MC around to create character movement.

When I try to test the enemies against the platforms, the hitTest returns true even when the platforms and the enemy aren't even close to each other. Has anyone else had this problem with hitTesting?