One bout of exhaustion-induced fever later, let’s continue.
To sum up all the stuff I went about last time, we need to establish a link between three different “levels” of the code.
We’re gonna go with the “chain of children” approach rather than the signals one for now (as it’s related to very static elements that don’t need updating that often when compared to say… enemies). And we’re gonna start out by making the simplest of tests.
On the top level we make this variable, which carries text.
We run the game, it prints the variable. That’s good.
Next we need to create something on the second level of things that reads this variable.
In theory this takes the parent node, takes linktest, and then prints that plus an additional line.
This is good, it means that we have a connection to parent node that we can use at this point.
Now comes the suspenseful part, the one where we repeat this on the last level.
In theory this should access the node with the first script, print the same message, and add some more the moment you open the look menu.
…game crashed but that was because of leftover code from last time.
THEN it crashed again but for more valid reasons.
HOWEVER, not only do I see the problem now, it’s so obvious I wanna scream.
This is what the resource tree looks like in runtime.
The goal is for lookcontainer to get things from startupnode.
The way it currently works is like this.
Do you see the problem? Here, let me highlight it.
Simply put, the error that I kept getting and that kept me spiraling out was born out of forgetting that there’s an intermediary container.
Now, there’s plenty of solutions to this specific part. The “fancy” solution would be to use signals as I mentioned before, however, signals would be a bit overkill in this case.
As a reminder, signals are the things I’ve used to have the buttons trigger things and whatnot. They’re great for dynamic elements like, for example, telling the dialog framework “kick in the moment this button is pressed” or telling other entities that the payer is doing this or that.
However, what we need to do is so static (call forth from a resource tree that doesn’t need to adjust dynamically through different situations) that not only would it be overkill, but it would involve the parent constantly sending signs of where it is.
So instead, we’re gonna create a script in the intermediary script that acts as a bridge.
First, let’s comment the faulty code to make sure this works.
It Did Not.
However, the error was on the print() command and not on the one where I try to call all the way to the first level of things.
I’ve read of things that don’t happen until the ready step ends, so it might be related to that. Indeed if I comment out the print command it’s all good.
So let’s go back to the last level and edit it to use the bridge.
So we hit play and…
Same error, but again, the error is happening on the print command specifically.
After taking a deep breath and vacuuming the office a little bit, I went back to looking things up and eventually found out about this option, an option that lets you refer to specific nodes through a unique name no matter where they are.
Before I kick myself and celebrate, let’s run the test.
So we run the program and….
OKAY DIFFERENT ERROR I CAN WORK WITH DIFFERENT ERROR.
Let’s first check if it’s detecting it at all to begin with.
We run the code and…
Okay, we have a better sense of what’s going on. It’s not that this method or that method is faulty, something in the way I’m handling it fundamentally doesn’t allow it to access things.
After reading the documentation, we actually have essentially the same issue that’s been going on so far. The program can easily go from parent to child but not from child to parent. Unique names help within this flow but are not meant to break or go against it.
Now, there’s this very important truth in programming: If you’re having a very specific problem, there’s an extremely high chance someone already came up with the extremely specific solution.
In essence, what I need is a global variable, and by looking that up I see that Godot has “Atoload Singletons” or whatever, which are, essentially the thing I need: Nodes and the like that can be accessed by any other node in any context…
…at least that’s what it SEEMS like.
So let’s get into the menu and…
OH RIGHT THAT’S WHY DIALOGIC CAN BE ACCESED ANYWHERE.
Okay, I have more faith in this now. Let’s do the quickest of tests.
We make a new node (Note: It HAS to be saved as a resource that the program can load from a folder).
Then we attach to it a script with some test text.
We add it to the autoload part.
We go back to the same script we’ve been trying to get a reaction out of and add this.
We test…
…
…
…
…
…
Before I throw a tantrum and cry like a baby, I will point out that I put the string before the Ready step which might be the cause.
So we move things like this.
…
…I am being tested, I will not be found wanting.
So check the remote. The node is there, but notably the Script section is empty.
So let’s add it.
We hit play once again and…
My only regret is that nobody will ever hear the monkey noises I made when I saw that it worked.
This discovery singlehandedly solves every other problem I’ve had. With this I can create the variables that will store the assets for each chapter, the flow of the game… and in the more short term side of things finish this current menu.
However, let’s leave that for next time.