I could add a BoolValue to GUIs named “PreserveOnRespawn” that I don’t want to reset on respawn, but littering GUIs with value objects is messy imo, so I just have a whitelist where I don’t refresh particular GUIs based on their name (i.e. ChatGUI and SpawnTransitionGUI), but that’s not very modular either. If I change the name of the GUI I have to edit the script and if I want to do the same thing in another place I have to copy/paste the script and modify the whitelist so it can be used with the new place.
I wasn’t referring to you specifically. I was referring to a particular someone on a baseless witch hunt for PreserveOnRespawn who continually derails the thread because it didn’t align with his sense of design.
So let me get this straight. In order to tweak a minority of my GUIs to not reset on respawn I have to disable a feature I want completely, and re-create and emulate that same behavior on my own? If you mean “do x until if/when this is a feature”, then that’s what I’m doing already – I want a cleaner way to do this.
I’m very skeptical about this idea. Mostly because everything I do is handled in a way where things don’t need to reset. They handle themselves. I’m with TheAmazeMan. It doesn’t affect me.
Everybody’s opinion here counts. If what we prefer doesn’t matter then there’s really no point in ever commenting on a suggestion thread. You are saying to let the staff do their job when nobody here is stopping them from doing their job. Nobody can stop them from forming an opinion. If it’s related to this feature at all then it is relevant to this discussion and isn’t de-railing. Seems like the words “attack” and “witch hunt” are used to make your thread a victim.
Yes, everyone has given a why, and that is precisely why the thread isn’t going anywhere. One side thinks you should be responsible for manually doing this yourself and the other side thinks that it should just work (coined by zeuxcg on Smooth Terrain Bloxcast) and that manually doing it is unnecessary and messy. Those are opinions and neither side is going to change their opinion because that’s what they think is best. Each person thinks what they believe in is best because of how they develop. Talking to Osyris over Skype yielded the information that he already has ResetPlayerGuiOnRespawn set to false, and without a doubt Anaminus does as well. The two of them consistently work with GUIs that don’t reset automatically and have always manually cleaned them up, so of course they’re going to believe that what they’ve always done is better. Myself, the thirteen people who thanked the OP, and that guy from the regular forums that I posted about previously have always worked with ResetGuiOnRespawn defaulted to true and we prefer ROBLOX to automatically clean up our GUIs (when only a minority of our GUIs, if that, need to be preserved on respawn, why would we turn ResetOnRespawn off?), so we naturally lean to what we’ve always used as well.
And that leads me back to what I was getting at earlier. This is completely a matter of preference at this point and it’s pointless to discuss it further. Only ROBLOX can decide whether this is a feature worth implementing or not.
Now that you’ve explained in more detail, I can see where you’re coming from. You seemed to be giving off the idea that supplying a why was irrelevant in all instances. In this instance, things are at a stalemate which I can definitely see why we could leave it only up to the staff to break it. Usually you could break it by comparing the amount of pros and cons along with the importance of each point. It’s not so clear cut in this instance. Thanks for explaining further. I get where you’re coming from.
Personally I find no use in FilteringEnabled. I think Roblox should prioritize it the least and possibly remove it to clear ways for development in other directions.
Actually, if they make it so that localscripts automatically fire all RemoteEvents/ Functions located inside ReplicatedStorage, it’d make it more user friendly and intuitive for new users to adapt.
[size=2]/s, I actually do like it/ use it but this statement is an example on how infuriating some of the comments here are[/size]
I’ve only had the luxury of being able to clean up GUIs manually for a mere 2 years. Before the wonder of ResetPlayerGuiOnSpawn (if it can be called that, with all of its quirks), I’d been forced to figure out how to work around this feature that you seem to love so much without tearing my hair out. I have my opinions not because of what I’ve always been able to do, but because of what I wasn’t able to do.
Anyway, my opinion is that the addition of PreserveOnRespawn would reinforce the existence of a feature that (in my opiniony opinion) is bad, and therefore, were my opinion taken into consideration, I would not recommend adding it.
I’ve only had the luxury of being able to clean up GUIs manually for a mere 2 years. Before the wonder of ResetPlayerGuiOnSpawn (if it can be called that, with all of its quirks), I’d been forced to figure out how to work around this feature that you seem to love so much without tearing my hair out. I have my opinions not because of what I’ve always been able to do, but because of what I wasn’t able to do.
Anyway, my opinion is that the addition of PreserveOnRespawn would reinforce the existence of a feature that (in my opiniony opinion) is bad, and therefore, were my opinion taken into consideration, I would not recommend adding it.[/quote]
If GUI preservation became mandatory, just remove the API related to preservation, since it’s already automatic
If you’re going to go ahead and flip a switch to drastically change the way GUIs behave, may as well give a middle finger to everyone using the old methods and the preserve properties (if they are added in)
It’ll just be candlelight compared to the wildfire coming from all the scripts on free models not working.
And then add in all the API to have stuff work like it did before, Roblox’s coined pattern, just like every time it decides to change core behaviour or aesthetics instead of simply adding onto. Look to “NoOutlines”, “SmoothPlastic”, “LoadStringEnabled”
Or
Make ResetPlayerGuiOnSpawn visible in PlayerGui properties, and a single new easily understood property to ScreenGuis