This may be a bug. Do you have an example project I could use as a reference to fix it?

https://www.dropbox.com/s/ufmjkaosihbjf3s/Spine_BB_Test_3.c3p?dl=0

Hope this helps. Thanks!

Are the Spine-defined Bounding Boxes supposed to scale with the rest of the sprites? I am trying to use the Spine bounding boxes as reference points in Construct but they only seen to work properly if the scale is set to 1. This image demonstrates the issue:

Is this as intended, am I using the scale-property the wrong way, or maybe a bug?

Amazing to see that this plug-in is still being updated!

I've only just begin digging into what it's capable of and one thing that I haven't been able to work out is how to implement palettes. I don't know Spine TOO well but as far as I can tell there's no way to define palettes within Spine.

Could anyone explain (or point me in the right direction) on how palettes with with the Spine plug-in and C3.

Thanks!

You could set the layout size to the largest you'd need to use, and then implement custom scrolling boundaries within that to simulate using a smaller layout.

Thanks! This is what I'm going to try. But is there any chance C3 will get an update to allows us to change the Layout size at runtime? This seems like it should be basic functionality.

One simple solution is make the layout size big enough to accommodate your largest possible level. There isn't any particular performance related aspect to layout size, only how much you put on it. Note that you have a good chance of running into issues with pathfinding across a large level though.

This had a occurred to me and would definitely be the easiest route. I'll try it out and stress test the pathfinding to see how it affects performance.

Another way would be to move your level around instead of the player, so your player effectively stays in the middle of the layout. This has the advantage of limiting the scope of pathfinding as well.

This is an intriguing idea and might work well with the way I've designed the levels. Thanks for the advice!

As I just discovered in another thread: The pathfinding behavior does not work in "areas outside the layout area".

In my game the level is generated at runtime and the size can vary quite a bit.

So, is there a way to change the size of the layout at runtime? That way I could set it to be the proper size based on the level that was generated?

If not, that severely limits the usefulness of the pathfinding behavior (at least in my case).

From the documentation:

Ah thanks! I looked through the documentation but must have missed that bit.

So, for my follow-up - is there a way to change the size of the layout at runtime?

The object.count does not only return picked instances, it returns all instances. object.pickedcount returns picked instances only

I was wondering about this, too. Thanks for explaining that. But I have to say.. it's weird that object.count requires objects to be picked even though no matter how many are picked it's always going to give the same number. Shouldn't there be a way to count objects without picking them?

Objects aren't fully created until the next top-level event. So Enemy.Count won't be updated until the loop finishes. Just use a local variable and set it to Enemy.Count before the loop, then check Variable = 0, and increment Variable for each Create.

This is what I am going to try. It's just always disappointing when something as simple as counting the number of sprites has to have a workaround.

Add a pick all enemy condition before it and it will work.

This does work, and I think I get why I was getting the result that I was.

The only problem now is that if there are no instances of the Enemy then Pick All won't trigger the event. I'm sure I can find a decent workaround, though. Thanks!