Godot: Particles with "one shot" enabled gets "emitting" turned off

[MelvinWM]

Godot version:
098c7ba4f9c49b472b9417819144378081996874
(current master)

Issue description:

When using the node Particles2D or Particles, and having both properties "Emitting" and "One Shot" enabled, if saving the configuration somehow (for instance by moving the focus away from the node), "Emitting" becomes false in the editor, and does not play when the game is run either. See also the GIF below:

Proposed fix
I think the regression happened in https://github.com/godotengine/godot/commit/1f609b7a8221f623ae0c051cbaf44f955c8d97bb. I do not know what the purpose of that commit was; it seems a pure regression AFAICT. That said, I do not know Godot or its particle system very well, so this might be wrong. I have tested a simple reversion, and that seemed to work: In the editor, "emitting" was kept and not discarded, and "one shot" worked when running the game.

[mateusak]

The point of the mentioned commit is to facilitate particles emission control by runtime scripts.
It should not function in editor, though, as one may want the particles to be one shot but start automatically at instantiation.

Fix:
While in editor, do not automatically disable emitting after emission completion when one shot is enabled.

[MelvinWM]

Ah, that makes sense, if the getter for "Emitting" only returned for a field in the Particles(2D) in the scene layer, it would not be possible to get the correct value once emission was over, since "Emitting" is only disabled in the "driver" with "One Shot".

Can "TOOLS_ENABLED" be used to check whether one is in the editor, or should something else be used?

Also, I believe it would be better if it still stopped emitting in the editor, since if I understand you correctly, that would make "One Shot"=true have emission continue while in the editor, which I believe is not desirable. Instead, I think a solution might be while in the editor to keep and use a field for "Emitting" in the scene layer, and when not in the editor ignore that field in the scene layer like how it currently works.

[mateusak]

Not quite right. Before that commit, when you enabled emitting with one shot on, it would spawn the particles once, leaving emitting 'on', which made it confusing to know in which state the Particles2D is currently in.
If you apply the fix I mentioned, it will visually function identically as it is now in the editor, with the only difference the preferred default state will be saved, and will function correctly at runtime.
Other potentially less confusing fix is to add a new option 'emit on instantiation'.

[MelvinWM]

I think I understand better now. But does that then mean that for "option 1", if "Emitting" is off, whether "One Shot" is on or off, and whether "Emitting" was turned off by the game developer or by "One Shot" running, it should still emit when running the game? Making "Emitting" in effect more of an editor-only property, at least from the game developer's POV?

Edit: Sorry, I am wrong, it would be from the game developer's POV while in the editor, not while using scripting.

[MelvinWM]

@mateusak I have thought about it some more and looked into it, and I think your second proposal regarding an option like "Emit on Instantiation" would be best. That approach would also enable having the same overall behaviour as AudioStreamPlayer2D, which has both "Playing" and "Autoplay". Maybe call it "Autoemit"?

The only issue I can see at the moment is backwards compatibility regarding "Emitting", since if "Emitting" is on (and "One Shot" is off), the generated game has particles emitting for that node, while if "Emitting" is false, the generated game does not have particles emitting for that node. With this change, that would instead be controlled by "Emit on Instantiation"/"Autoemit". How important is backwards compatibility in this case?

Also, assuming that the desired functionality is determined, would it be OK if I tried to implement it, test it and make a pull request?

[MelvinWM]

@mateusak Maybe a way to have backwards compatibility would be to let the proposed property "Autoemit" be disabled by default, and if it is disabled, let it default to the current behaviour. Or maybe let "Autoemit" have 3 states, "Enabled", "Disabled" and "Unset", and let it default to the current behaviour if in "Unset".

[mateusak]

@MelvinWM
This is actually an issue with the primitive inspector Godot has. There should be an start emission
and stop emission function and a loop boolean instead of one shot, then an autoemit would fit. But since Godot's inspector doesn't support buttons, they cant trigger those functions, so they went with a boolean and are now trying to buttonmize it. So now we have this strange situation where nothing fits quite right.
In this situation, the best solution is to hide the autoemit property until one shot gets enabled, but then again, Godot doesn't support this either.

Godot offers a lot, but its usability is seriously compromised by the antiquated text editor and inspector. If you want to fix the root of this problem, I suggest working on the inspector.

[MelvinWM]

