Autoload export properties

[pixel-boy]

Autoloads are very useful, but the inability to access their @export variables is a bit limiting. One alternative is to have them as children of the first game scene, but that would defeat the purpose of autoloading.

I don't think there's a technical limitation that makes autoloads incompatible with @export variables, so I think it's mainly an interface issue ?

With a well-designed and easily accessible interface for this, it would be a powerful tool for configuring configurable test situations. I haven't thought in detail what form this could take, but I can look for ideas.

Edit: I forgot it was possible to do this via an autoload scene, but I find tedious having two files instead of one per autoload, plus having to open each scene independently.

The idea behind the proposal was to make autoloads a useful tool for changing the configuration of global game parameters, but maybe this isn't the right place to do that.

I find that, as it stands, no solution really convinces me for this. Being able to launch a scene via F6 isn't ideal. I often end up with a Main.tscn scene that contains the @export variables. The advantage is that I know everything is in the main scene, the disadvantage is that it's very dependent on the current project and less easily reusable.

I'm not exactly sure what form this should take, but I feel like we could have a place to efficiently configure project's global settings. I should probably open a discussion specifically on this topic.

[AThousandShips]

See also:

• Add Autoloads to the Scene tree for easier signal connection management #4993

[pixel-boy]

Thanks, I'll follow this!

[passivestar]

Edit: I forgot it was possible to do this via an autoload scene, but I find tedious having two files instead of one per autoload, plus having to open each scene independently.

Personally I prefer to have a single autoload.tscn for all global nodes because it makes it easy to add scripts just by ctrl+dragging them into the autoload scene. This of course gives easy access to exported variables on them and you can have your "configurable test situations" by duplicating the autoload.tscn and changing exported variable values inside of it if you need to swap out the entire testing environment

If I need reference to any node inside of the autoload scene I use singleton pattern in it like so:

class_name GameManager

static var instance: GameManager

func _ready() -> void:
	instance = self

GameManager instance can be accessed globally from any script with GameManager.instance

Same exact singleton pattern works for nodes that aren't in autoload, for example main player controller that spawns dynamically. It's simple and covers a lot of usecases which is why a lot of games ship with that

[pixel-boy]

Thanks for your reply, I hadn't considered this approach, I'll try it!
Would you say there are any drawbacks to doing it this way compared to autoload?

I'd also be curious to have more details on this part, I'm not sure I understood it correctly.

Same exact singleton pattern works for nodes that aren't in autoload, for example main player controller that spawns dynamically. It's simple and covers a lot of usecases which is why a lot of games ship with that

[passivestar]

Would you say there are any drawbacks to doing it this way compared to autoload?

you mean compared to making every single node that needs global access an autoload? none that I can think of, besides 2 extra lines of code per class

I'd also be curious to have more details on this part, I'm not sure I understood it correctly.

class_name PlayerController extends CharacterBody3D

static var instance: PlayerController

func _ready() -> void:
	instance = self

player can be accessed from anywhere after it's spawned:

var player_position = PlayerController.instance.global_position

[pixel-boy]

I've never explored static variables, I think this will be the opportunity for me to get started, thanks for sharing!