Ha, no worries it's pretty much a guessing game for me too at this point. I realized this would be hard to diagnose without seeing the .capx but it's a massive .capx so I didn't want to have people sifting through lots of unrelated code to try and find one problem.

Anyway, yep, the amount of objects remains the same. I didn't realize it's possible to have a layout keep going after switching away from it, I figured it's automatically paused when that happens.

Not really sure where to put this, perhaps it's a bug of some sort but I can't seem to reproduce it outside of my project so I'm wondering if anyone's ever had a run in with something similar.

I have sprites that use Pathfinding and Persist, and after changing layout and coming back, they stop moving. However they don't register as actually stopped by the Pathfinding - after running some checks it seems they're meant to be moving, but for some reason are just stuck in place. Running events to make the sprites move along path will sometimes nudge them along a little at a time. I haven't been able to reproduce this in e.g. the RTS template so I'm not sure what's up. Any ideas what might be causing the hangup? A runaway loop maybe?

Nice! Looks to be working now, thanks!

I hope this capx illustrates it best

https://www.dropbox.com/s/nyj4ka0uyuzew4n/interception-layout.capx?dl=0

Clicking one of the green spots makes the blue arrow lock to it. When locking blue arrow will always turn towards sprite that it's locked to. After switching to layout 2 and then back to layout 1, blue arrow no longer turns towards the sprite it was locked to. It seems lock is lost despite having Persist behavior?

Hey, me again with another issue to report: this behavior doesn't seem to be supported by Scirra's Persist behavior. Switching layout causes objects to lose their lock.

Quick workaround (if using Lock by UID) is to have the target UID saved in a variable and re-lock on start of layout, but I just figured it'd be nice to have it supported by Persist if possible. Cheers!

That's the idea, but since it's still all tied to one and the same obstacle map I don't think the path cost thing would help either.

You can set the Pathfinding obstacles to Custom in its parameters and then add obstacle types through events instead of setting it to Solids.

Unfortunately Construct 2 is only capable of supporting one obstacle map at a time for its pathfinding behavior, so I don't think it'll work in the way you intend it. Barring that maybe you can also do something by adding/removing path cost to certain obstacles, but I'm not sure if that'll make any difference in the long run.

Just go to File -> New and look up the turret behavior tutorial.

Well I tried that originally, but as it turned out it just isn't doable currently. C2 only has one obstacle map per layout for all objects that use Pathfinding behavior, i.e. they will all avoid the same obstacles. For example if I set

[Object A avoid X]

[Object B avoid Y]

... both A and B will avoid only X (because it came first). If I set B to regenerate its map then both A and B will avoid only Y.

My workaround just contains hidden barriers that are impassable/high path cost. It works, but I feel it's limited in its scope, hence I was wondering if it's possible to have multiple maps.

I recently found out that C2 only has one obstacle map for all the pathfinding behaviors on the layout, meaning you can't have two different objects avoiding different types of obstacles. No problem, I thought, maybe I can jerry-rig some workarounds using other behaviors, path cost, etc.

Anyway, everything is working well enough, it's just that it took more work than I expected, and I think I lucked out because my project isn't very complex at all. All the hassle could've been avoided easily if only I'd had just one more obstacle map, so obviously I was wondering, how system-intensive would it be for the Pathfinding behavior to have 2-3 obstacle maps to choose from?

Every object having its own personal map sounds taxing, but what I had in mind was maybe an extra parameter in the behavior, a drop-down menu where you can select "Map 1", "Map 2", "Map 3", etc. This way you can at least have different groups of objects avoiding different obstacles. Or is having even 2 maps too intensive?

Seems like a really cool effect, but can it be used with a transparent background? I can see it being a neat way to make e.g. an object "turn to dust and blow away in the wind" as a kind of transition effect, but in the live demo it seems as if the object is only being distorted and wouldn't completely disappear.

Edit: nvm, finally managed to get it working with transparency, not sure what was up earlier. Nice effect, would support a full release.

Animation frames are only saved if there's a sprite object that has them. Of course this includes unused animations and sprites, so if e.g. you have a sprite with the animation that isn't on the layout but is still in the Projects bar then the animation is still included. If the animation frames aren't anywhere in the project then they're discarded.