Closed Wrzlprnft closed 4 years ago
Hello!
Thank you for the detailed explanation, I think I understand the problem, but I need to play with the example to be sure there is not a better solution.
I want to keep the basic example as simple as possible (it is already quite complex). Since this is for a specific need, what I propose is to create a new example 2D_with_ysort with your demo and specific scripts, is it ok for you? I have nothing against splitting the scripts, it was just easier for updates, but if it is not possible, so be it.
Did you create the graphics? Are you ok to release them under CC0? (btw red is acting very sus, I think he might be a sneaky little impostor)
Can you create a pull request? Thank you!
Hi.
The demo shown above doesn't use the ZoneLoadingSystem, it was just made to highlight what YSorting does.
I'll rebuild it using the ZoneLoadingSystem and the solution i came up for my personal project, so i can actually pull request something as an extra demo for the ZoneLoadingSystem. Which i then would also be fine with releasing under CC0. (but Red can only be Impostor, when YSorting works properly. Otherwise hiding becomes somewhat hard)
Ok, if you need assets I propose to use this tileset: https://0x72.itch.io/16x16-dungeon-tileset It is CC0 so we can use it in the demo.
Hello.
I want to tell you I just started working on a 2D example with ysort. Tell me if you already had something ready.
Thanks.
I was away for most of the weekend till now.
What i have: the idea to just add a YSortNode where currently the ZoneTrigger Area2Ds are, and have both the Area and then the actual zone as children to the YSortNode. I figured that i can move the ZoneTrigger-Script to the YSort-Node, and only leave the configuration warning and the signal connection in a script for Area2D.
I have nothing that works, though, i was just picking apart the current demo so far.
I think i have it working, ill need to build demo zones(i've worked from master, so that isn't in there yet), test it, and clean it up, then ill open a pull request.
if you want to have a look already, it's https://github.com/Wrzlprnft/ZoneLoadingSystem
basically did what i described in the comment above, just very... not nice, lots of get_parent()
spliced in there atm
I tested your demo, but it is weird, the player disappears when at the centre of a zone, it guess it goes below the zone.
Here is a video: https://www.dropbox.com/s/sq10z3kuefzbb4k/Zone%20Loading%20System%202020-10-22%2018-35-42.mp4?dl=0
Yes! That is acutally the correct behaviour, since the zones are not adapted at all yet. And it sorts based on the Y Position, and one the player is "above" the center, the player gets sorted behind the zone. Don't worry, that will go away once the zones are changed, and a proper background is included.
Updated the demo zones in my fork. They now work as intended. Set the Z-Index of the colored polygons, so they are always below the player. Added "NPC's the Player can go in front of, or behind. Also added some tilemaps, one YSorted and one background. Code and structural cleanup still standing out before ready to PR.
Ok, I integrated your pull request, that is awesome, thank you very much for improving this template, nice work :)
I have not yet looked into the code/structure, but I have renamed topdown to 2D and angled to ysort, I think it is simpler and less confusing that way.
In order so sort the player properly in front or behind other objects based on position, Godot has the YSort Node. This node sorts all child objects based on their position, as well as all child objects of all child YSort Nodes it has. Example:
Without YSort:
For the ZoneLoadingSystem, that can be almost achieved by converting the World, ZoneLoader and Root Nodes of the Zones to YSort Nodes. But:
Issue: The zones get attached to the trigger-Area2Ds, which breaks a potential YSort tree-connection to the player.
Proposed Solution:that could be fixed by reworking the structure to attach both the trigger-Area and the zone to a YSort-Node, which is a child of the ZoneLoader.
Why this isn't a pull request yet: But since that is not needed in 3D, that would split the script or add a layer of not needed nodes in 3D. An alternative Solution would be to reparent the Player from the World to the Zone they are currently in.
I do not have enough experience to judge which is the best approach with Godot. I just assume that keeping the script identical for 2D and 3D if possible is desired.
Edit: i just realized that this is pretty much a "i don't know what path to take" issue, which i usually try to avoid and just make a pull request. But i haven't worked on a demo like this yet, so i am pretty much unsure on how generalized this should be kept, versus just tailoring it to my personal project.