Is it possible to get node of a *.tscn

jonSS Remove camera limit updates from Player autoload (in miniMap node) and remove Player position/zoom update in next_level scene. Instead do all this in each level's _enter_tree() callback.

jonSS Then make a function in Player that will read any needed stuff from current level and adjust camera and player accordingly. Call this function from level's _enter_tree()

It's important to update all at the same time. Currently you have a mismatch because you set player position before the level is added and camera limits for new level only after the level is added. So there is one frame inbetween where player and level are not matched.

Btw no need to set camera limits every frame as you're currently doing. This is in fact causing the problem. Do it only once when level is loaded.

jonSS
in player.gd

func level_started():
	var lvl = get_tree().get_current_scene().get_child(0);
	cam2D.limit_right = lvl.get_region_rect().size.x;
	cam2D.limit_bottom = lvl.get_region_rect().size.y;
	position = lvl.player_initial_pos
	cam2D.zoom =  lvl.initial_zoom

In each level:

@export var player_initial_pos: Vector2
@export var initial_zoom: float
func _enter_tree():
	Player.level_started()

You can also put a dedicated positional marker node into level and let the level_started() function use its position for player starting position. That way you won't need a manually filled-in property.

Again, the important thing is to do all this at once as soon as level is added to the tree. So best to keep it all in one function and call that function exactly at right time.

EDIT: if there will be some initializer scripts inside level, it may be better to call Player.level_started() from level's _ready() instead from _enter_tree()

jonSS my player node script is kind of full

What do you mean by "full"? Just add this function to existing code. Having it in top node is better design-wise, and calling it looks simpler.

Your setup is kind of strange with Player being a sole autoload. It could be fully automated if level scenes were instantiated manually. This way, somebody needs to notify the autoload that scene was swapped so it can adapt itself to the new scene.

You don't need different scripts for each level. Use the same script just export the properties like map_POS and adjust them in editor. With this, you don't have to type any new code regarding camera/player initialization when you create a new level scene. It's fully automatic.

jonSS There's a way to do it without using scripts in levels, from the same place you change the scene. You can pass player position to Player.level_started() and call it deferred from next_level scene:
in player.gd:

func level_started(player_pos: Vector2):
	var lvl = get_tree().get_current_scene().get_child(0);
	position = player_pos
	cam2D.limit_right = lvl.get_region_rect().size.x;
	cam2D.limit_bottom = lvl.get_region_rect().size.y;

In next_level.gd:

if ( levelGO == true ):
	levelGO = false;
	get_tree().change_scene_to_file(nextLevel);
	Player.call_deferred("level_started", Vector2(plrnextX, plrnextY))

This is then minimal intervention into your existing setup and it's more or less fully automated. You can as well add other arguments to level_started() if needed.

jonSS Try it in 4.1. It works fine.
It's something related to 4.2, it's still beta after all but I'm not sure if it's a bug or they changed something in deferred call order. In any case the current_scene shouldn't be null there.

jonSS I'm not following what they're doing with 4.2 but the problem is happening when calling change_scene_to_file() from either _process() or _physics_process():

func _process(delta):
	if Input.is_action_just_pressed("ui_accept"):
		print(get_tree())
		get_tree().change_scene_to_file("res://scene2.tscn")
		print(get_tree())

The scene gets properly changed but get_tree() returns null after the call. When doing this from _ready() everything is as expected. Looks like a bug.

jonSS This is not specific to Area2D. It happens even if done plainly from _process(). Whatever it is, get_tree() should never return null here.

jonSS I reported it. The devs confirmed it as a regression bug that appeared in dev2. They added it to 4.2 milestone, so it'll surely be fixed.

As for your project, It'd be best to temporarily go back to 4.1 and use my last suggested solution with call_deferred() from next_level.

jonSS The solution with deferred call I suggested works perfectly. It's fully automatic and, design-wise, it's a "natural" way to do it in your setup.

get_tree() doesn't work in 4.2 because of a core engine bug. The moral of the story is that you shouldn't quickly jump into using latest betas if're not well acquainted with engine's inner workings.

jonSS Hm, the plot thickens Devs now claim that this timing change in change_scene_to_file() is in fact intentional. It won't be a deferred call from 4.2 on. It'll behave just like remove_child(), taking place immediately. The node running the script will not be in the scene tree after the call, so naturally get_tree() will return null. Imho this is better than it being deferred but it somewhat changes the way to handle scene swapping in cases like yours.

To make things bulletproof you should set things up so that there's no reliance on exact scene change timing:

• put all data that's relevant to camera/player initial setup into the level scene itself (instead into transitional next_level scene)
• notify the Player autoload about scene change form level itself by calling a dedicated level_started() function from level's _ready().
• do all level-related initialization of camera/player in that level_started() function.

That's all there is to it. If you set it up properly, this is fully automatic and should work regardless of change_scene_to_file() being deferred (v 4.1) or not (v 4.2)