WaveConfig waveConfig is a variable declaration, not an object. In C#, each variable must be defined with a type. The type, in this case, is WaveConfig because your class is named WaveConfig. waveConfig is the variable name.
In pure C#, we would create an object like this: new WaveConfig();. And this is how we would assign an object to a variable: WaveConfig waveConfig = new WaveConfig();.
Since we are working with the Unity framework, we often must not create objects ourselves because that would result in conflicts. If we tried to do that anyway, Unity would complain via a warning or error message in the Console. Unity creates objects itself, and we assign them to fields in the Inspector, or we create objects via the Instantiate method.
why would Enemy pathing need access to a Waveconfig object when WaveConfig waveconfig; (the red and green) already gave the enemypathing that access?
variable != object
If you need an analogy: Assuming you have a mobile phone, and your best friend is named Rick. You create a new contact. There is a field named “mobile”. Are you able to call Rick without having typed something into the “mobile” field? No, you are not because the “mobile” field is not the number but a field. You have to assign his number to the field first, then you can click on a button to call him. When Rick changes his number, you edit the “mobile” field.
If you had to write your own “contacts” feature with C#, you would create a variable named “mobile”, and it would be of type int because that field is supposed to accept integers only.
and why would we want to reference the local enemyspawner waveconfig parameters in the .GetComponent<Enemypathing>().SetWaveConfig( waveConfig); if what we’re trying to do is call out the information from the enemy pathing?
We are not referencing any variables but values. That’s a huge difference. See my example at the bottom of my answer.
If you meant “why don’t we access the waveConfig variable of the Enemypathing object directly to gain access to the referenced object”, the answer is: We follow the principles of object-oriented programming. One of them says that we do not want to make variables accessible to the outside because everything that has a reference to the object could modify the value of the variable. I covered that case in my example at the bottom of my answer.
What was the reference in this case?
We cannot see the reference. However, this.waveConfig and EP_waveConfig can both hold a reference to a WaveConfig object.
I mentioned the mobile phone, the contacts and the “mobile” field. The “mobile” field is supposed to contain an integer. That integer could be regarded as a reference to a specific mobile phone.
I don’t know how the equivalent looks in C#. I assume it’s some address in memory where the object can be found.
Sorry for bothering you too much, it just that I have been stuck here for 3 days replaying the lecture and reading other threads trying to understand this lecture.
No worries. I know that this lecture is fairly complex because a lot is going on there. We are dealing with different objects, moving data from one object to another. It is difficult to see the underlying concept, so please do ask questions. 
In C#, we usually do not work with objects directly. Instead, we use variables and treat them as if they were our object.
Due to the many different names we use in our scripts, the idea of referencing the same object could be a bit confusing. Let me give you an example with a badly written class named Test. For simplicity, we create objects from it ourselves and ignore Unity for a moment.
public class Test
{
public string name = "Rick";
}
public class EnemySpawner: MonoBehaviour
{
Test myTest; // default value is null (no reference)
void Awake()
{
myTest = new Test(); // we create an object and assign it to 'myTest'
}
public Test GetTestObject()
{
Debug.Log("this.myTest.name: " + this.myTest.name); // Output 1
return this.myTest;
}
}
public class Enemy : MonoBehaviour
{
[SerializeField] EnemySpawner spawner; // we assign the EnemySpawner object in the Inspector
void Start()
{
Test test1 = spawner.GetTestObject();
Debug.Log("test1.name: " + test1.name); // Output 2
test1.name = "Ben";
Test test2 = new Test();
Debug.Log("test2.name: " + test2.name); // Output 3
Debug.Log("test1.name: " + test1.name); // Output 4
}
}
If you can tell what the output in the console is without testing the code in Unity, you understood the underlying concept of references.
By the way, if you are interested in a free C# course, I can recommend Bob Tabor’s. If you feel you are getting stuck in each of Rick’s video because you didn’t understand what he was trying to explain, take a break from the Unity course, follow Bob’s C# course and proceed with Unity. You’ll realise that the C# stuff is not as difficult as it looks. It just feels difficult because you are doing so much at once at the moment: dealing with Visual Studio, typing code, moving stuff around in Unity, adjusting values in Unity.
