ScreenGui.PreserveOnRespawn

[1waffle1 (Waffle)]

Similarly to Modal, anything with a PreserveOnRespawn ancestor would be preserved, and anything with a PreserveOnRespawn descendant would be preserved as well. If there was a ScreenGui with two ScreenGuis inside of it, the main one did not have PreserveOnRespawn enabled, and only one of its children did, then the other one would be removed (and not autorefreshed) on respawn.

[Aurarus]

[quote] What happens when you set this property in a GUI under the StarterGui? The game begins inserting the same GUI over and over again. That’s bad API design over already bad API design. My real beef with this is that it’s a cop-out which assumes that resetting GUIs is even desirable behavior. The answer is that it almost always isn’t.

GUIs were created in part to be used by Tools, so GUIs are reset at the same time Tools are; when the character respawns. There are a few flaws with this: one is that Tools can be removed at any time, not just when the character respawns. Another is that Tools must insert their GUIs to a global location in order to render them, which goes against the modularity of Tools.

A good solution is to render GUI objects located under a Tool while the Tool is equipped. Now Tool scripts don’t have to worry about keeping track of their GUIs, and now there’s no reason that GUIs must be reset by default (except for that dang-blasted backwards-compatibility).

The reason one would insist on being able to reset a GUI in general is because they’re used to the default behavior. But there’s nothing wrong with making a script do the work. In fact, it’s more correct, because it’s a behavior of your GUI, and behaviors are controlled by scripts. [/quote]

gross :X

Having different “I think players would find it more intuitive to do it this way” scenarios in which GUIs can appear will only lead to more bugs and confusion. Already in plenty of my tools I have ScreenGuis that get copied or moved between the PlayerGui, hidden when I need them to, or copied into other playerGuis

Point is, PlayerGui is “the stage”. We know anything we put in there gets shown to the player. Any scripts placed here play locally for that player. We can take things out, put things in. It’s the stage.

Having multiple stages with different behaviours and exceptions only makes things more messy. That’s not what we’re asking for.

The originally suggested feature gives us power, and is soooo simple. There is no one who can’t wrap their head around it. It’s less confusing than having GUI’s inside tools automatically shown…

[Aurarus]

This is seriously mind blowing how everyone isn’t collectively on the same page.

It seems like most of the people here never had any experience using GUIs, even on a preliminary basis, even though I’m certain all of us has…

!?!?!?!?!

Even if you’re the “You should be responsible, do your own hacks” type of person, this feature just makes sense to have

It’s practically a flag marker for scripts and GUIs that you don’t want affected from respawns. In fact I’d probably use this more often on guis that automatically destroy themselves, so they can finish running whatever script they’re running and THEN get deleted. (Like, when changing FOV)

[Osyris]

This is seriously mind blowing how everyone isn’t collectively on the same page.

Sure, I agree on that note.
I do find it a bit confusing why you think it’s a good idea to implement it this way, but I’m not making a huge deal out of it.

I feel that this solution, while useful, is not the best way of approaching it. I think it creates more problems than it needs to.

[EchoReaper]

“I do find it a bit confusing why you think it’s a good idea to implement it this way”

Current GUIs have to reset on respawn because they’ve always been that way and it’d break stuff to change that
Still need way to preserve some GUIs and leave others to reset (e.g. shop window)
If we just disable resetting for all GUIs then we have to hack together something to reset specific GUIs by adding code to every GUI that needs to be reset (extremely redundant and unnecessary) or add a universal local script that resets GUIs if their name is in a table of names in the localscript (not modular at all and very bad) – you need to hack together something else to get it to do what you want, so that is not an optimal option for this
Only remaining way is to add property to each individual GUI to determine of it resets or not

People whine about stuff like GUIs not being what they should be and stuff completely unrelated to OP and dismiss OP because they don’t like the way GUIs work even though that can’t be changed

[Aurarus]

This is seriously mind blowing how everyone isn’t collectively on the same page.

Sure, I agree on that note.
I do find it a bit confusing why you think it’s a good idea to implement it this way, but I’m not making a huge deal out of it.