@mateusak
Regarding which design and UX Godot ought to have regarding the Inspector and the like, I know far too little of Godot to be able to really offer any real insights.

I think one of the really neat things about Godot, at least from what I have seen so far, is that it is really easy and intuitive to both modify and see the results of modifications just in the editor. For instance, you can have multiple particle effects running and see the results directly in the editor without having to run the game. Or play an animation, complete with sound and particle effects running. How well it works I do not know, but it seems to work at least OK, the basic "Platformer 2D" example project does showcase some of these features.

As far as I can tell, there are two main needs and goals related to the Inspector and UI elements like the bottom tabs named "Audio" and "Animation":

• The user needs to be able to view and modify nodes and properties (and other abstractions like signals) for the purpose of changing the behaviour of the game when it is run.
• The user benefits from being able to see directly in the editor the effects of changes to nodes and properties.

From looking at the code, it seems that the implementation that deals with these two needs are somewhat intermingled. In particular, I believe that the editor state for nodes overlaps or is shared with the node and property definitions used for generating games to be run. I fear that such a mingling can make the code more complicated and bug-prone than it has to be, though I do not at the moment see a good alternative. That said, I might well be wrong about that, and this is after all just games and game tools, so the quality requirements are not that high (higher for game tools than for games of course), and other concerns such as performance, flexibility, maintainability and functionality matter as well.

Assuming it might be that I am not off or way off regarding this superficial analysis with overlapping or shared state between the editor and the node/property definitions, do you happen to have any good intuition regarding whether there are few or many bugs that might stem directly or indirectly from this? If you do not at the moment have any good intuition regarding this, I could try to look into it. Of course, it may just be that I am still very new to Godot, and that this is a non-issue or has been discussed and planned for, etc.

There is also the aspect of supporting live editing, which I do not have experience with or considered regarding this.

[austinried]

I think this is actually a bug. I've been running into this a lot lately (with 3.1.1) and have been able to get around it by being in the script editor when I checked "Emitting" which kept it turned on. Now I have a scene with no script and two Particles2D nodes and I can't find a way to be able to make them both "Emitting" since the editor flips back to the scene view when I select the second node, which plays the one shot effect, and then turns off emitting on the other one.

[clayjohn]

@austinried It sounds like you just should be using an AnimationPlayer.

[austinried]

I didn't need to animate anything really, I just wanted both particle emitters in one scene to be set to one shot and emitting.

[clayjohn]

@austinried It's not about animating anything. You use the AnimationPlayer to set both particle systems to "emitting" at the same time. It is incredibly useful way to sync your particle systems in editor.

In game, if you want both to start upon entering the scene tree (i.e. when starting you game) in _ready() just put:

func _ready():
    $Particles1.emitting = true
    $Particles2.emitting = true

It doesn't make sense to add an entire new property to the editor just to avoid those two lines of code

[austinried]

Right... I mean I get that what you're proposing is a viable workaround, and I eventually just added a script very similar to what you have there, but I don't see why I should need either the script or the AnimationPlayer just to have both particle emitters start emitting when they enter the scene tree and also for them both to be set to one shot.

I'm not proposing a new property in the editor, I'm saying from a user perspective, if I check those two boxes, I want them to stay checked.

[MelvinWM]

@clayjohn I am uncertain, but does Godot differentiate between:

• Editor game definition state
• Inside-editor game simulation state

in this case reg. one_shot (and maybe other properties such as emitting)? And if not, is this desirable, undesirable, unconsidered, and/or other?

[clayjohn]

I'm not proposing a new property in the editor, I'm saying from a user perspective, if I check those two boxes, I want them to stay checked.

The only thing one_shot does is uncheck emitting. That is the entire purpose of that checkbox.If one_shot doesn't set emitting to false it does nothing at all.

@MelvinWM In theory you could check with TOOLS_ENABLED, but the core devs want to keep the editor logic distinct from game engine logic so that when you export you aren't stuck with a bunch of code that is only useful to the editor.

Think about what is being proposed. You are asking for one_shot to be effectively disabled while in editor and then enabled again once the scene is run. Not only that, but you want that to happen without the user being aware of it. Hiding functionality while in editor is bound to create confusion, especially for new users. And the only thing it saves is a single line of code.

I think the only clean solution is the one described above by mateusak https://github.com/godotengine/godot/issues/17903#issuecomment-378651405. At some point we should have editor controls to pause and play particle systems, this way you could set one_shot and emitting but just have it paused in editor, then it would play automatically when added to scene. Anything else is too hacky and is bound to create more problems than it is worth.

