Strange family movement behavior

This forum is currently in read-only mode.
From the Asset Store
Strange Game Ambient Loops 3 - This is the third volume in the Strange Game series.
  • In this cap, the desired behavior is that the skeleton walk straight forwards until it hits the edge of the platform, and then turn around. Each skeleton SHOULD do this itself, ignoring the others.

    What ACTUALLY happens is that as soon as one skeleton hits the edge, they ALL turn around and go the other way, in sync.

    I'm told that my code should work. So what is going wrong?

  • How about this?

    When using objects or families in condition that you want to alter, you have to carefully define the conditions. "Else" picks all objects that have met the condition but haven't met the subsequent condition, i.e. the skeletons that are moving into the same direction.

    Just negate the "is overlapping?" condition and it'll correctly pick the one only, thus change its angle.

  • But SHOULD else work that way? Especially when there's the for each object! Isn't it a bug? (Haha next ashley is going to say it's just how construct works and then Dave says it's bug after all, like last time... never mind, just joking ;D)

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I -think- I understand what you're saying. I think it's bloody unintuitive, since I'd rather construct deal with one member of a family at a time, but I think I understand. Thanks for the help! I may disagree with how it works, but this is how it works, so I'll have to live with it.

  • Let's go step by step...

    We have 10 skeletons, the game checks their angle each tick. Say at the tick 3581 there are currently 5 skeletons facing right.

    Okay, five skeletons have angle of 0, so those are picked. Next, we check for those skeletons if there is terrain 10 pixels away from them. Four skeletons meet that condition, so they move at set speed.

    Now, there is ELSE condition, which picks CURRENTLY PICKED skeletons. Those are the ones that match the desired angle, so it turns them all, no matter whether they met the terrain overlap condition or not.

    We want it to pick the skeletons that have no terrain ahead of them, so it picks THOSE skeletons. Thus, we have to make it an exact condition: Is NOT overlapping terrain at offset. That correctly picks the one skeleton who is about to fall off and turns him around.

    If you have a clear idea which instances should be picked at any moment, it makes things easier ELSE doesn't pick anything, the PARENT condition picked instances are counted here. Perhaps if you kept the ELSE and added the "Not overlapping terrain at offset" condition there, that would work, as it would properly filter picked instances. But in this case, ELSE is not necessary, as we already have a condition that filters the stuff.

    I hope I have been clear enough

  • I know that, but the for each loop there should ELIMINATE that; it sould test them one at time, separately. I am not currently on my own comp so i can't see the cap but I think there was a for each loop? I'll check it later...

  • Um, there is a bug with families in the current build.

    Not sure exactly whats wrong with it but I know families aren't detecting other families.

  • it's bug after all, fixed next build Else now restores the Selected Object List to its parent's, making this example work as expected.

  • Wow, I have cleary some insight how Construct should work ;D

  • I remember I had that problem and I was supposed to put it on the tracker......

    opps I knew i forgot something in that end of semester rush to get everything done.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)