Refresh collision when touching a new actor?

graaplgraapl Member, PRO Posts: 29

Here is a video of the issue I am having.

^There is all the clickable rectangle rules for playing sound on collision.^

I know what is happening, collision rules only update once on the first collision with an actor. The problem is... how do I work around this?

Best Answer

  • graaplgraapl Posts: 29
    edited June 2017 Accepted Answer

    That's a good way of going about it in some instances, but the project you put together wouldn't work for my game. Spawning in a dummy actor would disable all future sounds created by the block because there is the risk of colliding with a shape again, and well... it wouldn't be colliding with the same actor.

    I played around with a couple rules this morning and found one that is almost there! :) It is based solely on the individual actor's speeds. Here is a screenshot and description of the code, as well as a video of the progress.

    As you can see we are a step in the right direction put it's not perfect yet. I'm going to add some more rules so that sound isn't played ten times at once as it did in the video.

    EDIT: Overlapping sounds solved.

    1.) Create an integer game attribute called "SoundsAlreadyPlaying"
    2.) Change your play sound volume equation to

    "desired volume"/game.SoundsAlreadyPlaying

    3.) Add change attribute

    game.SoundsAlreadyPlaying to game.SoundsAlreadyPlaying+1

    4.) Put in timer after changing the self attribute "Moved Significantly" to false
    5.) Set the timer to "After 0.1 seconds" and check "run to completion"
    6.) Add change attribute in the timer

    game.SoundsAlreadyPlaying to 1

    Now overlapping sounds will not be any louder than the sound playing alone by itself! ;)

Answers

  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,949

    I'm confused... are you wanting a collision detection to occur repeatedly or only once? If only once, the setup you have above should work by changing a boolean value and including that attribute condition in the collision rule.

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • graaplgraapl Member, PRO Posts: 29

    The sound should play once, every time it touches a new clickable actor. The current issue is that the sound will only play once when a clickable actor touches another clickable actor (which is great if there weren't multiple actors) however if a new clickable comes in contact with the clickable block already in contact with another clickable block, the sound will not play because that is how collisions in rules work.

    Here is an illustrated guide to what is going on. Take note of the order of events

    P.S. the different colors don't mean anything. They are all the same actor.

  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,949

    Okay, so you want each edge of an actor that collides with another actor to produce a collision condition in a rule. I think I get it now (pictures helped!). As you realize, the standard collision rules won't work for this because once a collision occurs, the actor(s) have to "uncollide" before the rule will detect a collision again. Someone surely has struggled with this before but... it's not me. So I'll ponder it but you'll probably get a better response from someone else here.

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,949
    edited June 2017

    The one thing that comes to mind is a secondary condition or a collision rule within a timer. Something that forces the rule to test the conditions anew.

    Edit: here's a demo. If you slow Actor 1's speed to something like 25, you can see when the collisions are detected (according to the count).

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • RThurmanRThurman Member, Sous Chef, PRO Posts: 2,879

    Instead of only detecting collisions -- you might want to detect abrupt changes in linear velocity. Also try detecting abrupt changes in angular velocity.

    A bounce is nothing but an abrupt change in velocity (either linear or angular). And bounces are highly correlated with collisions! If you can't detect collisions like you want, perhaps you can detect the bounces.

  • SocksSocks London, UK.Member Posts: 12,822
    edited June 2017

    @xD.Enterprises said:
    EDIT: Overlapping sounds solved.

    Not sure how your method worked, but one approach is to have a single sustained sound, and on collision ramp that sound up to 1 and then quickly back down to 0, so even if 4 or 5 actors are colliding at the same time or in close succession there will only ever be 1 sound playing, as they are all just sending info to that one sound to get louder, rather than triggering a new copy of that sound to play . . . .

    Quick rough demo of the idea attached:

  • graaplgraapl Member, PRO Posts: 29
    edited June 2017

    @RThurman said:
    Instead of only detecting collisions -- you might want to detect abrupt changes in linear velocity.

    I described in my latest post that the actors are now detecting abrupt changes in linear velocity. Angular velocity would work great too based on the game. Should've put that in.

    @Socks said:
    One approach is to have a single sustained sound, and on collision ramp that sound up to 1 and then quickly back down to 0

    That's an interesting way of going about the issue. I'm probably going to switch my project to follow that rule. The way I did it before was make sure that all playing sounds' volumes combined never added up over 1. Here is an example of the math.

    2 sounds:
    0.5+0.5=1

    3 Sounds
    0.33+0.33+0.33=1

    Again, I might go with your way because it is much less resource demanding to change variables and play 1 sound than to do it my way and change variables and play LOTS of sounds.

  • SocksSocks London, UK.Member Posts: 12,822
    edited June 2017

    @xD.Enterprises said:
    That's an interesting way of going about the issue.

    You'd probably have to play around with it to get it tuned to your particular project, attached is the same demo as before but with a square wave instead of the white noise the last demo had, with a pitched/tuned sound (like a square wave) you can also play around with the pitch value, in this example the pitch is gently modulating up and down . . .

    Also if you open up the 'W' actor, there's another sound set up called 'Kicks', just switch off the 'Sqaure' Play Sound behaviour and switch on the 'Kicks' Play Sound behaviour, I think that one works ok too . . . what's interesting is that you can use all sorts of sounds for this method, you could have a sound that changes over time, for example a 10 second sound with all sorts of elements fading in and out - and this will give you lots of little hits all with differing qualities . . .

    Hope that makes sense !

  • RThurmanRThurman Member, Sous Chef, PRO Posts: 2,879

    @xD.Enterprises said:

    @RThurman said:
    Instead of only detecting collisions -- you might want to detect abrupt changes in linear velocity.

    I described in my latest post that the actors are now detecting abrupt changes in linear velocity. Angular velocity would work great too based on the game. Should've put that in.

    Great! You can do some simple tests -- like seeing if a falling object suddenly has a near zero or even a positive y-velocity. Or perhaps you can check to see if it's velocity in any direction has decreased significantly from its previous velocity.

    In terms of angular velocity -- has it changed direction from a split second ago? Or perhaps its going much faster, or much slower than from a split second ago.

    All these sudden changes probably indicate a collision has happened.

    You can also test for scraping/sliding and have sound effects for that as well.

Sign In or Register to comment.