I’m trying to load a map with resource.load. my code works 99% of the time… but after I close unity and reload it… I get a null reference error loding the resource. … as soon as I make any change to any script, even adding only a commit… it works again. Im pulling my hair out trying to google this, but I can’t figure out the magic keywords to describe this.
void SpawnDungeon()
{
GameObject temp = Resources.Load<GameObject>("Dungeon/Dungeons/" + dungeon.dName);
//print(dungeon.dName);
GameObject go = Instantiate(temp, transform);
Transform tilesParent = go.transform.Find("TilesMap");
tilesMap = new List<Tile>();
foreach (Transform t in tilesParent)
{
tilesMap.Add(t.GetComponent<Tile>());
}
}
I was hopeful for some stack trace in the error with line numbers. But, if that is your only instantiate call in all your code, then I guess that would be the error source. My first thought was just an order of operation error.
However, I’m thinking it’s just an issue with the Resource folder. Honestly, if it’s a GameObject, I would just tie it to a variable and drag and drop in the inspector, but if you have a ton of stuff, I can see why you wouldn’t go that route. Addressables is a better solution honestly, if that is the case. Unity is trying to move away from the Resource folder anyways.
Let me clarify. This code works every time, except when I load unity for the first time. I load unity, press play and I get this error. To fix it, I just have to let the code recompile(change anything in any script and save)… After recompile… it then works flawlessly until I close unity and open unity again. The dungeon.dName is dynamic, but ig i could use a list of publics…but id like to understand why this is happening instead. I know the reference isn’t broken, the path is definitely correct, because it works every time except that first time.
I think your right, the thread doesn’t really help fix it, but maybe its a unity issue. Although I’m using 2020, not 2019 and I haven’t updated in at leat 5 months, and my laptop stays mostly offline. Thanks for the link though.