There are specific GUIs that it would be undesirable to reset on respawn (i.e. chat) while there are others that it would be desirable to reset on respawn. Switching all GUIs to preserving with ResetPlayerGuiOnSpawn or leaving them all to be reset without ResetPlayerGuiOnSpawn enabled won’t cut it, and we shouldn’t have to set ResetPlayerGuiOnSpawn (which doesn’t even archive) to false and make our own custom PlayerGui cleanup manager. It would be nice if GUIs had a PreserveOnRespawn property that when set to true causes the current PlayerGui cleanup manager to ignore it and not delete it when the player respawns.
This seems pretty easy to script and I’m not sure the use case for it is very common, however I will suggest it at work to see what people think as it seems very easy to implement and would save people writing their own code to do it.
I’m actually more interested now as to why ResetPlayerGuiOnSpawn is hidden and doesn’t archive, I might try to get that changed if there isn’t a good reason as to why it is set up the way it is.
This is how it should have been from the start. Certain GUIs such as health bars and custom chats should persist while other ones such as active effects should not.
Your ui should never be appearing and disappearing, and the code for it certainly shouldn’t be doing that either. This seems like a very lazy way to escape writing proper respawn handling.
[quote] Your ui should never be appearing and disappearing, and the code for it certainly shouldn’t be doing that either. This seems like a very lazy way to escape writing proper respawn handling. [/quote]I’d personally see ResetPlayerGuiOnSpawn gone altogether, but if it has to stay this is a better alternative IMO. I don’t believe your argument is valid however since it makes it easier for younger players and makes it work in a simpler way ‘out of the box’ than at present, which is exactly what ROBLOX should be doing.
Don’t mistake using the tools available to you for being lazy. You may see it as needing respawn handling, but why? Why that way? Is it because it’s that way in other programs? Most programs don’t have physical characters that can respawn. Refreshing the PlayerGui on respawn seems to have worked out very well for ROBLOX. Why do you consider it improper?
“Proper” respawn handling:
Loop through all GUIs that should reset on respawn and set state to default
Current functionality:
Loop through all GUIs – replace each item with GUI in default state from StarterGui
They’re both doing the same thing, but the existing functionality saves us from having to add code to each and every GUI to reset it when you respawn / create a universal local script with an index of GUI names that should be reset on spawn. This is something that pertains to GUIs – it makes sense for it to be controlled through the existing GUI API instead of a loose and ugly localscript / redundant code in each and every GUI. And as woot pointed out, the ROBLOX audience consists of younger people as well who may not even know how to script very well, but would benefit from a property in their GUIs to determine if they reset on respawn or not.
This is such a great middle ground, and I can’t begin to explain how useful this type of functionality would be, or how much easier it’d make handling GUIs
Writing custom code to preserve/destroy GUIs automatically feels like a hack. This should definitely be an option.
I was literally just thinking about this, it’d be incredibly helpful.
I would totally use this for my rpg.
Don’t reset:
-Chat
-Interface
Reset:
-Area Text
-Interactive UI
Just noticed this was posted:
Looks like myself and the people who thanked the OP aren’t the only ones who would find this useful. It’s not like that was an old post either – it was posted a little over half an hour ago. It’s a recurring problem. If you search for the same topic in the forums you’ll find even more threads asking the same thing.
Just unlock “ResetGuiOnRespawn” or whatever so that it appears in the explorer and do it manually
That won’t cut it. If that solved the issue then nobody would be complaining because one script with one line isn’t hard to add to the serverscriptservice. The problem is that this isn’t an either-or situation. Resetting all GUIs won’t work for the ones that shouldn’t reset and not resetting any won’t work for the ones that should reset. This needs to be toggleable on a object-by-object basis.
I’m not sure what the resistance to this is. When your character reloads, all of your GUI is automatically reloaded with it. The request is to tell certain things not to do that because it’s dumb. The resistance to this that I see is that it isn’t dumb and it’s a good idea to deal with it and re-load the old instance manually, adding a spectacular flash on the screen as it flickers back. I don’t get why that sounds better.
This is with a custom chat room in mind. It is a good idea to have the chat stay on your screen when your character respawns, and it is a bad idea to delete it and make another one and then load all of the chat over it again.
1 Like
Okay, it’s outright insta-rage inducing to think anyone could suggest that “this isn’t all that useful”
This is like numero uno problem most people try to deal with when working with PlayerGuis
I haven’t learned about PlayerResetGui toggle thing until recently, because it’s hidden from the startergui properties
And even then you have to choose between 2 hells, with hacky workarounds trying to preserve/ refresh GUI’s for both methods
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.
If PreserveOnRespawn is enabled, StarterGui would only put it inside PlayerGui once, when they first join. After then, it’s done and loaded and doesn’t need to be inserted again and it’s up to us to tell it what to do.
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.
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.
“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.
Personally, I feel like this is poor implementation. There’s no clear indication whether one GUI resets or does not other than a single property in it’s ScreenGui ancestor.
What happens if I put a ScreenGui inside another and only the inner one is “PerserveOnRespawn”? The behavior here is confusing to say the least.
It’s not a bad idea, and I do think it’s important. I think it would be better suited to have another service, although I’m not sure what it would be called which does preserve it’s contents on respawn.
You’re not supposed to put one ScreenGui inside another – if you get unexpected behavior that’s your fault. I doubt ROBLOX recurses through the entire PlayerGui (that’d be a waste) anyway and instead just clears all of the direct children, so if the highest ScreenGui was set to not be reset, none of them would reset, while if the highest ScreenGui was set to reset, then all of it would be reset.