[MelvinWM]

@clayjohn That is a lot of derivations reg. proposals and requests from my most recent comment you come with :smiley: . That most recent comment I came with was just questions after all.

I think a clear, conceptual distinction between "editor game definition state" and "inside-editor game simulation state" might be useful:

• "editor game definition state", or maybe just "editor game definition", or "game definition" is _never changed by simulating parts of the game_ (such as a specific particle system) inside the editor, it is the definition of the game. When playing the game, letting these be changed (for instance through scripting) might depending on case make sense, but it would still not be reflected in the actual game resources once back in the editor.
• "Inside-editor game simulation state" would be running the game inside the editor, and will definitely change when the game is simulated inside the editor.

If one was to design and implement explicitly according to this distinction, for a particle system, the "game definition" might sensibly contain the following "variables"/"properties"/other:

• emit_initially
• one_shot

For the inside-editor game simulation state (and game state when running the game, I think), it could for instance have the following additional "variables"/"properties"/other as the implementation for enabling the desired behaviour (other implementations are possible of course):

• is_emitting
• has_emitted_once (or however it makes sense to handle one_shot)

Of course, this separation means that there would be more "variables"/"properties" than there currently is. And which of these should be exposed to the user, and in which ways? The "game definition" parts should definitely be exposed to the user in the editor, and likely also through scripting including while the game is running. And keeping the number of "variables"/"properties" low might be more desirable according to the chosen approaches than any possible benefits from separating the "game definition" and the "inside-editor game simulation state".

My impression is that Godot tends to have the "game definition" be handled by the same "property", implementation, etc. as the "inside-editor game simulation state", and that it for most cases does not cause any issues. However, in certain cases, such as when a property might be modified by simulating/playing a part of a game for instance when simulating a particle system with one_shot, it might cause issues as seen with this issue.

Most "variables"/"properties" for Particles2D does not change when simulating a particle system directly, from skimming https://docs.godotengine.org/en/latest/classes/class_particles2d.html , it seems that it indeed is only emitting and one_shot that might change when simulating a part of the game inside the editor. Might it make sense for these kinds of cases where simulating the game might change them to depending on case possibly split them up as with the example above? Or some other approach to dealing with them, as I gather you might be proposing?

[clayjohn]

@MelvinWM You have provided a very clear breakdown of the issue. Thank you.

I think a clear, conceptual distinction between "editor game definition state" and "inside-editor game simulation state" might be useful:

This is a fantastic idea and a very useful framework. However, the Godot editor is just a game made using Godot. While there is some limited ability to check if code is being run in editor, the core devs prefer not to do so and to keep the engine distinct from the editor. The implication of that decision is that we can't keep reference to certain "editor only" variables that don't affect game state while in editor and then discard them when the game is run. While I love the idea you have proposed here, I think it would require a restructuring of the entire Godot architecture to implement 😨

Might it make sense for these kinds of cases where simulating the game might change them to depending on case possibly split them up as with the example above? Or some other approach to dealing with them, as I gather you might be proposing?

This type of issue has arisen in a few places that I know of 1) when using a tool script and 2) when animating methods of a node. In 1) users just have to be very careful about what state they change while the tool script is running. In 2) they made it so methods won't be called by animations while running in editor (note that this makes it impossible to test animated methods while in editor).

For this particular issue we should find something that makes sense. In my opinion, it isn't too much to ask users to set emitting to true manually when they want the emission to start in code. At most this requires users to add an extra line to their code. Implementing a workaround (any workaround) in the engine is going to require a lot more than one line, and it is going to add a lot more complexity to the engine. From a users perspective, engine complexity isn't a big deal, but keep in mind that Godot is maintained by a bunch of random people most of whom only contribute a handful of times. So making sure that the code avoids unnecessary complexities is of the utmost importance.

All that is to say, we need to find a solution that is elegant, and avoids too much complexity. If that can't be done, then your gonna have to live with that extra line in your _ready() function.

I think you have addressed an important topic, and that is _separating editor simulation from game simulation_. which brings us back to mateusak's comment. What the editor needs (long term) is a way of pausing simulation in editor. Maybe this can be a property of Node (which would then extend to all it's children). Thus allowing you to freeze the simulation of the particles and not have them update in editor. Until then though, I don't think any other solution is worthwhile.

