Implement decay on the Chart Intro Screen

[zepumph]

Expanding from #80, this is one of the last features to implement. There will be a possibility to reuse much of the decay logic from the decay screen, but we will need to see how it should apply to the ParticleAtomView as well as the shell layers view too.

See notes from design on 11/16/22 of design doc, https://docs.google.com/document/d/12kmOdYKG1DWgMHGodMsY-rO75QS3xxHrzrjkJpqPUxQ/edit:

Keep mini animations on mini nucleons. But fade in/out nucleons on energy levels. Ex. Mini alpha particle shoots out of nucleus and in energy levels, 2 protons and 2 neutrons fade out in the same fashion (top to bottom, left to right)

[zepumph]

The above is a start at trying to tease out the common decay code between screens. We got to a point where we are calling the screen 1 decay methods in screen 2, but it isn't working at all correctly. I am not quite sure how to change those functions to support the multiple views we have in the chart intro screen when decaying, but we will keep on working on it.

[zepumph]

• Toggle enabled of Decay button depending on if there is a decay?

[zepumph]

Work completed above. I will review from here.

[zepumph]

• The electrons and positrons emitted in decay need to be smaller than the the scaled down atom in the chary screen. Right now they are the same size, because they are scaled down from the larger particles (from logic in the decay screen).

[zepumph]

Review:

• This comment confuses me, isn't this already the subclass?
  

  build-a-nucleus/js/chart-intro/view/ChartIntroScreenView.ts

  Lines 362 to 364 in 2d87cf6

  	public override addOutgoingParticle( particle: Particle ): void {
  	// no need to add the outgoing particle because that's done in a subclass
  	}

• ff36bfd#diff-a6b7780c2f9434941e367776926b5a0320ba17f1d3ea9ffc99b6500e1dbd2a55 makes sense to me, but there are other usages of this.model.particleAtom in the BANScreenView decay logic. Can you take another look at them, for example here, to make sure they shouldn't be using this.getParticleAtom() (a function that I'm generally quite confused about).

• There are still 4 TODOs pointing to this issue. One is about the decaying flag which I know is on hold until we get CT a bit cleaner. Let's get these taken care of.

• Can we add documentation to any abstract function about how it should be implemented.

• I feel like the sorting logic for finding the right particle to remove should be factored out, and maybe just called from something like this.model.particleAtom.extractParticle( particleType ). Why can't we do that for this or elsewhere?

  build-a-nucleus/js/common/view/BANScreenView.ts

  Lines 892 to 897 in 4596d78

  	const protonsToRemove = _.sortBy( [ ...particleAtom.protons ], proton =>
  	proton.positionProperty.value.distance( particleAtom.positionProperty.value ) )
  	.slice( 0, NUMBER_OF_PROTONS_IN_ALPHA_PARTICLE );
  	const neutronsToRemove = _.sortBy( [ ...particleAtom.neutrons ],
  	neutron => neutron.positionProperty.value.distance( particleAtom.positionProperty.value ) )
  	.slice( 0, NUMBER_OF_NEUTRONS_IN_ALPHA_PARTICLE );

• Just an idea here, instead of EmitAlphaParticleValues, what if you subtyped ParticleAtom to store the distance and duration onto it, and then you could just return the AlphaParticleDecayParticleAtom or whatever you want to store it. In general I think it is a bit sloppy to return arrays/objects as return types because you want a function to have multiple return values. That said I have definitely done it, and with typescript it isn't really confusing or anything. Up to you!

• Same exact question, but for BetaDecayReturnValues. There we don't have quite the same thing, so perhaps this is moot and unhelpful.

• Would a simplification like this work?

  Subject: [PATCH] clearIncomingParticle needs to update the ParticleNucleus shell positions, https://github.com/phetsims/build-a-nucleus/issues/74
  ---
  Index: js/common/view/BANScreenView.ts
  IDEA additional info:
  Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
  <+>UTF-8
  ===================================================================
  diff --git a/js/common/view/BANScreenView.ts b/js/common/view/BANScreenView.ts
  --- a/js/common/view/BANScreenView.ts	(revision 4596d78aa47c8b83e1ef80892db8f468f053d258)
  +++ b/js/common/view/BANScreenView.ts	(date 1690496602704)
  @@ -904,19 +904,13 @@
         particleAtom.removeParticle( nucleon );
         alphaParticle.addParticle( nucleon );
         this.addOutgoingParticle( nucleon );
  +      this.findParticleView( nucleon ).inputEnabled = false;
       } );
   
       // ensure the creator nodes are visible since particles are being removed from the particleAtom
       alphaParticle.moveAllParticlesToDestination();
       this.checkIfCreatorNodesShouldBeVisible();
   
  -    alphaParticle.protons.forEach( proton => {
  -      this.findParticleView( proton ).inputEnabled = false;
  -    } );
  -    alphaParticle.neutrons.forEach( neutron => {
  -      this.findParticleView( neutron ).inputEnabled = false;
  -    } );
  -
       // animate the particle to a random destination outside the model
       const destination = this.getRandomExternalModelPosition();
       const totalDistanceAlphaParticleTravels = alphaParticle.positionProperty.value.distance( destination );
  

[zepumph]

• We want to make the "fade" in/out for decay in the nucleus be exactly 1 second, and not based on the particle flying away distance.

[zepumph]

Looking really good. Thanks for all this work. Let me know if you want to pair about any of the above. Over to you.

[Luisav1]

• For the sorting logic, an particleAtom.extractParticle( particleType ) function already exists which returns an arbitrary instance of a particle, but I did create an particleAtom.extractParticleClosestToCenter( particleType ) function.
• This won't work for other cases, such as in the betaDecay function since that function relies on the particle closest to the center being a part of the particleAtom and particleAtom.extractParticleClosestToCenter( particleType ) removes a particle.

[Luisav1]

Thanks @zepumph for the review, all of these are now fixed in the above commits. Closing.