[SUG] Multiple player profiles

Started by Blitz, January 25, 2025, 08:56:25 PM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Blitz

Suggestion: I understand icho a bit but I also have a
start or at least one option and that is that you can have multiple profiles that are all saved in the game files but you can create a profile for example get what you want to be called etc
BUT i know it may sound stupid! 
the game will save this profile as a separate file like it does with lix like the trophies file but here's the catch it creates a whole new copy so it copies all the folders that are assigned to the user and it creates a profile folder which means we have for example Blitz and you can find the profile in the users folder and when you go into the profile you see replays,settings,level completions etc and then we have new profile 1 for example and it's been recreated which means we have a new profile. b and he was newly created that means he has nothing there are folders like settings etc in it but when you open the game it gives you an option either you play Blitz or profile 1 or as GUEST and what would also be good as security maybe if you can make passwords optional but possible.
it would bring more order and it would be more tidy.
I hope it would be possible BUT it's just an IDEA okay?
Tom Wolf :lix-evil:
 https://youtube.com/@blitzlix?si=EE0pCPusomuqjkRp. My Youtube channel

WillLem

#1
Quote from: Blitz on January 25, 2025, 08:56:25 PMthe game will save this profile as a separate file

Multiple profiles could be do-able...

Quote from: Blitz on January 25, 2025, 08:56:25 PMcopies all the folders that are assigned to the user

Can you be more specific about what you mean here? Do you mean copy all the folders in the directory (levels, replays, etc) or do you mean create separate settings (userdata, settings, hotkeys) files for each player?

I'm guessing you mean the latter. That may be fairly easy to achieve and I can see the benefits if multiple players use the same system (families, for example), or if a single player wants multiple player profiles to track different records.

The simplest way I can think of to achieve this would be to append the "userdata" title with the player name (so, "userdata_blitz" for example) and create a separate one for each player. A "select player profile" dropdown in the Config menu would likely be suitable for quick profile-switching, showing the names from each file. Then, wherever the userdata file gets read from/written to, check which profile is active.

Then, do the same for the other settings (settings.ini, hotkeys.ini)...

Decent idea. Anyone else in support of this?

namida

I don't see any harm in it existing.

One slight suggested change to your "how" though - instead of having multiple "userdata_XXXXX" folders, have subfolders of "userdata" for each user.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

Blitz

Tom Wolf :lix-evil:
 https://youtube.com/@blitzlix?si=EE0pCPusomuqjkRp. My Youtube channel

Simon

#4
Blitz, what is the use case?

Several people using the same computer? Do they use different Windows profiles? Do you want one installation of NL (sitting in some central place) to look into the different Windows profiles (and see different options/records/... per user, depending on who is logged into Windows)?

Or do those people all share a Windows profile? Since you're mentioning security, what is the goal? If all this happens in one Windows profile, the people can see/read/modify/erase each other's profile. What do you want to prevent with security?

Or is it for one person who makes several NL profiles? But then why worry about security?

Quote from: namidaI don't see any harm in it existing.

I do. In the best case (least harmful), this complicates the program in three ways:

  • Separate the options into two groups, user-independent and user-dependent. The groups must store separately. The only user-independent option is which user is active.
  • Load the user's option only after loading the user-independent options. Import older NL's user options, i.e., write extra code for backward compatibility.
  • Switch user during execution, to an existing user or to a new user. This touches a global (current user) that affects state across the program, which invites bugs.

Depending on what Blitz wants, this complicates the program a lot. Security features in NL that don't rely on the OS?

Quote from: WillLem on January 25, 2025, 11:05:46 PMDecent idea. Anyone else in support of this?

Consider: Have people keep two NL directories. People already do that to have different NL versions.

Does Blitz want one installation of NL to work with different Windows profiles? Consider: Write options into the OS's user directories instead of into the NL directory where the executable sits. This can be sensible, but it breaks culture, existing users expect the options to be in the executable's directory. I support this in Lix: Immutable program directory, read/write to user directories elsewhere, i.e., rely on the OS's user handling. But it's a compile-time option, I deactivate it for the Windows release. Linux package maintainers must enable it (I tell them in the build notes) so that Lix can be packaged for Linux distros.

I had different profiles in Lix itself, with per-profile options, trophies, ... for the same OS user. I removed all of it. I was very happy after removing it.

-- Simon

WillLem

Tbh, having read Simon's post and looked into what this would entail code-wise, I'm probably not so much in favour of this going ahead either.

Simplest solution of all: install NL multiple times, label each installation folder manually with the user's name, promise not to bother each others' installations.

Further benefits of this: each user can have their own set of levels, replays, mods, etc.

The existing program, without any changes, allows this.