Reset world skin, or work on temporary copy in Feature Requests

Page: 1 2 3
ID:100947
 
Aug 26 2010, 3:48 am
Resolved
Calling winset(player, null, "reset=true") will reset the user's skin, removing any runtime controls and cloned windows. Parameters that are saved are still saved/loaded as normal.
Applies to:DM Language
Status: Resolved (496)
This issue has been resolved.
Duplicates:id:107200
When creating windows and controls at runtime, they carry over between reboots. This may not always be desirable if the controls are dynamic and context sensitive.

A way to prevent these changes from being saved by either working on a temp version of the skin file or re-downloading the skin from the server would be great. Something simple similar client.control_freak (which does not prevent this).
#1 Sep 5 2010, 11:11 pm
471.1076 Release Notes:
"When connected to another server via link() or when reconnecting to the same world, the skin will no longer reset to its original state, remove cloned panes and windows, or delete any controls created at runtime. This should provide a smoother transition when switching between servers."

Can this be made optional? Or can a parameter be added to controls that individually determines if they carry over? "persistent" or something to that effect.

It's hard enough to create controls at runtime without having to first double check what's there already :P
#2 Sep 29 2010, 11:15 am
I'd like to second this. When I do an interface update a lot of people have to manually clear their skin because it doesn't want to update properly due to old settings.

Not to mention when somebody has multiple windows open during a reboot or reconnect or certain radio buttons selected and so on, all of that saves even though the windows no longer work and the selected buttons aren't the default settings. I'd rather not check every thing and reset it if needed. Especially when working with 20+ windows and many different settings.
#3 Sep 29 2010, 12:59 pm (Edited on Sep 30 2010, 2:48 am)
I was going to make a new feature request, but it seems like it should just go along with this.
A winreset() proc could be added, which can take a specific control, or an entire window. If a window is sent, it will reset all the controls (on that window) and the window to their default settings. There could also be an option, maybe when the argument is left blank, to reset the entire interface. Though you might also want to be able to reset the window without resetting any controls on it... Eh, oh well, there's the general idea.
#4 Jul 2 2011, 6:21 pm (Edited on Jun 24 2012, 11:10 am)
I can't believe this isn't implemented yet, it's been almost a year, it seems like such a simple feature especially since it was -disabled- in a previous update. :|

#5 Apr 21 2012, 10:37 am (Edited on Jun 24 2012, 11:10 am)
Totally bumping this.

#6 Apr 30 2012, 9:31 pm
Holy crap, yes, this is ridiculously annoying. I've just written an insane amount of interface options and it would cause a severe hang time on reboot to have to reset all of them. I guess Chatters is a good example of how this feature is necessary. It is incredibly unintuitive to have to assume that the skin is non-default on startup.
#7 May 4 2012, 8:48 pm
Keeping the interface with the same settings would be necessary to make a seamless transition for, say, an RPG with popups and toggable buttons and such. But I think that's the exception. So maybe it'd make more sense to have it togglable. That way users that want to keep the exact same setup have the choice of sending along data about the settings that are toggled, so it knows what to do.
#8 Jun 21 2012, 4:09 pm (Edited on Jun 24 2012, 11:11 am)
I still don't understand why this hasn't been added, or even had a comment by Tom or Lummox JR.

#9 Jun 21 2012, 4:13 pm
We'll take a look at this for the next version.
#10 Jun 21 2012, 6:23 pm
This feature was added to allow you to link() seamlessly, which is pretty important if you want to use link(). However, in those cases you're transferring the player from one place to another - It would make sense to tie a time-stamp as well as world.version together with the saved state, such that:

A skin is considered in need of an update on join, if:
- The last disconnected time for the client in this world is further in the past than world.skin_threshhold or the world.version is not the same, force a re-load.

That satisfies the problems described here, as well as still allowing link() to actually function. If you want to also support always loading the skin no matter what, and never reloading the skin no matter what, you could use a bitflag world variable to set this, such as:

world.skin_reload = ALWAYS || NEVER || ON_UPDATE


With a default set to ALWAYS, and ON_UPDATE satisfying the above criteria for classifying an 'update'.
#11 Jun 21 2012, 6:57 pm
I think a client variable would make more sense, following in line with preload_rsc. Assuming that DS knows if a connection is "fresh", from a link() from an identical binary, or from a reboot, I think the following flags would be more simple:

var/const/RELOAD_ON_REBOOT = 1 // Reloads on reboot
var/const/RELOAD_ON_LINK = 2 // Reloads on link to other world

client/var/force_skin_reload = 0 // Default, reloads only on fresh connection or interface file update (current behavior?)
#12 Jun 21 2012, 6:59 pm
It would definitely need to be a /client variable. Not just because of preload_rsc, but because of control_freak. Interfaces are a client-by-client thing.

Also, huzzah. My incessant bumping of this got it some recognition.
#13 Jun 22 2012, 8:17 pm
See though, I don't understand how it was supposed to help with link().

