Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a signal for when the map is finished building #33

Open
Yagich opened this issue Oct 13, 2022 · 7 comments
Open

Add a signal for when the map is finished building #33

Yagich opened this issue Oct 13, 2022 · 7 comments

Comments

@Yagich
Copy link

Yagich commented Oct 13, 2022

As the title says, it would be nice to have a signal or a callback when the map is finished building to allow for post-processing, such as setting collision layers/masks, hooking up signals to entities created in TB, and so on.

offtopic: I'm not quite sure what your vision with TBLoader is, and it is a bit early in development to allow for more advanced use cases where you can build your whole map, logic included, in TB, but it would be nice to have a more concentrated place for discussions than GitHub issues! And also, thanks for the plugin! 😄

@codecat
Copy link
Owner

codecat commented Oct 14, 2022

Hmm, would a signal allow stuff like editor plugins to act on builds?

My first immediate thought is "the build process is synchronous anyway", but maybe there's some use case for this that I'm not seeing yet! 👀

@Yagich
Copy link
Author

Yagich commented Oct 14, 2022

Uhhh, potentially? If you obtain a reference to the plugin somehow, I think it might work. I wasn't aware the build is synchronous, I probably should have figured 😅 But it might be useful for ingame things too I think. Mid-game recompilation, kind of.

At any rate, more automation options/API would definitely be good!

@EIREXE
Copy link
Contributor

EIREXE commented Oct 22, 2022

Uhhh, potentially? If you obtain a reference to the plugin somehow, I think it might work. I wasn't aware the build is synchronous, I probably should have figured sweat_smile But it might be useful for ingame things too I think. Mid-game recompilation, kind of.

At any rate, more automation options/API would definitely be good!

I don't see how it's benefitial when compilation is synchronous, making your own signal and running it after the build does exactly the same.

@codecat
Copy link
Owner

codecat commented Oct 22, 2022

I think signals can still be very helpful, for example if multiple nodes need to receive whenever the map has built. That would be easier than manually keeping track of all objects that need such notification.

@Skaruts
Copy link

Skaruts commented Nov 13, 2022

I think post processing signals might be useful. They might help me in my particular use case, but I'm not sure:

I'm currently trying to have my res://entities/info/player_start.tscn to be replaced by the actual player's scene on build, but I'm not being able to make it work. I'd like to separate the entity markers from the actual objects, and in this case because I'll also have multiple player controllers that could be used depending on the map.

This is what I tried to do in my player_start script:

@tool
extends Node3D

func _ready():
	var player = ResourceLoader.load("res://scenes/player.tscn").instantiate()
	get_parent().add_child(player)  # <-- this errors, needs call_deferred, but then it still doesn't work
	player.position = position
	player.rotation = rotation
	queue_free()

@EIREXE
Copy link
Contributor

EIREXE commented Nov 13, 2022

I think post processing signals might be useful. They might help me in my particular use case, but I'm not sure:

I'm currently trying to have my res://entities/info/player_start.tscn to be replaced by the actual player's scene on build, but I'm not being able to make it work. I'd like to separate the entity markers from the actual objects, and in this case because I'll also have multiple player controllers that could be used depending on the map.

This is what I tried to do in my player_start script:

@tool
extends Node3D

func _ready():
	var player = ResourceLoader.load("res://scenes/player.tscn").instantiate()
	get_parent().add_child(player)  # <-- this errors, needs call_deferred, but then it still doesn't work
	player.position = position
	player.rotation = rotation
	queue_free()

Your code has multiple issues, the use case you are referring to is perfectly possible with godot-tbloader:

  • I think adding children should work in _ready, but if it doesn't, perhaps an await get_tree().process_frame would do the trick, but again i'm pretty sure it should work anyways
  • You are adding children to a node that you then free, thus taking the new scene with it, you should probably add it to the scene root or to the parent of the node
  • In the editor adding a node is not enough for it to show up in the outliner, you also have to give it an owner, you can use set the owner property of your new node to get_tree().edited_scene_root
  • If you are going to set the position after adding it to the tree, you should probably use global_position so it matches properly

@Skaruts
Copy link

Skaruts commented Nov 13, 2022

@EIREXE good points (I was adding it to the parent node, though). I had a feeling this ought to work, but I had completely forgot about setting owners. That's what was missing.
I had to await for setting the position/rotation, though.

Thanks. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants