I must be doing something wrong (or local attributes are busted)?

hillelchillelc Member Posts: 56
edited October 2012 in Working with GS (Mac)
I have an actor on my screen which is set to accelerate towards and beyond two obstacles (which are also on the screen). Each obstacle is a completely separate actor. Both actors have a custom local attribute called "block". I have a rule in each obstacle that says: "When you "block"=true Collide with the moving actor. In other words, while the block local attribute is true, don't let the moving actor accelerate past the obstacle actor.

Here's where it gets weird. For each obstacle actor I have it set up so that an action in the game will change their local "block" attribute to false. In other words, let the moving actor go past them. But there's some weird linkage between the two obstacles even though they are COMPLETELY SEPARATE ACTORS. In my game the moving actor won't pass either until the local attributes in BOTH obstacles are set to false. I tried to repro it in a separate project and got the same results. In the demo i've posted I have it set so that clicking on the red obstacles changes the BLOCK local attribute to false. I've also set debugging statement and everything looks good.

Are there weird issues with using local attributes? Or with the collide behavior?

(I posted the file here if anyone wants to take a look: http://wikisend.com/download/525650/collisiontester.zip)

Comments

  • carlblanchetcarlblanchet Member Posts: 755
    edited October 2012
    I managed to get this working, and I modded the file.
    Download here:
    http://www.2shared.com/file/0m89zY6L/collision_testergameproj.html
    I left the barrier 2 actor in there, although it is simply an exact copy of barrier 1, therefor having simply barrier 1 does the trick.
    If you need further information about it, let me know.

    Cheers.
  • RThurmanRThurman Member, Sous Chef, PRO Posts: 2,881
    The game certainly gives the illusion that it is the attributes that are the linking factor. But the local attributes are definitely not linked. You can prove it for yourself if you click the first barrier before the player has time to 'bounce' off of it. If you click fast enough, the player will pass right through as you expect it should.

    The way things are set up is causing a strange interaction between the collide behavior and the engine already detecting that a collide is happening. (One of those chicken or egg things -- I suppose.)

    I wouldn't endorse putting a collide behavior inside a true/false rule like that. It's going to give some puzzling results.

    If you insist on doing it that way, you might want to give your actors some bounce so the player is not touching the barriers when they get clicked.
  • hillelchillelc Member Posts: 56
    Thanks @carlblanchet. But that actually doesn't solve my problem as in my game I need barrier 1 and 2 to be completely separate actors, not instances of the same actor.
  • hillelchillelc Member Posts: 56
    @RThurman, I don't insist on doing it this way. I'm happy to do it a different way, I'm just not sure how. I need to make it so that the obstacles sometimes block the other actor, and then at one point don't. And it needs to happen on a per actor basis. Do you have an alternative suggestion on how to approach this?
  • carlblanchetcarlblanchet Member Posts: 755
    edited October 2012
    @hillelc Well that is exactly how they are set up in the file that I changed up.. sooo kk lol
  • hillelchillelc Member Posts: 56
    Ah. OK. Sorry, I thought you meant they were both instances of the same actor. I'll check it out. Thanks.
  • carlblanchetcarlblanchet Member Posts: 755
    edited October 2012
    They currently have the same rules in each is what I meant, and can be customized by adding the required rules in each. :)
  • hillelchillelc Member Posts: 56
    Thanks. You certainly made it work. It looks like you did two key things: 1) you put the collide behavior in a timer, and 2) you created a layer of indirection by using an additional actor attribute. Is that so? I get that it worked and appreciate that. But I have no idea why it worked. Would you mind educating me on why you did those things?
  • carlblanchetcarlblanchet Member Posts: 755
    edited October 2012
    Ok.

    So the barrier actor has a boolean self attribute (name: block) and an integer self attribute set to 1 (name: blockkk). (Feel free to rename them lol)
    (Boolean = true or false) (Integer = a number. 1, 2, 3, etc.)

    In the rules are:

    ~TIMER - every 0 seconds~
    ~If attribute self.block is true~
    -Collide with Player-

    ^^This timer assures that it checks if that attribute is true to collide every 0 seconds, meaning always.

    ~WHEN TOUCH IS PRESSED~
    -Change attribute self.blockkk to (self.blockkk+1)%2-

    ^^This is when the barrier is pressed change blockkk from 0 to 1 to 0 to 1 to 0, etc.

    ~If attribute self.blockkk is 0~
    -Change attribute self.block to false-
    -change colour to green-

    ~If attribute self.blockkk is 1~
    -Change attribute self.block to true-
    -change colour to red-

    ^^This changes the block attribute from true to false from the click of the barrier. When block is true it collides when false it doesn't.

    I did, for a while, try playing with the use of one integer attribute instead before involving the boolean but it did the same glitch u had. So the boolean attribute allows it to take away the glitch by checking if it collides or not by taking the info from somewhere else.

    The 'Actor 1' is simply there so that when the player actor overlaps with it the scene resets.

    Best of luck with the rest.
    Cheers.
Sign In or Register to comment.