Let's assume that you have a radio group in the interface. If you link() over to another server, the radio group doesn't reset, and you have to manually check and set the client's corresponding variable or reset the radio group. Now let's assume that you just send the appropriate data with the client in link(). Great! All of that work with setting the interface on link() has been handled efficiently....

Except now, every other scenario is handled terribly. What if you want to connect to another server of the same game and you don't want to carry over all of the skin settings? What if the client reconnects? What if a client connects to another server using a link in the chat or the interface rather than link(), or what if they use .url in the commands? Now in no situation can you rely on your skin being set to default, even on a new connection. By default, you have to assume that the skin is non-default and you end up having to winset() everything in the interface to it's default settings. Now you have the start-up issues that Chatters has because you're calling a metric f***-ton of winset()s or one ridiculously long winset() when a player connects.

The whole idea completely disregarded any ascenario that wasn't a successful use of link().
#14 Jun 23 2012, 1:07 pm
In response to Hiro the Dragon King (#13)
Hiro the Dragon King wrote:
Let's assume that you have a radio group in the interface. If you link() over to another server, the radio group doesn't reset, and you have to manually check and set the client's corresponding variable or reset the radio group. Now let's assume that you just send the appropriate data with the client in link(). Great! All of that work with setting the interface on link() has been handled efficiently....
Except now, every other scenario is handled terribly. What if you want to connect to another server of the same game and you don't want to carry over all of the skin settings? What if the client reconnects? What if a client connects to another server using a link in the chat or the interface rather than link(), or what if they use .url in the commands? Now in no situation can you rely on your skin being set to default, even on a new connection. By default, you have to assume that the skin is non-default and you end up having to winset() everything in the interface to it's default settings. Now you have the start-up issues that Chatters has because you're calling a metric f***-ton of winset()s or one ridiculously long winset() when a player connects.

It sounds like you can use savefiles to get around this. If the user checks a box to change some setting in the game, there should be some record of that in the server - just save those settings. You shouldn't have to use winget() to read the value from the client. When the player connects to a game you'd load their settings and use winset() to make their form show the proper values, not the other way around.

I can't figure out why people use interface controls so much. It sounds like they cause a lot more trouble than they're worth.
#15 Jun 23 2012, 1:17 pm
And using a savefile isn't a catch-all situation, either. You can connect to other instances of the same game and the interface doesn't reset. You can actually even mess with things like radio groups and toggled menu options while the skin isn't actually connected to a server. There are just too many unknown variables.

Using winget() isn't the issue, either, and I definitely don't do it. I use the client's saved settings, and anything that isn't in the save-file is reset. I actually have page-length winset() call that sets every single interface element to their default settings.

Interface controls can be used well, and that is why I use them.
#16 Jun 23 2012, 1:33 pm
If you have to set the form to match a user's settings when they connect to a server, there's no way around it. Having the form simply reset wouldn't be sufficient. For parts of the interface that aren't populated by settings from a savefile you do need to reset the interface but you should already have the procs for managing the interface.

With all the different ways someone can connect or reconnect and all the different ways you might have your interface work, it sounds like most people will need to develop something that's specific to their game (just resetting the whole thing wouldn't help many people). It sounds like this is what you'd want:

Falacy wrote:
A winreset() proc could be added, which can take a specific control, or an entire window. If a window is sent, it will reset all the controls (on that window) and the window to their default settings. There could also be an option, maybe when the argument is left blank, to reset the entire interface. Though you might also want to be able to reset the window without resetting any controls on it... Eh, oh well, there's the general idea.
#17 Jun 23 2012, 1:42 pm
In response to Forum_account (#16)
You can't make any assumptions about the state of the interface right now, so why would you reset only parts of it? I think it makes more sense to reset the entire thing and know you're always starting from a blank slate, then you're just handling one case instead of many. It doesn't matter if they're a first-time player, reconnecting from a reboot, ect--they all need the same settings changed if you just wipe the skin.
#18 Jun 23 2012, 1:54 pm
DarkCampaigner wrote:
You can't make any assumptions about the state of the interface right now, so why would you reset only parts of it?

If you only have the options to reset the entire thing or reset nothing, it doesn't help you for the case where you need to reset some parts. In realistic situations you'll have part of the interface that needs to be reset and part that doesn't. If you had a winreset() proc you could easily implement whatever kind of resetting you need.
#19 Jun 23 2012, 2:10 pm
In response to Forum_account (#18)
Forum_account wrote:
In realistic situations you'll have part of the interface that needs to be reset and part that doesn't. If you had a winreset() proc you could easily implement whatever kind of resetting you need.

What part wouldn't need to be reset (or rather, what parts would be harmed by being reset)? For any controls that shouldn't be at their initial state, you'll have to set them up anyways because you don't know if its a fresh connection (and everything is already at its initial values) or if its a reboot/link (and has already been set up).
Page: 1 2 3