As a consolation, last week a made a PR that updates the emitting property's status in editor so at least it updates to show it is set to false instead of you having to click out and back again for it to update. https://github.com/godotengine/godot/pull/29937

[MelvinWM]

@clayjohn Reading your reply, I am not convinced at all that you and/or I understand the other.

The implication of that decision is that we can't keep reference to certain "editor only" variables that don't affect game state while in editor and then discard them when the game is run. While I love the idea you have proposed here, I think it would require a restructuring of the entire Godot architecture to implement :fearful:

I did not at any point discuss or propose editor-only "variables"/"properties". The "game definition "variables"/"properties" I gave examples of above would very much ALSO be runtime.

In 2) they made it so methods won't be called by animations while running in editor (note that this makes it impossible to test animated methods while in editor).

That sounds strange and less nice. is that special-cased hard-coding?

For this particular issue we should find something that makes sense. In my opinion, it isn't too much to ask users to set emitting to true manually when they want the emission to start in code. At most this requires users to add an extra line to their code. Implementing a workaround (any workaround) in the engine is going to require a lot more than one line, and it is going to add a lot more complexity to the engine. From a users perspective, engine complexity isn't a big deal, but keep in mind that Godot is maintained by a bunch of random people most of whom only contribute a handful of times. So making sure that the code avoids unnecessary complexities is of the utmost importance.

Apart from the complexity of introducing new "variables"/"properties" and changing the implementation as you typically would, without any non-standard changes, I am not convinced that any special implementation or refactoring of the engine, editor or other would necessarily be needed. Though, I have not investigated this part either, and my insight into the engine is still very limited.

But still: If you add 2 "variables"/"properties" and refactor the code, such that two of the "variables"/"properties" in practice describes the "game definition", without any special requirements or handling required by the engine, editor or other; and then add 2 "variables"/"properties" in practice for the non-"game definition" (or maybe one of them just an internal variable, depending on what you want to be exposed and the like), that would satisfy the above distinction (though it would be somewhat direct) and would not require anything special for the editor, engine or other.

Of course, here I assume that the "game definition" "variables"/"properties" would also be useful and meaningful to have while running the game, and that it might make sense to change them through scripts while running the game. You might well have a point reg. "variables"/"properties" that it would not be meaningful to change or include runtime, though I do not as such believe that is the case here, though I could be mistaken.

I think you have addressed an important topic, and that is _separating editor simulation from game simulation_.

But... my main address was reg. distinction between "game definition" and "inside-editor game simulation" :confused: . Wouldn't that distinction be much more important than between "inside-editor game simulation" and "game playing"? Besides, cannot "inside-editor game simulation" and "game playing" be handled the vast majority/all of the time by the same concepts and implementation, and isn't that the goal already, and a good goal?

All that is to say, we need to find a solution that is elegant, and avoids too much complexity. If that can't be done, then your gonna have to live with that extra line in your _ready() function.

When I encountered this issue reg. one_shot, I got confused and ended up spending debugging time and effort due to the "property" one_shot being for me changed unexpectedly. And the behaviour difference between playing the game not causing a change to the property in the game resources and conversely simulating the particle system actually causing a change to the property is definitely surprising, especially if you are new to Godot. It might trip up many people and waste time and effort. It seems to me a time-wasting quirk or bug. Yes, this quirk or bug can be worked around, so I think you are right that it does not matter all that much, but it might still trip up x number of users that begins to use one_shot. I am not certain that the solution would be very expensive, though it might require a change in interface reg. the properties, and that would mean that such an approach if viable and good would have to be postponed until a version that allows such breaking changes.

I think you have addressed an important topic, and that is separating editor simulation from game simulation. which brings us back to mateusak's comment. What the editor needs (long term) is a way of pausing simulation in editor. Maybe this can be a property of Node (which would then extend to all it's children). Thus allowing you to freeze the simulation of the particles and not have them update in editor. Until then though, I don't think any other solution is worthwhile.

I might be wrong, but while pausing the simulation sounds like an interesting feature, it seems... off as a way of dealing with this issue.

As a consolation, last week a made a PR that updates the emitting property's status in editor so at least it updates to show it is set to false instead of you having to click out and back again for it to update. #29937