I feel that this solution, while useful, is not the best way of approaching it. I think it creates more problems than it needs to.[/quote]

I already have all my guis separated into different ScreenGuis

IntroGui
ShopGui
ChatGui
LeaderboardGui

Some of those ought to persist, some of them should not

ticks true for the ones that should

BAM, everything works

[Anaminus]

We’re past the point of no return for whether GUIs should reset on respawn or not – all GUIs are built assuming that it will reset on respawn, so ROBLOX can’t change that behavior unless they wanted to break every GUI. It’s useless to argue what it should be – we’re stuck with what it is now. So no, regardless of how “improper” it is, GUIs will always reset on respawn by default – deal with it. What we can do however is provide API functionality so that regardless of what you want the GUI to do on respawn, it will always work – even if you’re a greenhorn scripter.

The great thing about this situation is that it’s still possible to change the default behavior through adoption over time. I’m not saying that it should absolutely happen, but do I think that it would be for the best. It has already been done in Roblox many times already (dynamic lighting, smooth terrain) with graceful results. PreserveOnRespawn would only solidify the problem. If that is added, the default reset behavior cannot be changed without breaking the behavior of PreserveOnRespawn.

You’re also suggesting the same thing you’re denying at the same time. “Let’s have GUIs render in tools and have them go away when they’re unequipped.” If you have multiple tools, you’re just going to be resetting the same GUI (in appearance) over and over each time you change weapons.

I never said the GUIs inside tools would be reset. I said they would either render or not based on whether or not they’re equipped. No copying or moving of GUIs occurs, tools would simply act like a PlayerGui. This is great because the GUIs are contained, so if the tool is arbitrarily removed, the GUIs go with them.

[quote] “now there’s no reason that GUIs must be reset by default (except for that dang-blasted backwards-compatibility).”
You’re also very wrong on this. If I have a “hack terminal” GUI pop up whenever I click on a terminal, I’d want that to go away when the player respawned because they’re not at the terminal anymore and shouldn’t have that GUI. I want to get rid of the NPC shop GUI whenever they reset because they’re no longer in the shop. I want to reset the red-circle-thing-that-shows-where-you-got-shot-from on respawn (that’s not related to a tool – it’s related to damage). There are a lot of things aside from tools that need to be reset on respawn. [/quote]
This behavior can easily be handled by a script, which I’ve already made my point on. Character respawning is only one of many cases where a GUI needs to be killed.

[quote] Point is, PlayerGui is “the stage”. We know anything we put in there gets shown to the player. Any scripts placed here play locally for that player. We can take things out, put things in. It’s the stage.

Having multiple stages with different behaviours and exceptions only makes things more messy. That’s not what we’re asking for. [/quote]
You already deal with multiple “stages” when working with scripts. What I’m proposing is analogous to this. If I understand correctly, no one has a problem with scripts running in multiple locations, so why should they have problems with GUIs rendering from multiple locations? Not to mention that this already happens anyway (see CoreGui). How is this more messy than requiring tools to inject and manage their GUIs?

[EchoReaper]

The great thing about this situation is that it’s still possible to change the default behavior through adoption over time. I’m not saying that it should absolutely happen, but do I think that it would be for the best. It has already been done in Roblox many times already (dynamic lighting, smooth terrain) with graceful results.

That’s assuming that not resetting it is the better solution. You’re forgetting ROBLOX’s target audience for studio. ROBLOX automatically taking care of GUI cleanup helps their largest population of developers, the younger / less-experienced developers. Making it easy to use for everyone aligns with ROBLOX’s principles – phasing out automatically cleaning up GUIs and making it harder for their largest population of developers to use just because a handful of people think resetting any GUI on respawn will end the world goes against that principle.

And no, you can’t phase it out to begin with. There’s no guarantee that games will even update. The reason dynamic light was able to be added is because there’s a GlobalShadows property. The reason smooth terrain was added is because you have to intentionally convert your place to smooth terrain. The only way to “phase in” new behavior is to archive ResetPlayerGuiOnRespawn and display it in the properties window, but as Aurarus said earlier you’re just moving to a different side of hell – it doesn’t solve the underlying issue.

