UberLou's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I've been using particles for FX and there are some additional settings that would make life much easier and particles look a lot better.

    1) Randomize the initial particle opacity

    2) Randomize the initial particle angle

    3) Randomize the timeout per particle. So all the particles don't fade out at the same time. Looks especially bad if you use one-shot.

    4) Timeout to destroy the particle emitter without destroying whatever particles are still on screen. Every particle emitter I make, I need to make the events: For each particle emitter, if number of particles = 0 -> destroy.

    If there's already a way to do these things, please let me know.

    Thanks!

  • tumira - I can't seem to find the post, but I thought I remember lucid saying the CocoonJS support was possible without XML.

  • Just wanted to show my support for Spriter. I've been using it on a pretty big Metroidvania game which is almost ready to show. There are some features missing like curves that will hopefully be implemented soon, but it is very capable software. I thought I read Spriter should work in CocoonJS soon too.

    Here are some images of my game from an old build. Hope to have some video soon so you can see how fluid Spriter animations are.

  • Add me to the list of people who would really like to see these features.

  • Even better. Thanks for the help!

  • Yeah that should work. But for ease of use, I think the default should just be a global change.

  • Doesn't seem to work for me. I have one Spritefont object. At the title screen I set the character widths and they appear correctly. When I start playing the game and spawn a new Spritefont instance, I have to set the character widths again.

  • It would be helpful to have the "Set character width" action apply globally to the Sprite Font. Whenever I create new text, I have to set the character widths again. I can't think of a case where I wouldn't want it to be a global change.

    Thanks

  • Link to .capx file (required!):

    N\A

    Steps to reproduce:

    Alt scale any sprite

    Observed result:

    The sprite is scaled from the center and also activates the grid snapping override shortcut.

    Expected result:

    Normal scaling behavior, but with grid override like previous versions. There should be separate shortcuts for grid override and scale from center.

    Construct 2 version:

    r137