Well, it is no skin off my nose :smiley: , to be honest, for some time now I have decided not to advance with Godot (I did publish a minimal game at Google Play that I used to learn Godot with). I am participating here mostly just to be responsible and seek to be helpful reg. the issues and pull requests I started or participated in.

[mateusak]

Well, it is no skin off my nose 😃 , to be honest, for some time now I have decided not to advance with Godot (I did publish a minimal game at Google Play that I used to learn Godot with). I am participating here mostly just to be responsible and seek to be helpful reg. the issues and pull requests I started or participated in.

I had decided to not say anything, but this is... interesting. Could I know why you didn't stick with Godot? No need to spare feelings.

[MelvinWM]

@mateusak Well, there are many nice or very nice things about Godot, and seemingly nice or seemingly very nice things about Godot, and a lot of interesting concepts, but there are honestly also a lot of bugs and quirks and the like. It is of course still fairly early days for Godot, and it is improving considerably. For instance, reg. the very basic minimal game I made to learn Godot with, I very stupidly and irresponsibly did not test it early on for the different platforms I wanted to deploy it on, namely Android and web, and that meant that I found out very late that Particles2D was not supported fully for the graphics system I was using reg. the web as a target platform. I then looked into using CPUParticles2D, but I recall that I gave up on that, maybe due to there not being feature parity (which is fully meaningful, HTML5/Javascript games are still fairly early days and continuously changing, and the nature of the platform seems to inherently impose considerable constraints, no matter which tools, engines and libraries you use, at least that is my impression so far). Of course, Godot has improved since then, and when starting a new project, it asks you to select the graphics system and informs you of the constraints and features each have, which is very nice, so that is no longer an issue.

But I have also encountered a number of other quirks and bugs and the like, and it can end up being frustrating. For instance, I encountered #27106 very shortly after starting a new project, and I ended up spending 5-30 minutes (I don't recall how long) debugging and seeking to figure out why things were not working before I realized or began suspecting that it was an issue with the editor itself, not my own actions. In and of itself, that issue is a very minor thing and easily worked around, but such minor things can accumulate, and if there are many of them, it can become frustrating to a considerable degree.

Then one could fix them, but there might be regressions, and new bugs, and the like. Decreasing the overall number of bugs and keeping up the quality for a software project, especially a large or very large project, is generally a highly challenging aspect, especially if you also want to have other aspects and properties as well as other goals, technical and non-technical (though in the case of quality, sometimes quality can help aspects such as productivity, though again, it very much depends on the case, approaches taken, etc.). For example, one attribute that I get the impression Godot seeks or claims to seek to have is adaptability, including in regards to the different technologies, approaches and methods used, and that is a very meaningful and good goal to seek. I did make this comment as intended to help assist reg. this issue: https://github.com/godotengine/godot/issues/2641#issuecomment-460805110 , though I do not know how those approaches fit into Godot, its developers, its community, its business model (primarly Patreon AFAIK and recall), etc.

Then there are other stuff that are not technical, but I will not comment on those.

[austinried]