PreserveOnRespawn would only solidify the problem. If that is added, the default reset behavior cannot be changed without breaking the behavior of PreserveOnRespawn.

I had to go over this with Osyris on Skype too – look closely at the name. It’s not ResetOnRespawn – it’s PreserveOnRespawn. If you turn off resetting GUIs, nothing is broken. If it has PreserveOnRespawn set to true, it isn’t reset as expected. If it doesn’t have PreserveOnRespawn set to true it still isn’t reset but that’s also expected because you turned ResetPlayerGuiOnRespawn to false. There’s nothing game-breaking about it.

I never said the GUIs inside tools would be reset. I said they would either render or not based on whether or not they’re equipped. No copying or moving of GUIs occurs, tools would simply act like a PlayerGui. This is great because the GUIs are contained, so if the tool is arbitrarily removed, the GUIs go with them.

Resetting wasn’t what I was referring to. Your belief is that GUIs should not reset automatically and you should manage all of the GUIs manually and reset them to their default states when it’s appropriate, correct? GUIs inside tools goes against that principle. Instead of having one ammo GUI in the PlayerGui and updating the GUI’s ammo box whenever you equip/unequip a tool, you’re copying and pasting the same ammo GUI into each tool. In other words, instead of using one and manually keeping track of and managing GUI states, you’re letting ROBLOX handle state changes automatically + you’ll just end up with flicker between the duplicate GUIs when you switch tools, so I don’t know why you’d want to do that in the first place.

This behavior can easily be handled by a script, which I’ve already made my point on. Character respawning is only one of many cases where a GUI needs to be killed.

That is a mess and I’ve already made my point on that as well. Resetting a GUI on respawn or not is related to the GUIs themselves. It belongs in the API and not some ugly, loose script. When you use a feature you shouldn’t have to hack together something else just to be able to use it.

[Aurarus]

[quote] Point is, PlayerGui is “the stage”. We know anything we put in there gets shown to the player. Any scripts placed here play locally for that player. We can take things out, put things in. It’s the stage.

Having multiple stages with different behaviours and exceptions only makes things more messy. That’s not what we’re asking for. [/quote]
You already deal with multiple “stages” when working with scripts. What I’m proposing is analogous to this. If I understand correctly, no one has a problem with scripts running in multiple locations, so why should they have problems with GUIs rendering from multiple locations? Not to mention that this already happens anyway (see CoreGui). How is this more messy than requiring tools to inject and manage their GUIs?[/quote]

If I want tools to contain certain ScreenGuis but not show them, now I have to make sure I can place them in areas that won’t get dragged into the stage without my permission.

Also regarding what Echo said, we certainly are past the point of no return, even through very slow adaptation. GUIs have been out for how long now? And their behavior has remained consistent. Guis rely on player characters, waiting for things to settle in, and tagging all sorts of existing objects. Not to mention all the Guis that have scripts/ behaviour that make changes to newly spawned in entities. (Tools, character)

With persistent Guis, so many scripts, free models, and games will become unusable, and will have to be made to “refresh” themselves every time player.CharacterAdded() is fired.

PlayerGuis are not better off being entirely persistent, and if they were you’d certainly want a simple “RefreshOnRespawn” property in ScreenGui. Heck, even making certain games playable depend on being able to reset playergui stuff, since poorly scripted games may run into a bug with guis/ localscripts but simply be refreshed with a character reset.

Thinking back on all my projects, I’d say over 50% of my screenguis are better off refreshing every time the player respawns, while a select few would be really nice if they could avoid it.

[1waffle1 (Waffle)]

To people resisting this: What is your solution? If you wanted to keep something on your screen (like a chat) even after you die and respawn, what would you do so that it doesn’t have to flicker or reload without adding a new special button that makes it not disappear automatically? Shouldn’t I be able to tell it whether or not I want it to disappear? Are you going to tell me that I can’t?

[Aurarus]

To people resisting this: What is your solution? If you wanted to keep something on your screen (like a chat) even after you die and respawn, what would you do so that it doesn’t have to flicker or reload without adding a new special button that makes it not disappear automatically? Shouldn’t I be able to tell it whether or not I want it to disappear? Are you going to tell me that I can’t?

