How come there isnt a grid 3x3?!
Yeah, there’s literally no reason not to give us more options like 3x3 etc.
I don’t understand why we’re limited to only THREE options (2x2, 4x4, 8x8) when a lot of people make and sell flipbooks in other formats like 3x3 and 6x6
yeah exactly because very often 4 frames are too few, and 12 is just too many. 9 in a great middle-ground. Although personally, i do prefer the 3x2 or 4x2
Do you have a video showcasing the issue you run into with the provided place file? I’m failing to reproduce your described issue locally. I’ll attempt to test on different device configurations, but it would be useful to know what exactly to look for.
Relevant information about your local configuration would also be helpful. Thanks!
Huge W for fixing this bug. Basically killed the feature for me. Does this mean that GLES 2 is gone, considering that’s the issue cited at the time? @JaapSuter
Yep, pretty sure this is the exact problem I’m having.
I have absolutely no idea how the heck this shipped.
Visual artifacts can happen when authoring too close to the tiles/frames’ edges. If you think that might be something different, could we get a place file so we can reproduce your issue on our end, please?
Since individual frames are a subsection of the 1K texture, the frames are smaller than the total texture size. In a 1K Flipbook texture,
- 2x2 layout’ frames are 512x512pxls,
- 4x4 layout’ frames are 256x256pxls
- 8x8 layout’ frames are 128x128pxls.
This is an inherent limitation of Flipbook textures since all frames are contained within the 1K texture. Is the resolution of your displayed frames lower than the values I listed based on the layout you are using?
in the clip below, if you look very closely, you can see that every time the particle happens, the spritesheet of the particle animation is visible for a split second (most of the time)
https://gyazo.com/39367c6d7dbd057c5b340b47185eb727
the spritesheet just appears out of nowhere for a split second. it seems as if the particle flipbook system actually has a tiny delay before it starts working, hence the spritesheet being visible for a moment. Other than that i have absolutely no idea why this bug happens
Edit: As a side note, i use particleEmitter:Emit(1) method to make the effect appear, and also the particleEmitter isnt enabled.
Hi all,
We pushed a Client fix for this issue (particles not enabling/disabling as expected) earlier today, which means that players should not be experiencing this problem anymore. We also sent in our fix for Studio and it’ll be taking effect with next week’s Studio release. We apologize for the inconvenience and thank you for providing us details on this issue . Please let us know if you’re still seeing anything unusual on players’ side relative to this bug.
Sure, i sent you the place file. Let me know if it doesnt work. the bug is most visible on Greatsword when you press m1(left mouse button) with the weapon equipped
ALSO the effect itself is found in ServerStorage > fx > Swingg or Swinggreverse or SwinggVertical, they all use the same particles* > Attachment.
quality got broken
This occurs in Studio, it doesn’t effect your main game dw.
To be fair, that was for the beta, for a full release I would have expected those technical bugs/limitations to be squished, oh well.
For noobs like me,
I could not figure out how to lock the particle to the emitting part, I tried setting the particle to other than facing the camera without luck until I found the right setting
Orientation: Velocity Paralel
Acceleration 1, 0, 0
Before:
After
hey, I wish there was an “Always On Top” option so I don’t have to make my own particle system with billboardsgui
It would also be nice to add the ability to use meshes instead of images, unity does a good job of this.
I think that particles are something in which we should have a lot of customization capacity…