Confused about code at 1:00 ~ 1:54

I am specifically confused about the code used to toggle the emission module of the particle system on and off.

for context, the code that i initially came up with was something like this :

laser.GetComponent().emission.enabled = true;

this of course did not work as laser.GetComponent().emission is a get only property of the ParticleSystem class. which means it should be impossible to edit .enabled, as it is a property of emission, which is an instantiation of a struct called EmissionModule, which is declared within the ParticleSystem class.

so I eventually settled on this as a solution:
laser.GetComponent().enableEmission = true;

while visual studio gave me messages telling me that this was obsolete, it worked so I just went with it.

my understanding of why this works is that:
while I am not able to directly manipulate laser.GetComponent().emission as it is get only, I can however directly manipulate laser.GetComponent().enableEmission as it is get and set and i assume it does some backend joojoo that i cant see to make the particle system stop emitting.

here’s where my confusion with ricks code comes in. from my understanding of c#, what the code within the red circle would be doing is passing in the value of laser.GetComponent ().emission into the var emissionModule. so it makes sense that emissionmodule.enabled would be editable as the .enabled part is no longer a property of the get only property laser.GetComponent().emission but instead a property of var emissionModule, which would be of type EmissionModule(the struct within the ParticleSystem class). now here’s what i dont get:

why does editing emissionModule.enabled, which by my understanding should be a property of a completely separate variable(emissionModule) that only has had the value of laser.GetComponent().emission passed into it, give the same results as editing laser.GetComponent().emission.enabled directly? shouldn’t it do like, literally nothing at all?

In an attempt to find an answer on my own, I even tried replicating the situation that i am confused with in a more simplified form

and the results were demoralizingly:
sssssssssssssssss

proving that i was right, but also completely wrong??

sorry for the confusing clusterf*ck 500 word essay of a question but please help me lol.

Hi,

Thanks a lot for your questions. :slight_smile:

Actually, laser.GetComponent<ParticleSystem>().emission.enabled should not work. The compiler would throw an error because we cannot modify a property, which is basically a method or multiple methods itself. emission returns an object of type ParticleSystem.EmissionModule, which is a struct and therefore a value type.

In line 71, which I cannot copy and paste from your screenshot, we assign the returned object to emissionModule. Then we can access that object. We are not getting a reference to a ParticleSystem.EmissionModule object but a new object. That’s why you are getting two different results in your console: the default value of the enabled variable of the new object returned by PS1.emission, and the modified value of emissionModule.enabled. They are two different objects.

Did this make sense?


See also:

1 Like

thanks for the help! and sorry for the late reply and the confusing formatting of my question :sweat_smile:
I am using screenshots because I figured it would be more effective at conveying my situation than whatever I can do with my limited knowledge of C#. I hope you can understand haha so feel free to suggest a better alternative.

1.

I assume this in response to

this part of my question. yes I am fully aware that laser.GetComponent<ParticleSystem>().emission.enabled cannot be modified. but I assumed it was because laser.GetComponent<ParticleSystem>().emission comes up as a get only property when I press f12 and go into it like in this screenshot (and pardon my usage of screenshots again lol)


are you saying that it would still be unmodifiable even if it were a get and set property?

2.

yes, I understand this part. in line 71 of rick’s code they are assigning the value of laser.GetComponent<ParticleSystem>().emission to var emissionModule because laser.GetComponent<ParticleSystem>().emission returns a struct,which is a value type. my console app mock up was just me trying to confirm this.
my confusion comes from what comes after that. by my understanding, line 72 of rick’s code should not be affecting how the game runs as it should be a completely separate object from laser.GetComponent<ParticleSystem>().emission, which I understand to be a reference to the emission module of the particle system component attached to the game object “laser”.

just like how in my console app mockup modifying emissionModule.enabled does not affect PS1.emission.ebabled at all as emissionModule is a completely different object that only has had the value of PS1.emission assigned to it.

1 Like

leaving this here for future generations and myself.
so I figured this would have something to do with how unity itself works and not C# so I went to the official unity discord server to ask some people for help and immediately got some answers. turns out, if we were talking solely about C#, i would be right and rick’s code would not work(as seen in my console app mock up). but the structs named “…module” within the particle system class are not actual local fields but rather interfaces (not to be confused with interfaces in C#, the things classes inherit and stuff but rather interfaces as in the context of the english language; a means to interact with something. in this case being actual unity engine data) that contain some kind of reference to the actual C++ engine data running within unity. so manipulating them actually modifies things.

it’s documented here: https://docs.unity3d.com/ScriptReference/ParticleSystem-emission.html

Particle System modules do not need to be reassigned back to the system; they are interfaces and not independent objects.

again interfaces as in the english language not C#.

also, here’s a link to the official unity discord server it’s pretty lit : https://discord.com/invite/unity

3 Likes

That’s interesting. Thank you very much for sharing this information here. Since most parts of Unity are not open-source, we often don’t know what’s going on behind the scenes. I’ve always wondered what they meant by “interfaces”. The description in the API never made any sense to me because I thought they were referring to C# interfaces.

2 Likes

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms