GameSalad

Can't stop colliding whilst still colliding

imjustmikeimjustmike Posts: 450Member, BASIC

Run into an interesting quirk. I've got a hero actor that is able to stand on top of a box for a limited amount of time before the box is destroyed. For various reasons (partly involving triggering an animation, and keeping a remnant of the box) I don't want to use the destroy behaviour.

I was hoping that I could have a self attribute called self.destroyed and a rule that says when self.destroyed is false, collide with hero, else nothing.

Unfortunately this doesn't work as I'd expected. If the hero is on top of the actor when it's destroyed, it continues to collide with the box, which, given an animation shows the box being destroyed, makes it look like the hero is floating. Though, if he stops being in contact with it, the rules seem to kick in and the hero can walk through the box.

I was hoping the hero would simply fall down when the self attribute is triggered. Does anyone know why this isn't the case or can think of any workarounds?

My last ditch resort will be to use a combination of destroy and spawn behaviours, but I'd rather not do that as it'll make some other things quite tricky in other areas of the game (tracking positions, scene resets using tables etc).

Comments

  • IceboxIcebox Posts: 1,390Member, PRO
    edited June 14

    It has something to do with the collide behavior,

    Here are 2 examples to get a better picture , scene consists of 4 actors , button to set collision on and off , ground actor , box actor , player actor,

    Button - No collide behavior with Player
    Ground - No collide behavior with Player
    Player - No collide behavior with anything
    Box - if game.collide is true - Collide with actor player

    It will work as you expect

    Now i placed a collide behavior in the player actor Collide with ground and the thing you mentioned happened , the rule kicks in when they are no longer in contact. I had to jump for it to detect that there is no longer a collision

    This also happens if i put a collide behavior on the ground and set it to collide with player , or if i put a collide behavior on the button and set it to collide with the player. So nothing should collide with the player for it to work as you expect, and the player should not collide with anything. This wont be possible in a platform game cause the player needs to collide with the ground.

    The workaround is to place the collision rule in the player instead of the box , you can work it out with a game attribute , if game.destroy is true do nothing otherwise collide with actor box.

    I dont know if this made sense but hope it did :)

    Edit: im not sure of all this , its just based on testing, maybe someone else have a better solution or explanation to this.

  • imjustmikeimjustmike Posts: 450Member, BASIC

    Ah right, so isn't just me then!

    That's a shame, but I have a slightly hacky workaround instead of using global attributes (I'm going to have lots of boxes and keeping track would be annoying). When I want the collision to stop happening, I simply shrink the box's height by 2 pixels, forcing them to not be contact for a split second :)

    When combined with images and animations it's barely noticeable. A very rough prototype with destructible box:
    image

    I'll keep playing to see what else I can come up with.

  • ValanValan Posts: 371Member, PRO

    Yes, it's the size of the Actors box rather than the image inside. With a circular collision GS uses the smallest dimensions to gauge the collision circle. The Custom option loads in a file that can be an alternative shape to a rectangle or circle.

    Have you tried invisible collision shapes that coordinate with separate animation Actors?
    A bit more organising but quite straight forward. The boxes can be visible for dev and then turned invisible when finished.

  • IceboxIcebox Posts: 1,390Member, PRO

    @imjustmike Ah your right , its better to do it this way in your case , btw i love your animation its really smooth , looking forward to seeing more :)

  • imjustmikeimjustmike Posts: 450Member, BASIC

    @Valan said:
    Yes, it's the size of the Actors box rather than the image inside. With a circular collision GS uses the smallest dimensions to gauge the collision circle. The Custom option loads in a file that can be an alternative shape to a rectangle or circle.

    Have you tried invisible collision shapes that coordinate with separate animation Actors?
    A bit more organising but quite straight forward. The boxes can be visible for dev and then turned invisible when finished.

    I'm not sure I follow. This collision quirk happens even when the actors don't have artwork, @Icebox has some super useful gigs to highlight the issue. The reason I change the size is to break contact between the actors and allow the collision behaviours to fire again.

  • imjustmikeimjustmike Posts: 450Member, BASIC

    @Icebox said:
    @imjustmike Ah your right , its better to do it this way in your case , btw i love your animation its really smooth , looking forward to seeing more :)

    Thanks buddy! It's still prototyping stage the moment but if I reckon there a game worth continuing with I'll be sure to post some more screenshots. Though I do have just under 100 half finished games now.... Oops

  • SocksSocks London, UK.Posts: 12,700Member, PRO
    edited June 15

    @imjustmike

    Great zombie walk cycle animation ! :)

    If I were you I would kill off the solid crate (and its associated collision area) and spawn a new actor for the crushed crate (with a new smaller/lower collision area), then the character would drop down onto the newly crushed crate (and would be free to walk off it left or right).

    P.S. I like the little leg/knee bounce when he lands on the crate.

  • imjustmikeimjustmike Posts: 450Member, BASIC
    edited June 15

    @Socks said:
    @imjustmike

    Great zombie walk cycle animation ! :)

    If I were you I would kill off the solid crate (and its associated collision area) and spawn a new actor for the crushed crate (with a new smaller/lower collision area), then the character would drop down onto the newly crushed crate (and would be free to walk off it left or right).

    P.S. I like the little leg/knee bounce when he lands on the crate.

    Thanks! Your animation tied to a rotating actor really helped :)

    The game is one where you move objects around to solve a puzzle, very loosely similar to TIM (the incredible machine, if you ever played that) but with the twist that you can control the character too. At the start you get a set number of different blocks to play with, and if you fail it gets reset. I'd rather not reload the scene, and the simplest way I can think of is to have a reset rule in the actor which moves the blocks back to their starting position (and in the crate's case, changes their image). If I destroyed the crate I'd have to spawn new actors, which isn't the worst, but I want to be able to have a soft reset, so if a player fails, they can try again without having to reset the blocks position (for example if they missed a jump).

  • BBEnkBBEnk Posts: 1,700Member, PRO
    edited June 15

    Is this what your trying to do.

  • imjustmikeimjustmike Posts: 450Member, BASIC

    @BBEnk said:
    Is this what your trying to do.

    Not quite, thanks though. I'm looking for the actor to stop colliding completely. Unfortunately this isn't possible as you can't change the collision of two actors that are currently colliding. My work around is to shrink the box by a couple of pixels, forcing the the actors apart and allowing the new rules to kick in. It's a bit hacky but does the job.

  • BBEnkBBEnk Posts: 1,700Member, PRO

    I think I see now, like this maybe lol.

  • The_Gamesalad_GuruThe_Gamesalad_Guru Posts: 9,881Member
    edited June 16

    If you use my custom collision shpe animation technique you can have robust animation collisions and avoid using circle or square options. Also I would try putting the collision rule in a loop to jump the scan and get the change to be acknowledged faster.

  • imjustmikeimjustmike Posts: 450Member, BASIC

    @BBEnk said:
    I think I see now, like this maybe lol.

    That's interesting. Why does it work when the collide rule is in both the hero and the box, but not when it's just in the box?

  • imjustmikeimjustmike Posts: 450Member, BASIC

    @The_Gamesalad_Guru said:
    If you use my custom collision shpe animation technique you can have robust animation collisions and avoid using circle or square options. Also I would try putting the collision rule in a loop to jump the scan and get the change to be acknowledged faster.

    THANKS, I'll check it out

  • BBEnkBBEnk Posts: 1,700Member, PRO

    @imjustmike said:

    @BBEnk said:
    I think I see now, like this maybe lol.

    That's interesting. Why does it work when the collide rule is in both the hero and the box, but not when it's just in the box?

    Actually I meant to delete the box rules. funny it still worked fine with or without.

Sign In or Register to comment.