Most people against this idea have all their Guis persist by disabling the ResetPlayerguiOnRespawn thing or whatever in PlayerGui.

They think you should be in charge of refreshing GUIs yourself and being responsible for it.

We argue that we shouldn’t have to use hacky methods. But the resisters seem to also forget that many games already depend on the reset behaviour (and might be better off for it)

This sort of harkens back to the whole FilteringEnabled debate, where the only determining factor for which side you’re on is your experience on the type of games you’ve worked on. (Action based/ extremely dynamic games rely on local stuff replicating, vs. More simple games that have relatively simple patterns or straightforward mechanics)

[Dinizterz]

Pls don’t remove ResetPlayerGuiOnSpawn

[EchoReaper]

No one is asking for it to be removed…

[Dinizterz]

Ik but just in case.

Sounds like som ppl here don’t like GUIs persisting which could mean instant malfunction on all my projects.

[Velibor]

Sorry, Echo. But I use Frames to do this exact behavoir, and the 10 lines of code that you need to write do make a module that can do this is really not that much to ask. (Using ResetOnSpawn to false)

[Anaminus]

[quote] And no, you can’t phase it out to begin with. There’s no guarantee that games will even update. The reason dynamic light was able to be added is because there’s a GlobalShadows property. The reason smooth terrain was added is because you have to intentionally convert your place to smooth terrain. The only way to “phase in” new behavior is to archive ResetPlayerGuiOnRespawn and display it in the properties window, but as Aurarus said earlier you’re just moving to a different side of hell – it doesn’t solve the underlying issue.
[/quote]
First, make ResetPlayerGuiOnSpawn a normal property that isn’t all weird and hidden. Second, make it on by default for old places, and off by default for new places. This is exactly how GlobalShadows works. GlobalShadows even introduces a behavioral change (i.e. Ambient), which everyone seems to have dealt with just fine.

Resetting wasn’t what I was referring to. Your belief is that GUIs should not reset automatically and you should manage all of the GUIs manually and reset them to their default states when it’s appropriate, correct? GUIs inside tools goes against that principle. Instead of having one ammo GUI in the PlayerGui and updating the GUI’s ammo box whenever you equip/unequip a tool, you’re copying and pasting the same ammo GUI into each tool. In other words, instead of using one and manually keeping track of and managing GUI states, you’re letting ROBLOX handle state changes automatically + you’ll just end up with flicker between the duplicate GUIs when you switch tools, so I don’t know why you’d want to do that in the first place.

The next great thing about it is that you don’t have to use it. You can continue managing your GUIs in a global way. Combined with the gradual adoption mentioned above, current games can continue functioning the same way, while new or updated games can use either the modular or non-modular system. The point here is to stop forcing Tools to use GUIs in a non-modular way. Make a few Gear and you’ll understand why modularity is important for Tools.
The only problem is that current tools may already be storing GUIs as descendants, which means they would start rendering unintentionally. If this turned out to be a major issue, it could be worked around with a simple property in Tools that toggles rendering of GUIs.

That is a mess and I’ve already made my point on that as well. Resetting a GUI on respawn or not is related to the GUIs themselves. It belongs in the API and not some ugly, loose script. When you use a feature you shouldn’t have to hack together something else just to be able to use it.

You already have to use scripts to handle all the cases where you don’t want to display a GUI. What is it about respawning in particular that it needs to be handled by the API and not your script that is already doing almost the same thing?

[quote] PlayerGuis are not better off being entirely persistent, and if they were you’d certainly want a simple “RefreshOnRespawn” property in ScreenGui. Heck, even making certain games playable depend on being able to reset playergui stuff, since poorly scripted games may run into a bug with guis/ localscripts but simply be refreshed with a character reset.

Thinking back on all my projects, I’d say over 50% of my screenguis are better off refreshing every time the player respawns, while a select few would be really nice if they could avoid it. [/quote]
Utter nonsense. Why would they be better off? Why should one have to deal with the entire state of a GUI being reset just because the character respawns? It doesn’t make any sense. Every time I’ve worked with GUIs, the resetting behavior has been the most obnoxious roadblock I’ve encountered.

