Yes. Also saved with the latest version of Spriter b4.

I'm getting a random bug and I'll do my best to explain. I load the player character at the beginning of the layout and it always appears as a jumble of sprites. It usually takes about 1 frame for the sprites to assemble into the correct position. I can live with that 1 frame hitch, but sometimes (about 1 out of every 20 times) it can take over 5 seconds and it seems to be random when it happens.

If the fix for this isn't obvious, I'll reduce my game into a simplified capx and send it to you and\or Ashley.

Thanks for all the comments guys! I finally put together a teaser trailer. Still working hard on getting a playable demo out.

Yeah really well put together. A lot of nice little touches like the spent shells bouncing off the enemy sprites.

Here is a prototype I'm developing called APC, Incorporated. It's a metroidvania style game with 360 degree shooting.

Update: I've totally overhauled the graphics to be more low res and pixel art due to performance issues.

<font size="5">Screenshots </font>

Intro Cinematic

<img src="http://stealthfrogstudios.com/siteImages/APCinc/SS135/screens16.jpg" border="0">

City Bridge

<img src="http://stealthfrogstudios.com/siteImages/APCinc/SS135/screens17.jpg" border="0">

Maintenance Corridor

<img src="http://stealthfrogstudios.com/siteImages/APCinc/SS135/screens18.jpg" border="0">

<font size="5">Video </font>

Teaser Trailer #1 (old graphics)

<font size="5">Demo</font>

APC, Inc. Demo 1 (old demo)

<font size="5">Links</font>

Twitter

IndieDB

Ashley Not sure I understand what you mean.

There's nothing removed from the Spriter animation as I'm just reimporting the same SCML file.

The red sprite is created in Construct (it doesnt exist in the Spriter animation) and added to the container with the Spriter object.

I can get around the problem by removing all non Spriter objects from the container, reimporting the SCML file, then putting the non Spriter objects back into the container. It's a bit of a hassle, but it works.

Link to .capx file (required!):

https://dl.dropboxusercontent.com/u/95028662/ContainerTest.capx

Steps to reproduce:

1. Run Layout 1

2. Move the mouse cursor close to a red sprite

Observed result:

The 1 red and 1 blue sprite are in a container together. When you move the mouse close to a red sprite, it gets picked and changes size correctly. I would expect the one blue sprite in the container to be picked and moved randomly too, however both blue sprites get picked.

Expected result:

Only the blue sprite in the corresponding container gets picked.

Browsers affected:

Chrome: yes

Firefox: yes

Internet Explorer: yes

Operating system & service pack:

Win7

Construct 2 version:

139

Huh...yeah that is interesting. Thanks for checking it out. I think it would make sense to pick the container objects also to be consistent with other picking events. Going to submit as a bug.

I've read the manual on containers but I'm not sure I understand the picking. Here is an example file:

Container Capx

The 1 red and 1 blue sprite are in a container together. When you move the mouse close to a red sprite, it gets picked and changes size correctly. I would expect the one blue sprite in the container to be picked and moved randomly too, however both blue sprites get picked.

Am I missing something?

Link to .capx file (required!):

    https://dl.dropboxusercontent.com/u/95028662/SpriterTest.zip

Steps to reproduce:

1. Drag the Bat01.scml file into the test.capx project

Observed result:

The red sprite is in a container with the spriter objects. It gets deleted out of the project when you drag the new scml file in.

Expected result:

The red sprite is not deleted and is included in the container with the new spriter objects.

Operating system & service pack:

Win7

Construct 2 version:

r139

1) Yes, I asked about initial opacity randomization. I was simply stating that when you set the initial opacity, they still timeout at the same time which is not what I would expect. This results in an unnatural looking particle system which is why I had also asked about randomizing the per particle timeout in my original post.

2) Spray cone is the emission angle. I would like settings to change the individual particle angle (the sprite), not the emitter.

3) Object count is a performance hit. Quoting the manual "Avoid using too many objects or particle effects..." Having a simple randomization setting would avoid more objects and keep the project cleaner.

4) You just created 2 events. So yes that's extra events rather than having a simple setting to delete the particle emitter.

I do have the ability to handle all of it in script. I can set up events, groups and families to manage everything. Yes I know about those too. I'm just making some very simple suggestions to make the workflow easier and make particles more robust.

Thanks for the workarounds.

1) Sort of works but not really as expected. The initial opacity is changed, but they all fade to 0 at the same time. Meaning that a particle that has an opacity of 50 and one with an opacity at 100 fades to 0 in the same frame. Looks very unnatural.

2) Angle of the particle, not spray cone.

3) That works, though it's not very optimization friendly and gets messy with bigger projects, which is what I'm trying to avoid. If you have 5 particle objects and decide to change a few settings, you would have to change them on all particles.

4) Yup, I can destroy the particle emitter when there are no more particles. However, again, in a big project with lots of FX, this creates a lot of events. Seems like a "destroy emitter on timeout" property would speed up workflow.