Implement per-user settings that are available at startup

[Tynach]

I recently asked for help with implementing settings for a mod of mine, and found it was impossible to implement a setting that was both available in the 'data' stage (such as the 'startup' setting type), and could be set separately for each user that joins a server (such as the 'runtime-per-user' setting type).

It's possible I'm still misunderstanding something, like perhaps it only matters if the server uses the mod, and having the mod absent from the server won't prevent users with the mod from connecting? I don't have an easy way of testing that right now though, so I'm just assuming that requiring all users to have the same value set for a 'startup' setting also means the mod must be on both the client and server.

Regardless, I believe that there should be a way to make 'client-side only' (which I presume equates to 'per-user') settings which are available during the 'data' loading stage. Essentially, I'm proposing a new setting_type that could be called 'startup-per-user'. I figured there was value in posting this here as a formal request, rather than just having my post asking for help end on 'not possible'.

Note: the reason why the settings I want to implement need to be per-user and not shared, is because they depend on the characteristics of the user's computer display (and the user's personal preference). It defeats the purpose of the setting if everyone who wants to play on a server together has to have the option set to the same value.

[Rseding91]

Sorry but none of that is possible with how Factorio and mods work. All players in a multiplayer game must have the same startup settings and produce the same data.raw results after all mods have run. There is no such thing as client-side or server-side mods: all mods are just "the game" mods.

Multiplayer is implemented using deterministic lock-step (if that helps you understand why none of this can ever happen)

[Tynach]

Multiplayer is implemented using deterministic lock-step (if that helps you understand why none of this can ever happen)

Multiplayer works perfectly fine when my 'mod' was not a proper mod, but instead consisted of me editing the lua files in the game's own folders to instead hold the values I wanted them to hold.

This consisted of tweaking the values in 'Factorio/data/core/prototypes/utility-constants.lua', modifying 'daytime_color_lookup' and 'zoom_to_world_daytime_color_lookup'.

I can tell you with confidence that changing those two tables does not in any way interfere with multiplayer, and I do not understand why allowing those to be tweaked without informing the server the mod is even installed would be 'impossible'.

It might be difficult to determine which properties can be modded and which can't without interfering with multiplayer, but I would imagine it could be done most easily by making another filename to check for (such as the current 'data.lua' and 'data-updates.lua' files) that is only allowed to modify certain properties that for sure won't affect multiplayer. Then you could make a new type of setting (like I'm proposing to begin with) that can only be read during the loading phase that looks at this new Lua file that's being checked for that can for sure only affect things that don't affect multiplayer.

Besides, the game already has settings like this. Not everyone who joins a multiplayer game has to have the same UI scaling options set, and all I'm proposing is for the same sort of setting to be available to modders! Settings that a server never knows or cares about, and never should!

I feel like this was moved into the 'will not implement' pile way too quickly, or perhaps was grossly misunderstood.

[Rseding91]

Determining what values can be changed and not cause determinism issues is a bag of cats that none of us wants to sign up for maintaining.

Even changing the name of a sprite can theoretically cause issues if any mod uses the name of that sprite in any way that effects the simulation. Detecting and preventing stuff like that just isn't worth it.

[Tynach]

Determining what values can be changed and not cause determinism issues is a bag of cats that none of us wants to sign up for maintaining.

That's why I proposed another phase, stage, or whatever you want to call it. You could have an entirely separate system that doesn't touch 'data', even, to make absolutely certain - and you could simply move things you know for sure won't cause problems into there.

Granted, I do see why that could potentially cause problems. A mod that changes how map generation works could theoretically use the LUT file path for night vision goggles to modify how often trees spawn, to give a random and unlikely example. I suppose it's more than possible that there are cases like that where you (and even myself) might think, "Ok, this for sure would never be used to determine anything that would affect gameplay," and yet someone's managed to find a valid use case for doing so anyway.

Like, maybe someone likes the way mods that modify night time LUTs can make forests spookier, or something, and will try to detect which mods are in use and what their options are to make a forest more or less dense and 'spooky'. Or something. I don't really know, I just like to try to see things from all sides.

Perhaps the safest bet would be to only add new items/options (and maybe provide access to some of the game's own client-side-only settings that are already there) to this new stage/phase/\[insert term here\], though that would not help me with my LUT thing.. But it might help someone else further down the line.