[Aurarus]

[quote] And no, you can’t phase it out to begin with. There’s no guarantee that games will even update. The reason dynamic light was able to be added is because there’s a GlobalShadows property. The reason smooth terrain was added is because you have to intentionally convert your place to smooth terrain. The only way to “phase in” new behavior is to archive ResetPlayerGuiOnRespawn and display it in the properties window, but as Aurarus said earlier you’re just moving to a different side of hell – it doesn’t solve the underlying issue.
[/quote]
First, make ResetPlayerGuiOnSpawn a normal property that isn’t all weird and hidden. Second, make it on by default for old places, and off by default for new places. This is exactly how GlobalShadows works. GlobalShadows even introduces a behavioral change (i.e. Ambient), which everyone seems to have dealt with just fine.

Resetting wasn’t what I was referring to. Your belief is that GUIs should not reset automatically and you should manage all of the GUIs manually and reset them to their default states when it’s appropriate, correct? GUIs inside tools goes against that principle. Instead of having one ammo GUI in the PlayerGui and updating the GUI’s ammo box whenever you equip/unequip a tool, you’re copying and pasting the same ammo GUI into each tool. In other words, instead of using one and manually keeping track of and managing GUI states, you’re letting ROBLOX handle state changes automatically + you’ll just end up with flicker between the duplicate GUIs when you switch tools, so I don’t know why you’d want to do that in the first place.

The next great thing about it is that you don’t have to use it. You can continue managing your GUIs in a global way. Combined with the gradual adoption mentioned above, current games can continue functioning the same way, while new or updated games can use either the modular or non-modular system. The point here is to stop forcing Tools to use GUIs in a non-modular way. Make a few Gear and you’ll understand why modularity is important for Tools.
The only problem is that current tools may already be storing GUIs as descendants, which means they would start rendering unintentionally. If this turned out to be a major issue, it could be worked around with a simple property in Tools that toggles rendering of GUIs.

That is a mess and I’ve already made my point on that as well. Resetting a GUI on respawn or not is related to the GUIs themselves. It belongs in the API and not some ugly, loose script. When you use a feature you shouldn’t have to hack together something else just to be able to use it.

You already have to use scripts to handle all the cases where you don’t want to display a GUI. What is it about respawning in particular that it needs to be handled by the API and not your script that is already doing almost the same thing?

[quote] PlayerGuis are not better off being entirely persistent, and if they were you’d certainly want a simple “RefreshOnRespawn” property in ScreenGui. Heck, even making certain games playable depend on being able to reset playergui stuff, since poorly scripted games may run into a bug with guis/ localscripts but simply be refreshed with a character reset.

Thinking back on all my projects, I’d say over 50% of my screenguis are better off refreshing every time the player respawns, while a select few would be really nice if they could avoid it. [/quote]
Utter nonsense. Why would they be better off? Why should one have to deal with the entire state of a GUI being reset just because the character respawns? It doesn’t make any sense. Every time I’ve worked with GUIs, the resetting behavior has been the most obnoxious roadblock I’ve encountered.[/quote]

It keeps it simple for scripts that need to tag the character/ character’s humanoid/ particular tools in the player’s backpack.

It also works as a way to get around GUI breaking bugs by refreshing the entire PlayerGui + the scripts in it when the script breaks.

Your proposition is 2 extra properties while we’re asking for just a single one in an object that comes lacking in properties.
Plus, no one is asking for the tool + Gui feature. Cloning a GUI into the PlayerGui is way easier than refreshing variables to the CharacterAdded event.

You’re also failing to recognize the countless scripts floating around in free models with the playergui reseting in mind.

Additionally, you compare changing the fundamental behaviour to a service most games depend on to an aesthetic feature that is simply an addition.

New games work with dynamic lighting because they see the new problems they are confronted with. This area is dark with this NEW setting? Let me add this NEW light feature here.

Whereas with persistent UI, the bugs will be sprouting randomly and out of nowhere. “My footsteps don’t make sound when I respawn! Help!!!”

[TheAmazeman]

Things I learned from this thread:

