Closed patwari closed 4 years ago
Properties specific to the Emitter and not specific particle types belong on the main config, not extraData
.
What is the use case for turning off inOrder
on an emitter mid-cycle and having it finish out the cycle? That seems non-obvious/confusing to a user and makes the code a little messy - you could manage the whole thing internally with just currentImageIndex
otherwise.
Properties specific to the Emitter and not specific particle types belong on the main config, not
extraData
.
On second look, I agree that that the inOrder
should be moved to Emitter config.
What is the use case for turning off
inOrder
on an emitter mid-cycle and having it finish out the cycle? That seems non-obvious/confusing to a user and makes the code a little messy - you could manage the whole thing internally with justcurrentImageIndex
otherwise.
The reason I wait for the cycle to complete, is starting to emit randomly in middle of cycle would be more confusing, also will not look good.
However, I am open to suggestions.
Anything in the config is considered to be largely static for the Emitter, the only things expected to be changed during emission are position and rotation. Anything else is part of the presumably carefully designed particle system and requires a full re-initialization, or is modify at your own risk. As such I am fine having that oddity happen if changing isOrder
during emission. Owners of the emitters can know when emission is complete with the callback for playOnce()
to avoid changing it during emission, if they absolutely must.
I'd suggest changing isOrder
to orderedArt
, using the protected variable currentImageIndex
where -1
is orderedArt == false
and any other value is orderedArt == true
.
Anything in the config is considered to be largely static for the Emitter, the only things expected to be changed during emission are position and rotation. Anything else is part of the presumably carefully designed particle system and requires a full re-initialization, or is modify at your own risk. As such I am fine having that oddity happen if changing
isOrder
during emission. Owners of the emitters can know when emission is complete with the callback forplayOnce()
to avoid changing it during emission, if they absolutely must.I'd suggest changing
isOrder
toorderedArt
, using the protected variablecurrentImageIndex
where-1
isorderedArt == false
and any other value isorderedArt == true
.
@andrewstart I've made some changes as per your suggestion.
Sweet, I'll work on an example emitter for this feature and then push out a new version. It sounds like you are doing some kind of Eastern dragon, but I can also see this being useful for turning characters/vehicles into giblets/debris.
Added a boolean in Emitter to emit particles in order. To set you have two options:
__yourEmitter__.inOrder = true;
config.extraData.inOrder: true
It is quite useful when you want emit textures in an order, for example: dragon [head, body1, body2, ..., tail].
Although, I understand that half of Particles' beauty comes from its' random nature, however this feature will be great to have. I needed that for a game.