@clayjohn OK, I can understand how what I'm saying might sound unreasonable from your perspective, considering what emitting is supposed to do/reflects about the state of the particles. However, I'm not sure if the solution posted earlier (https://github.com/godotengine/godot/issues/17903#issuecomment-378651405) is the only way to go. I'm also not sure why you were initially so against a new editor property when this proposes several new editor properties/abilities.

At this point I think it would actually be best to introduce that new autoemit property, which I think does indeed make make sense without the proposed stop/start editor function buttons, because it matches the interface of the AudioStreamPlayer. If those new editor buttons were introduced for start/stop here, it seems they would also need to be introduced there for consistency as well. But regardless of that proposal, why does it not make sense to mirror the playing/autoplay pattern here into emitting/autoemit?

IMO, it's about more than saving a few lines of code or an extra AnimationPlayer, it's about having a consistent UX that doesn't trip people up.

[clayjohn]

I'm also not sure why you were initially so against a new editor property when this proposes several new editor properties/abilities.

Because the changes proposed by mateusak could be done without integrating editor features into core engine code. The change you suggest, while also useful from a UX perspective would require integrating the editor into core code in a way that the core devs have said they won't allow.

In my personal opinion I have no problem setting emitting to true when I want my particle systems to start emitting. So I have no real desire to change anything. I've already spent more time discussing such a small nuisance than I want to.

You have a lot of great ideas! Just because I (a random contributor) disagree with you about what is the best implementation you can still prove me wrong 😛

[MelvinWM]

@clayjohn

The change you suggest, while also useful from a UX perspective would require integrating the editor into core code

You have claimed this before, but I do not understand how it "would require integrating the editor into core code". Why would it, namely adding and changing a few properties similar to how it is done now, require anything special like you claim? Of course, we may be talking past each other.

I've already spent more time discussing such a small nuisance than I want to.

It is true that the issue is indeed very minor. That said, minor issues can add up, and when each user encountering the issue has to spend time figuring out there is an issue and that it needs to be circumvented, that time can add up across users. But yeah, it is still a very minor issue. I also find it valuable to be able to identify problems and find good solutions for them, and learn and improve reg. this - software development is after all typically entirely non-trivial, so it is natural to always be learning and improving. And discussion, if constructive and benign, can be very valuable reg. learning and improving.

[akien-mga]

I did not read the full backlog, but reacting on the issue title and some keywords I parsed from the various answers:

• I agree that it can be annoying that you can't configure a particles node to be One Shot + Emitting by default, since Emitting will be reset to false once the lifetime is passed.
• An autoemit / autostart property could indeed be added for that instead, so that the particle effect starts emitting automatically when it enters the tree. (Currently you'd have to call emitting = true in _ready() for such a situation).

That being said, I don't know how frequently I would need one shot particle effects to autostart. I've been working on https://github.com/KOBUGE-Games/jetpaca a bit, porting it to Godot 3.2, and all the one shot particle effects seem to be triggered manually when their parent scene enters the player's camera, which seems to make the most sense for one shot effects (you want them to be visible, not run off screen).

[MelvinWM]

@akien-mga Regarding the use cases I had, I used it for various explosions as well as a minor amount of debris flung from the cannon muzzle when a shot is created/fired.

[austinried]

That's pretty much my exact use case as well, little effects here and there that play once and then are gone.

[Feniks-Gaming]

That being said, I don't know how frequently I would need one shot particle effects to autostart. I've been working on https://github.com/KOBUGE-Games/jetpaca a bit, porting it to Godot 3.2, and all the one shot particle effects seem to be triggered manually when their parent scene enters the player's camera, which seems to make the most sense for one shot effects (you want them to be visible, not run off screen).

This is needed every time you need one of instance. For example when creating explosion of a ship I would like it to autoplay, explosion of chunk of ship and then to playing it, when player dies I would like to one of play blood splatter from dead body and then stop etc.

[akien-mga]

Alright, so it seems there's two different approaches used by different devs:

• Have particle emitters in the scene which will use them, and use code/animation to trigger emission when relevant. That's what I tend to do and in this scenario this issue is not particularly problematic.
• Have particle emitters in dedicated scenes, and instantiate those scenes from code/animation when relevant, in which case users also want those to autostart. That's what users most bothered by this issue seem to be doing. Edit: This use case is likely most frequent when one wants to decouple a particle effect from the scene it originated from, especially for the transform.

IMO adding an autostart or autoemit property that sets emitting = true when entering the scene tree is the simplest solution that does not require a heavy refactoring of how nodes are being processed in place in the editor.

[Feniks-Gaming]

autostart would be desired solution as this is what all other nodes like for example timers use. This would be consistent with the rest of the engine and make it easy to understand at first glance what it does.

[Jummit]

autostart would make it more inline with Timers autostart and AnimationPlayers autoplay.

[bitbutter]

I found this thread because I'm also trying (failing) to instantiate a dedicated particles scene, have it play immediately, just once. Very confusing (and to me, unexpected) that when I have One Shot checked, the Emitting checkbox becomes unchecked if i click on a different tab, and then back on the one containing the particle node.

[FaultyFunctions]

I stumbled upon this thread because this was confusing to me as well. I found a pretty decent work-around in the editor for people using particles in their own separate scenes and instantiating them from other scenes.

1. Set the particle node to Oneshot enabled
2. Select the particle node and go to the signals section in the editor
3. Double click the Node -> Ready signal
4. Set the Receiver Method to set_emitting
5. Check Advanced
6. Add a bool argument and check the on setting (setting the bool to true)
7. Check Oneshot in the signal dialog (this is probably optional?)
8. Connect the signal to the particle node (connect to itself)

This should set emitting to true while preserving the Oneshot property in the Particle2D node without any extra code.

Having a dedicated autostart property would still be a great feature to have though!