Forum_account wrote:

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.

That's not the point. The point is that, as the developer, you cannot, at any point, assume that the skin is default, including when a client first connects to the server, in single player, which is just ludicrous.

There is a difference between loading a players settings, changing the skin accordingly, and having to practically create the entire interface upon startup.

Abandoning the argument that Forum_account would like to have, I think we're missing something here.

One thing I haven't yet queried, and something I think needs to be addressed, is how does DM handle linking to alternate versions of the same game. How does it differentiate when it needs to reset the skin?

That wouldn't be it because the resource is dynamic. Hell, the skin changing would change the client's resource files (I think), and dynamically generated icons would change the server's.

Yeah, I've always wondered why we aren't given the option of using saved-params. This actually seems like the perfect application.

Hiro the Dragon King wrote:

One thing I haven't yet queried, and something I think needs to be addressed, is how does DM handle linking to alternate versions of the same game. How does it differentiate when it needs to reset the skin?

What do you mean by "alternate versions"? Switching between two versions of the same game (ex: you are playing version 1 of some game and you're linked to version 2)? Or switching between two instances of the same version of a game (ex: you're connected to a version 2 server and are linked to an instance of version 2 on a different server)?

If it'd reset when you reboot (you keep the same game, same version, same host) I'd expect it to reset for any other case (where you connect to a different game/version/host).

DarkCampaigner wrote:

Couldn't you save that user preference just like the others? That would be even better, because then it would be remembered between separate play sessions instead of only reboots.

You have to save the value, load it, and re-initialize the parts of the interface that had been open. It'd be a lot easier if all you had to do was add a winreset(src, "main-window") call to your Login() proc so the main window was reset and everything else was left alone.

Forum_account wrote:

What do you mean by "alternate versions"? Switching between two versions of the same game (ex: you are playing version 1 of some game and you're linked to version 2)?

Well, yes. For example, playing on version 2.1 and linking to version 2.0 or 2.2.

Or switching between two instances of the same version of a game (ex: you're connected to a version 2 server and are linked to an instance of version 2 on a different server)?

I think that reading what you had written would have cleared up any need for actually asking.

If it'd reset when you reboot (you keep the same game, same version, same host) I'd expect it to reset for any other case (where you connect to a different game/version/host).

Except that, at the moment, it doesn't even reset when you reboot.

While it may not have been clear to you originally, (I was indeed trying to ruffle your feathers) how is it "still not clear"? I quote the part where you quoted myself as saying "alternate versions" and then asked about servers using the "same version". And why must you believe that I am upset?

Right, but we can assume it would because that's the feature that's being requested =)

Right, but you seemed to have been comparing something that we are requesting to happen with something that does happen that we are asking about now.

JBoer wrote:

Is it possible to still retain a smooth transition between worlds while at the same time removing elements that were generated at runtime?

I'm not sure I understand your question. That would depend largely on the game, so... for some? If the game is set up to link() the player from mid-game to mid-game, maybe not. But if the game state differs on either side of the link (ie one's a menu, one has you in the actual game world), you might not want the interface in the same state. We're not asking for a reversal of the feature, just a toggle for when it's not desirable.

I think its getting way overcomplicated with trying to accomodate far too many situations..

There are two usecases:

- You want to reset the skin every time, because you don't use link() and its a bother. This is the case for f.ex. Aaiko, and what brought this request up in the first place now.
- You want to use link() to link mid-game to another instance. In this case, windows resizing, moving to a different area of the screen, etc. etc. look horrible, so you want to save the state of the interface and only do minor edits post-link(). This is the current behavior, which effectively allows for almost completely seamless link()'ing, which makes link() amazing for distributed games. Which is actually an amazingly strong, under-utilized feature of BYOND.

As such, the suggestion of being able to turn 'off' the current behavior makes perfect sense. All of this accounting for a dozen different mini-varieties of games, is feature-bloating something bad. The reason you couldn't just restore after link() was because windows were moving, all controls cleared, red text appeared in the default window, etc. The same can't be said for minor adjustments needed after a link().

Rebooting a computer before connecting to a game, etc. should very obviously not save the state. In those cases, you expect the game to load some things on startup, which is why its okay to save and load state manually there.

I wasn't loving the control_freak approach I did, so instead we went with something actually closer to Forum_account's winreset() approach. However it was unnecessary to add a new proc for this; instead, just calling winset(player,null,"reset=true") will cause a skin reset to happen.