Issue Type: Other Impact: Moderate Frequency: Constantly Date First Experienced: 2021-04-12 18:04:00 (-04:00) Date Last Experienced: 2021-04-13 02:04:00 (-04:00)
Reproduction Steps:
This issue can be reproduced by creating a SurfaceGui, disabling the ResetOnSpawn property in the Properties window, and then parenting it to any object inside of StarterGui. When a Player respawns, the ResetOnSpawn property is ignored, and the SurfaceGui will be reset even if it is turned off. It does not occur when parented directly to the PlayerGui. It seems this issue existed a couple years back but was resolved.
Expected Behavior:
SurfaceGuis and other descendants of LayerCollector should respect ResetOnSpawn even if parented to a Folder or other Instance in the PlayerGui.
Actual Behavior:
The ResetOnSpawn property is ignored and the SurfaceGui is always reset. You can see in the video attached that the SurfaceGui not directly parented to the PlayerGui will respawn, even though it’s ResetOnSpawn property is disabled.
Workaround:
It can be avoided by parenting it directly to the PlayerGui, but this prevents any sort of organization.
EDIT
It appears this behavior is currently intended as everything under PlayerGui is reset unless it is LayerCollecter with ResetOnSpawn disabled. In the original thread it was discussed that it’s difficult to decide what the intended behavior would be. I think that the current behavior is considerable more unintuitive than respecting anything the ResetOnSpawn property, and I would request that it be reconsidered.
This is because descendants of the PlayerGui which are not LayerCollectors are always deleted upon respawn. This has been the behaviour for as long as I can remember, and, only the children of the PlayerGui are ever checked.
I already know that removing this behaviour would break parts of my current project and changing it otherwise might, I’m not really sure.
Based on a quick test, LayerCollectors under LayerCollectors are rendered separately, and, their Enabled property works as expected. Additionally, their ResetOnSpawn property appears to be ignored, only the top level LayerCollector is recreated, which, makes sense to me since only the children of the PlayerGui are checked.
I realized it was intended after I posted the report. The previous thread had two different discussions going on and I missed the reply where the reasoning for this behavior was discussed. I still feel like it should be changed as there are plenty of other containers now, and anything that isn’t related to UI shouldn’t be in a container intended for UI only. If they won’t change it I understand, as backwards compatibility is important, but I’d like them to at least add a note to the developer hub page since it’s not even mentioned.
Perhaps folders could get a ResetOnSpawn-like property which appears when parented to the StarterGui or PlayerGui. I’m not really sure, but, I’m not sure how this could be solved.
In order for this to be possible, the game would have to check the descendants of the PlayerGui and not just the children, and, it’d also have to selectively delete & replace only specific instances.
Why not organize your GUIs and load them in by code? That’s how I do it in my game. I have a UI folder, and, under that UI folder I have various UIs, but, I can also have sub folders with more UIs if I need to. When the game runs, it puts them all into the PlayerGui, and, selectively determines which UIs to unload based on ResetOnSpawn.
Yeah I’ve gone ahead and done it programmatically. Thanks for the suggestion. I’ll leave this open for the time being so that they’ll see this and (hopefully) add a small note on the devhub for other developers.
I have run into this problem as well. I have BillboardGuis parented to a folder in StarterGui, but they still reset on spawn. I suppose a workaround is to detect when the character gets removed, parent it to nil, then re-parent after the new character loads.
It would be cool if this was addressed, as it is, for me at least, becoming an issue for organization. Namely the fact that I have a ton of surface gui objects with no way to organize them unless I want to sacrifice having it not reset on respawn.
I have two suggestions:
A UI folder object would be pretty useful, something similar to the Configuration object.
Allow surface GUIs and billboard GUIs to be adorned to multiple objects if that makes sense. It would appear as a clone of the single LayerCollector, but, well, on multiple objects.
This is currently causing me large organisation issues in relation to screen GUIS, with recent updates resulting in it being more optimised to split up our screen GUIs I feel this really needs to be urgently addressed to allow developers to make use of these optimisations without losing their sanity
Really sorry for the bump but I found a workaround sorta, you can actually organize them if your LayerCollectors are parented to another LayerCollector. I noticed this functionality when looking at the chat’s source code. This is what they do on the backend, there’s a ScreenGui, then all of the BillboardGuis get parented to that ScreenGui which doesn’t remove the billboards when the player resets. I just tried it with a bunch of interactive SurfaceGuis and it does work.