#Making Scene-To-Scene Doors

1 messages · Page 1 of 1 (latest)

patent steeple
#

I'm attempting to make some interactable doors that have an export variable for the packed scene that the door is supposed to load, as making a new script for every door would obviously suck.
However, this comes with an issue of this fun gddeadinside bug:
"E 0:00:00:713 _printerr: res://1.Scenes/_testing_area_2.tscn:21 - Parse Error: [ext_resource] referenced non-existent resource at: res://1.Scenes/_testing_area_1.tscn.
<C++ Source> scene/resources/resource_format_text.cpp:39 @ _printerr()"

I'm a rather ameteur coder and dont' mess with scene-to-scene stuff too much so any help with imrpoving this code or just using a better system would be awesome.

Image attached is of the interactable door script. (pretty much everything is unusued right now except for the interacted function; the rest is later work lol)

||and YES I know having an underscore before the variable "looks odd" or whatever but it's just easier for me that way.||

tulip atlas
#

Just answered another person asking almost the same question! 🙂
The reason it's not working may possibly be that you have, e.g., scene A with a door linking to scene B, but scene B with a door linking back to scene A. This creates a circular reference, which won't work since a PackedScene contains the whole scene, and isn't just a 'reference'.

(You could confirm this by making a scene that only has links to scenes with no doors. If that works, but your other scenes don't, that's probably why)

Instead of exporting a PackedScene, you could try exporting a file, so that it is just a reference (by the local filepath) and not the whole scene, e.g.,

@export_file("*.tscn") var _scene_load : String

This will still let you drag-and-drop the scene onto the property, but it will then be just a path reference vs. an embedded scene. Just keep in mind, once you do this, you don't want to rename or move the referenced scene, or it'll break that link (again, since it's pointing to it by its filepath).

Anyhow, then you can use _scene_load directly in change_scene_to_file:

if _scene_load != "": get_tree().change_scene_to_file(_scene_load)

(If this doesn't work.. there might be other issues; so feel free to keep the convo going 🙂)

patent steeple
#

Worked like a charm! Thank you so much!
good call on using export_file; I often forget there's more than just export gdupsidedown

patent steeple
#

the system of having it as a string prevents any kind of instantiation / loading beforehand before changing the scene to it, right? I'm trying to add a player instance "on the other side of the door" but I don't have a great idea on how to do so at the moment.

tulip atlas
#

Sweet! 🙂 So, yes, by using just the path to the file, it won't be data representing the full scene like PackedScenes are (as an fyi, PackedScenes are technically just objects with some dictionaries and arrays that structurally represent all the nodes in the scene and their properties.)

#

As far as adding the player 'on the other side of the door', it sounds like you might need to store some kind of global autoload. You can create an autoload by simply creating a normal scene (that typically extends just the Node class), and then going to Project > Project Settings > Globals > Autoload, and then for "Path" just click the directory icon and load your scene, then give it a name in the box to the right (you can use this name directly in your code to refer to the instance), and then click "+ Add". Then just make sure it's enabled.
The nice thing about autoloads is, they persist between scene changes. So, for instance, if you wanted to make the player appear in the next scene, you could, e.g., store details about the door chosen on an autoload, and then -- when the next room loads -- read those details to figure out which door the player should appear in front of in the new scene.