[REJECTED][SUG][PLAYER] Multiple user profiles.

[namida]

Would anyone like to have this feature?

I've already coded it (Nepster / IchoTolot: see "feature/profiles" branch on my repo), but it could be slightly intrusive, and of course is a new potential source of bugs - so I think we should only integrate this feature into NL if there's community interest in having it.

The settings, hotkeys and progression for each profile is independent. Of course, if you've got multiple profiles that you use and you want to copy settings between them, you can do so just by copy-pasting a file. There's also a Guest profile, which if selected, data isn't saved.

If you're the only person on your computer, and you don't want to use multiple profiles for any other reason, there's an option to select a profile to automatically start NeoLemmix with. Likewise, being prompted to select a profile in testplay mode could get really annoying, so you can also select a profile to automatically use for testplay mode (if you don't select one, it uses the guest profile).

[Nepster]

In principle this is a good idea, but I have a few problems with the details (or perhaps I just misunderstood some points):
1) It's totally fine to ask for a username input the very first time NeoLemmix starts (similar to how we ask for high/low-res settings and hotkey layout). However I think it will be annoying if this pops up any other time, except on explicit user input that asks for this. In other words: We should copy the way Lix handles this.
2) Similarly, I would like the automatic selection of the previously used profile (even if it may just be the guest profile) to be the standard setting. Actually I would even pose the question: Do we even need a settings option to disable automatic profile selection?
3) The guest profile (rename this to "default" perhaps?) should still save all the data. I totally expect lots of users to consistently play on this profile, because they are the only ones playing on their computer. At least if the amount of people using Windows under the default admin account is any indication...
4) Regarding the "save progression for each user" feature: Could we save the profile name to all the replay files. When running a replay (whether manually loaded or in mass replay check mode), we can then check for the profile name match to determine whether to save the progress. There was already a feature request in that regard, but I deemed it too much work for too little gain. But with already coded user profiles, it should be reasonable fast to add (at least a non-perfect solution that just works in 99% of all cases and possibly fails on edge cases like loaded and slightly modified replays).
Edit: Oh, you already found the other feature request and posted there. Didn't see that previously
5) Regarding testplay mode: This could become annoying if it behaves differently than usual gameplay regarding profiles (especially as the hotkeys and settings are profile-specific). I would rather use the usual automatic profile selection, but completely disable saving the progression. Or am I missing other reasons not to use the main account for playtesting own new levels from the editor?

[IchoTolot]

I've already coded it (Nepster / IchoTolot: see "feature/profiles" branch on my repo), but it could be slightly intrusive, and of course is a new potential source of bugs - so I think we should only integrate this feature into NL if there's community interest in having it.

Dumb question: Where is the repo?

I only got the link to Nepster's bitbucket right now -- or I totally forgot that I have your link already (if so sorry ).

[Nepster]

Here: namida's bitbucket repo

[Simon]

I advise against multi-user support.

We should copy the way Lix handles this.

I ditched profiles from Lix in 2018. I write the username (important for replays, network games, ...) into the single options file. When you change that name in the options, all other options and trophies remain.

I find in-game multi-user-support purely a feel-good feature for devs, to make us feel like we're getting really important work done. I implemented multi-user in Lix ten years ago, I thought it had to be really important and solve lots of problems. But nobody ever needed it in Lix. And nobody had asked for it, neither before the impl or after the cut.

Also it's a source of confusion first, and bugs second. Confusion because you need a global file to store current username, and then an extra file per user, even if it's just one user in 99,x % of cases; who will want the feature anyway? Any of the devs that shares a computer? No? Then who from the nondevs has asked for this feature?

If two people are already sharing a session (of login in an operating system), they won't bother changing the user in the NL options. They'll merely play with the current name, and solve levels together.

Windows is particularly confusing. Assume you have NL in a no-writeable dir: Can happen when you're logged in as a non-admin because you happen to care about security, or, even less likely, because you have several user accounts on your home machine and thus want privacy w.r.t. other machine users. Then Windows generates written files in your hidden user dirs anyway, C:\Users. And then your NL global options file goes into that Windows per-user dir, and the NL per-NL-user options go into that Windows per-Windows-user dir. You'll duplicate effort and confusion that the OS has already solved/inflicted on you.

I don't even expect multi-user support by any application, I expect apps to rely on the OS.

Please carefully consider:
You can remember a player name as a normal option (without multi-user support).
You can move options/trophy files to get any perceived benefit of multi-user support.
To test options code automatically, you can refactor and isolate (no need for user features).

Why is this not enough and we need the complex feature instead?

-- Simon

[namida]

I've put a poll up, because I know a lot of people have an opinion but don't want to write out a post explaining it. Based on the posts so far though, it does look like this is a feature that's probably going to the trash pile.

[namida]

Well, it looks like there's not even enough interest in this feature for people to bother voting. Given that the few responses are all against it, I think it's safe to say this feature should be rejected.