The Daily Click ::. Forums ::. Klik Coding Help ::. Embedded detection hitbox not working with fastloops?
 

Post Reply  Post Oekaki 
 

Posted By Message

Eternal Man [EE]

Pitied the FOO

Registered
  18/01/2007
Points
  2955

Game of the Week WinnerHero of TimeLOL SignI am an April Fool
16th May, 2012 at 16/05/2012 01:39:49 -

Hi!

I usually do hitboxes for active objects acting as backdrops, but I just noticed that regular collision detection on those hitboxes doesn't work during fastloops, i.e when checking for a collision between a detector(active) and a hitbox(active).

At the top of my events I have my actives set up to change animation direction to the hitbox one, and at the bottom to restore the animation direction. The fastloops being called do all take place during the hitbox animation direction, but collision detection with the actives register using the mask/restored animation direction, how come?

I believe this used to work earlier, am I wrong?

Does anyone have any clue on how to solve it without using invisble doubles for collision detection?

//EE

 
Eternal Entertainment's Code'n'Art Man

E_E = All Indie


...actually Ell Endie, but whatever.
Image
Image

Sketchy

Cornwall UK

Registered
  06/11/2004
Points
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
16th May, 2012 at 16/05/2012 02:48:08 -

Embedded detectors do work with fastloops, but there's no way to tell what the problem is without a file.

 
n/a

Chris Burrows



Registered
  14/09/2002
Points
  2396

GOTW WINNER OCT. 2011
16th May, 2012 at 16/05/2012 03:51:49 -

Sounds like you aren't testing for a collision from within the fast loop.

When a fast loop runs, MMF won't process any of your other code until the loop is over. This is what you need:

On Loop
+ Collision between Object A and Object B
THEN Whatever

 
n/a

Eternal Man [EE]

Pitied the FOO

Registered
  18/01/2007
Points
  2955

Game of the Week WinnerHero of TimeLOL SignI am an April Fool
16th May, 2012 at 16/05/2012 12:20:43 -

I'll experiment and if I don't solve it I'll post a specific file with the problem. Thanks for the input!
Cheers
//EE

 
Eternal Entertainment's Code'n'Art Man

E_E = All Indie


...actually Ell Endie, but whatever.
Image
Image

Eternal Man [EE]

Pitied the FOO

Registered
  18/01/2007
Points
  2955

Game of the Week WinnerHero of TimeLOL SignI am an April Fool
16th May, 2012 at 16/05/2012 13:38:02 -

Ok, I made an example with the specific situation and problem, have a look and say what you think. Pixelthief gave a thorough explanation on the root of the problem, but I recall this working earlier. Opinions?

http://www.mediafire.com/?ioqoiu1u4s1r2o6

Cheers
//EE

 
Eternal Entertainment's Code'n'Art Man

E_E = All Indie


...actually Ell Endie, but whatever.
Image
Image

Sketchy

Cornwall UK

Registered
  06/11/2004
Points
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
17th May, 2012 at 17/05/2012 16:05:39 -

You're doing things backwards from how I was expecting. I always have the player's detector change, but the scenery stay the same, and that always works fine, which is why I know it can be done.

It makes me think that it must make a difference whether you test for A overlapping B, or B overlapping A, and that does seem to be the case (under normal circumstances, if A overlaps B, B must also overlap A).
In theory, you should be able to check if the Hitbox overlaps the Detector, rather than the other way around, but in your specific example that doesn't seem to ever detect an overlap - which is strange.

To see what I mean: http://skydrive.live.com/redir.aspx?cid=b1e7ee094271bbda&resid=B1E7EE094271BBDA!522&parid=B1E7EE094271BBDA!131

If we check for the HitBox overlapping the Player, it uses the correct direction.
If we check for the Player overlapping the HitBox, it uses the visible direction (so it changes depending on whether you pressed space).

 
n/a

Pixelthief

Dedicated klik scientist

Registered
  02/01/2002
Points
  3419

Game of the Week WinnerWeekly Picture Me This Winner!You've Been Circy'd!VIP MemberI like Aliens!Evil klikerThe SpinsterI donated an open source project
18th May, 2012 at 18/05/2012 03:35:06 -

I did an explanation of it on the CT forums for anyone else who was interested;
http://community.clickteam.com/showthread.php?t=71051&p=525353&viewfull=1#post525353

Basically, MMF2 generates a collision mask just once every frame loop, and tests against that when looking at collisions for objects. The object being tested will use its 'current' collision mask, while it will be tested against an 'old' mask that hasn't been updated since the start of that eval loop. So you can test A against B if A changes, but not B against A

 
Gridquest V2.00 is out!!
http://www.create-games.com/download.asp?id=7456

Sketchy

Cornwall UK

Registered
  06/11/2004
Points
  1970

VIP MemberWeekly Picture Me This Round 43 Winner!Weekly Picture Me This Round 47 WinnerPicture Me This Round 49 Winner!
18th May, 2012 at 18/05/2012 13:19:34 -

Yeah, I did figure it out in the end - it's fine if either one object or the other change position/animation/etc, but not both at the same time

 
n/a
   

Post Reply



 



Advertisement

Worth A Click