Feedback & Requests

[Yogoda]

You can use this issue to discuss the plugin.

[Gulbasaur]

Firstly - thanks, this is exactly what I was looking for.

Secondly - would this work with a LOD? So you could have a low-poly version of a zone operating as scenery that's then swapped out on triggering the zone loading.

Thirdly - have you had any issues with saving and loading games?

[Yogoda]

Thank you, I'm happy that it is useful :)

For LOD version of zones, I think it should be possible without too many modifications if there is only one LOD level.

• In the zone_trigger.gd, add a new variable zone_path_LOD that will contain the LOD version of your zone.

• Then, in zone_loader.gd, in _on_zone_exited, you request and attach the LOD version, and in _on_zone_entered you remove the LOD version. Basically it is the same code as the normal zones, but inverted.

I've not had any issue with saving/loading games, but I only save very few data. For example, if I kill monsters in a zone and come back later, they will be back, but this is normal for my game. If you need to keep the zone state, you need to save each zone data when they are unloaded, I don't know if that is your issue.

[rmvermeulen]

Hi, just started playing with the template project. The character runs fast enough to launch itself out of all the zones and you can see them being unloaded and brought them back when you come down. It does exactly what I wanted to implement so far.

As to the workflow, I guess it comes down to

• creating the real map (in full or in part)
• setting up the zones and triggers
• removing the map nodes

I'm thinking that maybe it would be nice for the zone to show the map-node it will load later while in the editor. In case you have to line things up again. But either way, very useful, thanks

[Yogoda]

You mean have all the zones attached in the editor to see the whole world? Unfortunately doing so Godot would load all the zones at the start of the game, defeating the system purpose (only load what is needed).

[rmvermeulen]

You can use the Engine.editor_hint in tool scripts to run some code only in-game, or in-editor.

tool extends Node
func _ready():
  if Engine.editor_hint:
    # in-editor behavior
    show_always() # or use VisibilityNotifier ?
  else:
    # regular behavior
    use_triggers()

I'll cook up a prototype, if it works I'll share it in a PR

EDIT you obviously know all that. I think the misunderstanding is the loading part; Godot only saves parts of the scene that are owned by the current_scene. If you add the map-part to the editor from scripts, but leave the owner blank, it will not be saved. Then when loading the level in-game only the triggers are there, as intended.

[Yogoda]

Wow, that is some seriously cool stuff, didn't know it was possible. It's a great addon to the system, I will merge it when I have time, thank you :)

[Wrzlprnft]

How about turning off the "monitorable" property for the ZoneX Area2D's? As far as i can see, they only need to detect the player entering and exiting, but do not need to be detected, as in any overlap between each other? (haven't looked much into the 3D variant, but from what i see i assume this works much the same in that case).
I am barely starting to use this great system, but that seems like an easy performance gain for to me. I am just not sure wether this is needed when having a lot of zones, and wether i am missing something.

edit: Additional thought, would a visibilityEnabler2D also work to just disable trigger areas off screen, or that be unnecessary (too)?

[Yogoda]

Hello!

I use "zone.get_overlapping_areas()" to detect which zones are connected to each other, so "monitorable" is needed, and without "monitoring" the zone won't be able to detect the player entering it. Anyway, I don't think it is a problem performance-wise since there is only the player and the triggers on this physics layer.

I think it is possible to improve the system for 2D with VisibilityNotifier2D, I need to work on this.

[Yogoda]

Ok, I updated the 2D detection system and demo, there is actually no need to use VisibilityNotifiers or Enablers.

The 2D player now has an Area2D that covers the whole screen making zones attach as soon as they become visible.

[Wrzlprnft]

That was quick! Thanks!
About my performance concerns:
I am not sure wether the change adresses any performance concerns i had, but from the further reading i did, having them on a seperate layer to all other collisions is apparently enough for most cases. The thought behind the VisibiltyEnabler-Idea was to disable collision checking completely if an area is too far off screen/away from the player position. looks like this isn't necessary, and without a large enough project at hand that actually struggles just optimization for optimizations sake.

about the 2D specific change:
One thing the change makes sure though, is that the view on the screen, not the player character causes the zones to load, which is a better default for the 2D example!

[Yogoda]

Yes, exactly my thoughts, also the physical engine is optimized for collision detection, so I don't think it is a big deal, unless we have hundreds of areas. In that case it is possible to have a culling process that disables the colliders according to the distance from the camera.

[Wrzlprnft]

A 2D game, where the perspective is not straight top down, but rather a 45 degree-ish angle (or an isometric view, now that i think about it), needs some Y-Sorting so things properly occlude each other. I guess there is a clever way of using nested YSort-Nodes, or brute force reparenting the player to the zone they are currently in, so the default YSort behavior works. Could this be something added to the demo project?

Edit: I think i figured it out, i overlooked Z-Index. Basically, in the demo2d Scene, change the types of World and ZoneLoader to YSort-Nodes, and change the root node of the Zone to YSort nodes, then change either the background stuff a Z-Index lower, or the Player and Obstacles/Enemys a Z-Indexhigher.

Now it is only a question wether that should be added to the demo.

[Yogoda]

Hello, I mainly use Godot for 3D stuff, so I don't know the issues with 2D sorting very well, if you think your solution can help most of the 2D games that will use this system, can you submit a pull request?

Much appreciated!

[Wrzlprnft]

If the 2D game is 100% top down view, then this will be not needed. If it isn't, and the viewing angle of the assets is more like 45 degree (e.g. Undertale), something like this will be necessary so the perspective makes sense(otherwise you will either always be in front or behind everything in every zone). I'll test around a little more to make sure I am not missing anything, and then I'll create a pull request. Glad I can contribute.