Problem with array of objects turning Null right after exiting for loop.

Hello, Currently having issues with a Card and Deck class. I made it so that when the deck is initiated, the deck class which has an array of 52 cards, goes through and give every card a value 2-14 (ace is 14 for this case) as well as a suit, which is all in a card class which has a default constructor. On awake, I make sure that the array of cards all have values like 0 and “” for the suit. Once giving each card a value, I check in debug to see if my getters for the cards are working like getValue() and getSuit(). They all work fine in the for loop but as soon as I leave the for loop they just turn null. Any ideas on what I’m doing wrong?

Some images of the test, null test is using the same function getValue() but is outside of the for loop that initiates and gives the cards values. Turns null.

9124996--1266355--image_2023-07-05_134127845.png

You need to turn off the “Collapse” setting on your console so you can see the logs in the correct order.

Your first loop is looping over 52 (hard coded) iterations
Your second loop uses the length of the array

There is no guarantee these two are the same, and that’s something you need to log as well.

You also seem to be using a constructor on your Monobehaviour derived class, which is ill advised.

Hello! Thanks for the fast response,

So I went through to check with the logs without collapsing and the output is in the order that I want, they seem to be getting values then losing their values after exiting the for loop.

I also changed both loops to go off or arr.Length so that is more consistent.

For not using a constructor in monobehavior, what does that exactly mean? I currently have Classes for Cards, Deck and Table which are all Monobehavior. Currently Deck has an array of 52 cards and each table has their own deck. I currently have constructors for deck and cards but should I get rid of those? Sorry I come with a C++ background in OOP. Doing what I have learned (hopefully correctly).

You should be seeing warnings in the console about creating monobehaviours via their constructor.

Components can only exist attached to game objects, and they should only be added via Monobehaviour.AddComponent<T>. Using a constructor to create them bypasses this and causes memory leaks.

If you don’t want them attached to game objects, make them plain C# classes. If you do, use AddComponent<T>, or set up a prefab.

Ah ok, Yeah I currently have them all as separate monobehavior scripts all dragged onto the table prefab I am using, I will try getting rid of the constructors and using the AddCompnent way. I am guessing that both default constructors and constructors are a no go?

Thanks!

Parameter-less constructors are ‘okay’ that they should be called when the object is created (via Object.Instantiate), though often not recommended as it’s not the ‘Unity way’. Using Awake, Start and OnEnable for initialisation is the recommended Unity way as the timing and order they are called is will understood and reliable.

Rule of thumb being Awake for self-initialisation, and Start for initialisation that relies on other objects being initialised. OnEnable partners with OnDisable and should be used for as the name described, behaviour that should happen when objects are enabled or disabled.

The Execution Order is important reading to understand this: https://docs.unity3d.com/Manual/ExecutionOrder.html

Naturally you only need AddComponent if you’re dynamically adding components. It sounds like you already have the components set up on a game object, so I’d recommend using the Unity callbacks to initiate this stuff.

The first loop is just outputting to Log all those times with no useful information, nothing else is repeated. You have no braces after the for (...) so only one statement is looped.

1 Like

Sounds good! Ill give it a try. Thanks!

1 Like

Yeahhhh just realized that, I read your comment and thought “Im not THAT dumb” and was wrong. Thanks for pointing that out, was able to get accurate data now lol. Hopefully will be able to fix now with the accurate readouts.