ResetPlayerGuiOnSpawn should be a visible property for StarterGui.

New games should auto set ResetPlayerGuiOnSpawn to false because it is better practice and allows for more possibilities with games (sounds able to keep playing, a gui to pop up as your character dies, etc), and is also more efficient by not reloading any local scripts within the GUI every character respawn.

Old games should not be messed with so that everything still works.

If your GUI scripts are breaking and that’s why you want it to reset every character respawn, then that means your scripts should be recoded to not break.

Story for why setting ResetPlayerGuiOnSpawn to false is so powerful:

Last summer I wanted to be able to keep playing a sound in the GUI even if someone died. I didn’t want it to reset. I went all hacky to try to make it so the player could never actually die. Changed the humanoid name so they couldn’t reset, and it was a disaster game, so that made it soo much harder. If something hit you it would check if the damage would get you below 0 health, and if it did it would make a ragdoll and teleport your real body to the lobby with camera still on the ragdoll for a few seconds. All because I didn’t know about being able to set ResetPlayerGuiOnSpawn. When I found out you could have GUIs not reset I was so happy and got rid of all of that hacky workaround stuff.

So when ResetPlayerGuiOnSpawn is not visible by default it is a real bummer for anyone that really wants to have it not reset (and that does not previously know about it)

[EchoReaper]

If your GUI scripts are breaking and that’s why you want it to reset every character respawn, then that means your scripts should be recoded to not break.

That was a poor reason that Aurarus brought up. The most relevant reason is that it automatically cleans up the GUI. Have 20 different shops? Now you don’t have to loop through your GUI on respawn “if shop1open then removeshop1 elseif shop2open then removeshop2 … elseif shop20open then removeshop20.” It’s the most user-friendly way possible.

And jesus christ you people – stop attacking the idea of PreserveOnRespawn. How many times have I explained there are more greenhorn scripters on ROBLOX than anyone? It is ROBLOX’s principle to make things easy to use on ROBLOX.

Sound.PlayOnRemove
-Accomplishable with 5 lines of code and scriptable, yet ROBLOX implemented it anyway for ease of use

StarterGui.ShowDevelopmentGui
-Can be accomplished by adding them to a serverscript which clones its children to the playergui on characteradded. ROBLOX added it anyway.

WaitForChild
-Can be accomplished by repeat wait() until parent:FindFirstChild(childName), yet ROBLOX added it anyway

IncrementAsync
-Can be accomplished with UpdateAsync and adding n to oldValue. ROBLOX added IncrementAsync anyway

Seat.SeatOccupant
-Can be accomplished by seat.SeatWeld.Part1.Parent.Humanoid, yet 22 people voted for it on the trello and a staff member said something along the lines of “You have to know how seats work for that and it’s not very user-friendly” and they added it

I don’t know what I have to say that it doesn’t matter that it’s scriptable (I don’t even know why you’re attacking it so viciously just because of that) – ScreenGui.PreserveOnRespawn is more intuitive and can be understood by any level of scripter – even level not-a-scripter., just like SeatOccupant can be used by anyone.

Stop de-railing and attacking the thread. It’s up to ROBLOX to decide whether this is useful enough to be added / the demand is large enough. Your personal preferences have no impact whatsoever on whether ROBLOX will implement it or not – they’re irrelevant. Stop posting irrelevant replies to the OP and stay on topic. Stop this completely unwarranted witch hunt on PreserveOnRespawn and let the staff do their job and decide whether it’s useful or not.

[TheAmazeman]

I actually never attacked or even mentioned the idea of PreserveOnRespawn, I don’t really mind it. I am completely meh about the idea, because I will never use it. If they want to add it I won’t be mad, if they don’t add it I won’t be mad. But what I did present in my post is some ideas to make what you’re wanting to do possible. -Being able to stop the reset of GUIs on respawn because of setting ResetPlayerGuiOnSpawn to false.

Question though, if you want to reset some GUIs on respawn, and not others. What are you doing differently to the GUIs that don’t reset compared to the GUIs that reset. With ResetPlayerGuiOnSpawn set to false, can’t you account for what GUIs need to be visible or invisible in a humanoid.died function?