Passing parameters to next scene

[MashedD]

I think there is no way currently to pass params to next scene.

Scenario:

• Scene 1 has a button to open Scene 2.
• Scene 2 has a few exports like:
  export(String) var some_variable = "some_value"

Here is a proposition how passing parameter(s) to Scene 2 could be done from Scene 1:

	SceneManager.change_scene("res://scene_2.tscn", {
		"scene_params": {
			"some_variable": "another_value"
		}
	})

[jabsatz]

Hmm, I hadn't thought of this feature. I'm definitely down to implementing something like this if there is use for it, would you mind sharing your usecase with me?
(btw, sorry for the long response time, I didn't get notifications for new issues in the past few months)

[MashedD]

(no problem :))

Currently I'm using a workaround that looks like this:

func _on_EasyButton_button_pressed():
	GameplayData.cards_layout = preload("res://screens/levels/layout1.tscn")
	GameplayData.cards_count = 4
	GameplayData.camera_fov = 60
	SceneManager.change_scene("res://screens/gameplay.tscn", SceneUtils.transition_options)


func _on_MediumButton_button_pressed():
	GameplayData.cards_layout = preload("res://screens/levels/layout1.tscn")
	GameplayData.cards_count = 8
	GameplayData.camera_fov = 65
	SceneManager.change_scene("res://screens/gameplay.tscn", SceneUtils.transition_options)

GameplayData is a loaded using AutoLoad feature, so it is a globally accessible object were I keep data I'd like to pass around between scenes. This doesn't seem to be a nice solution, better one would be like a proposition above in first comment, I have no better ideas (not even sure if it's possible like that, but should be :)).

[jabsatz]

Hmmm, I think I understand what you mean. From a technical standpoint doing something as "automatic" as that seems like it could go several ways.

We could set the data on the metadata of your scene, then it would be up to the user to take it and use it in the new scene.
That means in your example you could then use get_meta('some_variable_name') and set_meta('some_variable_name', 'new_value') to change and use it. (We already do something similar internally with the Entity Singleton feature, so I think that's possible)

Another option is getting and setting a variable directly on the Scene script. You would have something like this in your second Scene's script:

var some_variable_name

_process(_delta):
  print(some_variable_name)

This approach might be a bit "cleaner" in general, but the downside is you definitely will need to declare that variable in your script, if you don't we won't be able to change its value.

With either of these solutions, there's also another problem (which is also present in the Entity Singleton feature) and that's that the scene will get initialized before the variables get set. Meaning if you want to use that variable in your _ready method, you might have to do something like this

func _ready():
  yield(SceneManager, "scene_loaded")
  print(some_variable_name)

All this isn't to say that this feature is impossible to make, far from it, but there are some caveats to it. I want to make this library into a simple one that solves simple Scene issues, that people want to use from the start of development and won't feel the need to replace or rewrite it, and I'm worried this might encourage some bad practices.

In general, having an Autoload for these sorts of features seems like a good idea to me, I don't think your solution is a bad one (in fact, I would probably do the same). This has the benefit that the Autoload script remembers all the values you set up in case you need them again at some point.

Say, for example, you made a "second level" for this game in another scene. If you had passed the difficulty as a parameter directly to the first level, you would have to pass it on to the second afterwards. Now, maybe you will figure this limitation out early and decide to put these variables in an Autoload at some point, but maybe that's too much work, or maybe you don't even learn about Autoloads for a while (It took me a long time to find out about them, personally), and in all that time this library might be encouraging people to set variables directly on a Scene.

Another option would be to actually add a "Storage-like" feature to SceneManager. After all, it already has an Autoload. I actually started working on this feature some time ago, but I dropped it because it didn't seem like it was related to "Scenes" per-se, and I wanted to keep this library small. (Though I would consider writing a second standalone addon for handling storage-related issues, like global variables and saving/loading states to files, if there isn't an alternative)

I see two ways where I end up developing a feature like this:

1. There is enough demand of people who think this is a good idea (anyone who sees this comment and would like this feature developed, please react to it)
2. There are genuine use-cases for a feature like this, where a globally available variable isn't a better option (I currently can't think of any, but if there are feel free to respond here)

I'll be tagging this issue as "won't fix" for now, but I'll be checking it regularly in case anything changes.

[jabsatz]

Closing as the feature is not particularly feasible in godot 3.x.

#11 should solve this problem in godot 4