Triggers in loops

0 favourites
  • 12 posts
From the Asset Store
For Adventure, Action, Heroes, Sci-fi and Action-RPG games.
  • I have this basic scenario for my game:

    For Each Enemy

    -- Find Path

    -> On path found | Move on path

    "On path found" is, of course, a trigger.

    Can someone explain to me why a trigger doesn't work inside a loop like this?

    I'm finding I have to be very careful with my For Each usage (and sometimes finding it's even redundant...). So if I could get some clarification, that would be wonderful. Thanks!

  • A trigger happens sometime in the future, you don't know when. It could be in a tick, it could be in X seconds. Since you are calling Find path, then immediately checking the trigger condition, the chances of the trigger being true within that time are pretty much zero. You need to move your trigger outside of the For loop, so that when it occurs sometime later, it can be processed and your Move on path called.

  • When a trigger fires, it must check all its parent events are true before it can fire, so triggers in subevents work properly.

    If 'For each enemy' is a parent event, when firing 'On path found' it has to check if 'For each enemy' is true or not. It doesn't really make any sense to ask this, because it's a loop - a flow control condition, not a true/false condition. So I think in this case the engine simply returns false and doesn't run the trigger.

    Why would you put a trigger in a subevent to a loop anyway? What are you hoping it would do differently to being a top-level event?

    You may even not need the 'for each' for the 'find path' action, since the engine has a built-in for-each to run actions on every instance that meets the event's conditions. You only need an explicit 'for-each' condition when what the engine does automatically isn't enough.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • blackhornet - Aye. In my learning and testing, I've found that to be more so the case than not. In trying to isolate a larger problem I'm facing in developing my enemy behavior mechanics, I'm presently attempting to isolate and identify where things work and do not. At one point, I did have the "On path found | Move along path" event set outside the whole series of events and loops that controlled enemy movement. I switched it inside the loop(s) just to test some things...

    Ashley - Thank you, sir! :) Someone newt shared with me a short tutorial on how For Each loops work, so now I'm trying to better implement (or remove) the use of them. My question here is simply trying to better understand the limitations of the functions that the loops have. Kinda like asking, "The rocket fires up...that's its function. But what's its limitation? How FAR UP can it go?" Hopefully that makes sense.

    Your point that For Each has no true/false factor is one such limitation (or quality, I guess) that makes things much clearer for future reference.

    Ultimately, what I wanted to ensure happen was that ONLY each instance whose path had been found would actually move along the path. This was before I fully/better understood how For Each works. I had previous implementations of my enemy behavior that had multiple instances moving when maybe only one or two should have done anything. That led me to thinking I needed For Each regularly...apparently not.

    ...Hmm...would it help if I shared my capx?

  • A CAPX is always the fastest way to get help. Just be clear what you want.

  • blackhornet - LOL Trying to be, truly. But as you can see, I can already say a lot when I'm trying to be brief. Anyway, here's the capx.

    sugarsync.com/pf/D6025908_4317202_6840595

    Look for event sheet "ES CharEnemy", starting particularly at line 17, though lines 13-16 also factor into things.

  • Sorry, it's still not clear how your game works, and what is broken. I'm also not seeing the Pathfinding mechanism there, that you started this thread with.

  • blackhornet - Hmmm...

    Well, a friend helped me identify one problem. I had quotation marks in the Properties field for one of my variables. So the editor was literally looking for ""String""... Heh. I'm going to look things over from there and see what I can resolve from there.

    But the short explanation goes like this:

    PATROL: Find path between designated PatrolNodes.

    CHASE: Find path to last known location of Player.

    ALERT: Find path within a radius from last known location of Player, search randomly for a brief time.

    RESUME: After some time has passed, if Player is not found, return to nearest PatrolNode and resume PATROL status.

    That's basically what's supposed to happen. Does that help at all?

  • I didn't get that far, but there is some pathfinding working.

    OpPASS v1-1-4_BHT_PF.capx

    I did have to change the PF Cell Size, as it was too big for your narrow paths.

  • blackhornet - Dude. Stunningly amazing! I'm still looking it over, but I think I've kinda got the gist of what you've got going on. But I'm confused on one part.

    Line 39...

    Pick Node by evaluating NodePatrol.UID <> Enemy.CurrentNP

    What in the world is the " <> " bit? LOL I've never seen that before.

  • blackhornet - Dude. Stunningly amazing! I'm still looking it over, but I think I've kinda got the gist of what you've got going on. But I'm confused on one part.

    Line 39...

    Pick Node by evaluating NodePatrol.UID <> Enemy.CurrentNP

    What in the world is the " <> " bit? LOL I've never seen that before.

  • "<>" not-equal. If you stop and say it out loud, it makes sense: is A less-than or greater-than B? If so, then it can't be equal.

    scirra.com/manual/78/expressions

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