Why activate/deactivate and not Play/Stop?

[anula]

In the previous project (Project Boost) to stop or start particles we used ParticleSystem.Play()/ParticleSystem.Stop(). Why activating vs deactivating the whole GameObject here? Is this for performance reasons? For some reasons related to how particles collide? Or simply since with this setup (polling for fire key, instead of event-based approach one can take with the new input system) it is simpler (otherwise we would need to check if it is already playing, etc)?

[anula]

Ah, I see the approach changed in the next lecture - now we are disabling and enabling the emission module.

I guess this is similar to calling Play/Pause? I am still not quite sure what are the benefits/drawbacks of each of the methods, it would be nice to know.

[Rick_Davidson]

In the past I have had troubles with turning the particle system on and off or Play / Stop whereby the existing particles would disappear. It may be that this is solve nowadays and you could absolutely use Play and Stop on the particle system itself. The approach we’ve taken, by turning emission on and off ensures that I know the exact behaviour I’ll be getting - emission starting or emission stopping.

I also like to show different approaches in the lectures to solve similar problems, that way students are doing more than just the one way that I say is the best, they are experimenting with other approaches (eg. turning on and off a module).

Perhaps have a try implementing with Play and Stop and let us know how you get on - there is possibly a simpler way of doing things than I’m doing.

[anula]

I ended up with Play/Stop approach but my input handling is different than in the lectures - probably better suited to the Play/Stop approach. I didn’t manage to make it work correctly when polling for input in Update method.

I am using the new InputSystem but not in the way shown in your lectures. I have a separate InputAction asset, with all the action maps/control schemes defined and then a PlayerInput component on PlayerShip (just like in this example: https://github.com/UnityTechnologies/InputSystem_Warriors). It invokes UnityEvents on my Movement script, so instead of polling in Update method, I just call Play every time “Fire” is pressed and Stop every time it is released, something like this:

    public void OnFire(InputAction.CallbackContext context) {
        if (context.performed) {
            ActivateLasers(); // iterate through all lasers and call Play() on them
        } else if (context.canceled) {
            DeactivateLasers(); // iterate through all lasers and call Stop() on them
        }
    }

I find handling input with events slightly more readable (especially in situations like this - sometimes you have to check the input state in Update anyway) but that is of course a matter of preference.

When I tried polling for the state of “fire” button in Update() and then do something like “Play() if !isPlaying” I indeed had problems with it sometimes reacting and sometimes not that I never managed to debug.

[Rick_Davidson]

Thanks for sharing your approach. I think its really cool that you are exploring your own way of doing things and getting a deeper understanding of the engine and language in the process.