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).
ID:100947
 Aug 26 2010, 12:48 am
|
|||||||||
Resolved
| |||||||||
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. | |
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. | |
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.
| |
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.
| |
We'll take a look at this for the next version.
| |
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'. | |
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 | |
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. | |
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(). | |
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.... 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. | |
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. | |
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. | |
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.
| |
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. | |
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). | |
"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