[0.15] Mod setting/config interface - give your input

[folk]

@rseding There might be another, much more sneakier problem on the horizon. I have not tried to replicate it reliably, because frankly the parameters of the problem I built up in my head make it hard to replicate;

1. I started off by adding 4 options, like you can see from my post above. Like you can also see, they were all tests.
2. I renamed the first option and started fiddling around, and got it working like I want.
3. I removed the 3 other test options and added 1 new one. There are now 2x int-options exclusively.
4. After loading up the savegame, settings.get contained a boolean-value for the newly-added option.
5. If I went to the mod options screen and clicked the Reset and Reload buttons, the interface would swap between a text field with a number in it and a checkbox.

I frankly have no idea if the steps above reproduce it, but it does feel like this might be a bug in how your store the options - it seems to me like the 2nd "real" option I added after I removed the 3 fake ones inherited the boolean value from my test setup posted above - as you can see, the 2nd option in the test setup from the post above is a boolean-option.

This leads me to believe that the settings and the values are stored in two tables on the backend, and that both tables are indexed - and that they are not "cleaned" properly when required.

In any case, enough rambling.

EDIT: Also, it might be good if you show the cfg-description text on hover of the input fields/checkboxes/whatever as well. If at all possible - I know you guys are not pleased with the UI library.
I can also, from personal experience, tell you a few more things people will be asking for quite soon, that you might as well add to the TODO
1. Show mod name instead of ID
2. Collapsible mod-options structures that remembers toggle, you know like

Code: Select all

[+] mod-name-that-is-collapsed
[-] expanded-mod
    - setting 1
    - setting 2
[+] another-collapsed-mod

3. Colors in the description text
4. Individual reset buttons per mod

Thanks for reading.

[Supercheese]

The 0.15 changelog says:

Added support for mod settings: startup, runtime, and runtime-per-user.

Startup and runtime-per-user work, but Factorio does not like it when I set:

Code: Select all

setting_type = "runtime",

[Rseding91]

The 0.15 changelog says:

Added support for mod settings: startup, runtime, and runtime-per-user.

Startup and runtime-per-user work, but Factorio does not like it when I set:

Code: Select all

setting_type = "runtime",

It's "runtime-global".

[folk]

I posted the improvements I mentioned above to viewtopic.php?f=6&t=44799

[ZlovreD]

I can't find a way to get access to startup setting.
I've noticed what they stored in root\mod-settings.json file. But it's looks useless or than just for save them between restarts.
So.. or change data.clear(self) to something like that:

Code: Select all

data.clear = function (self)
	for k, v in pairs(self.raw) do
		if k ~= 'bool-settings' or
			k ~= 'int-setting' or
			k ~= 'double-setting' or
			k ~= 'string-setting' then
			self.raw[k] = nil
		end
	end
end

Or needs another working way to get acces to them in data load stage.

[Rseding91]

I can't find a way to get access to startup setting.
I've noticed what they stored in root\mod-settings.json file. But it's looks useless or than just for save them between restarts.
So.. or change data.clear(self) to something like that:

Code: Select all

data.clear = function (self)
	for k, v in pairs(self.raw) do
		if k ~= 'bool-settings' or
			k ~= 'int-setting' or
			k ~= 'double-setting' or
			k ~= 'string-setting' then
			self.raw[k] = nil
		end
	end
end

Or needs another working way to get acces to them in data load stage.

You access them in the data stage by accessing "settings" - a global table with all startup settings only available in the data loading stage.

[ZlovreD]

I can't find a way to get access to startup setting.
I've noticed what they stored in root\mod-settings.json file. But it's looks useless or than just for save them between restarts.
So.. or change data.clear(self) to something like that:

Code: Select all

data.clear = function (self)
	for k, v in pairs(self.raw) do
		if k ~= 'bool-settings' or
			k ~= 'int-setting' or
			k ~= 'double-setting' or
			k ~= 'string-setting' then
			self.raw[k] = nil
		end
	end
end

Or needs another working way to get acces to them in data load stage.

You access them in the data stage by accessing "settings" - a global table with all startup settings only available in the data loading stage.

And there is a problem:

Code: Select all

	[rocket-silo-rocket-shadow] =>  {	-- <table: 0x00000262a4f57ef0>
		[rocket-silo-rocket-shadow]
	}
	[selection-tool] =>  {	-- <table: 0x00000262a5294dd0>
		[dummy-selection-tool]
	}
	[simple-entity] =>  {	-- <table: 0x00000262a4753740>
		[medium-ship-wreck]
		[red-desert-rock-big-01]
		[red-desert-rock-huge-01]
		[red-desert-rock-huge-02]
		[small-ship-wreck]
		[stone-rock]
	}
	[simple-entity-with-force] =>  {	-- <table: 0x00000262a4f59e70>
		[simple-entity-with-force]
	}

There is no ['settings'] field. =)
Looks like data.raw erased after setting stage and json updating.

[orzelek]

I can't find a way to get access to startup setting.
I've noticed what they stored in root\mod-settings.json file. But it's looks useless or than just for save them between restarts.
So.. or change data.clear(self) to something like that:

Code: Select all

data.clear = function (self)
	for k, v in pairs(self.raw) do
		if k ~= 'bool-settings' or
			k ~= 'int-setting' or
			k ~= 'double-setting' or
			k ~= 'string-setting' then
			self.raw[k] = nil
		end
	end
end

Or needs another working way to get acces to them in data load stage.

You access them in the data stage by accessing "settings" - a global table with all startup settings only available in the data loading stage.

And there is a problem:

Code: Select all

	[rocket-silo-rocket-shadow] =>  {	-- <table: 0x00000262a4f57ef0>
		[rocket-silo-rocket-shadow]
	}
	[selection-tool] =>  {	-- <table: 0x00000262a5294dd0>
		[dummy-selection-tool]
	}
	[simple-entity] =>  {	-- <table: 0x00000262a4753740>
		[medium-ship-wreck]
		[red-desert-rock-big-01]
		[red-desert-rock-huge-01]
		[red-desert-rock-huge-02]
		[small-ship-wreck]
		[stone-rock]
	}
	[simple-entity-with-force] =>  {	-- <table: 0x00000262a4f59e70>
		[simple-entity-with-force]
	}

There is no ['settings'] field. =)
Looks like data.raw erased after setting stage and json updating.

It should be a separate table. Tried dumping table named settings ?

[Rseding91]

The "settings" table is not part of data or data.raw. It's like "game" - you just access it directly.

[ZlovreD]

The "settings" table is not part of data or data.raw. It's like "game" - you just access it directly.

Heh.. old habits die hard.
But its strange. If dump 'data' in settings.lua then we get all settings, or at least my own, as part of 'data.raw' (both startup and runtime)

Code: Select all

0.187 Script settings.lua:84: [[data]]
{	-- <table: 0x0000015069f645b0>
	[clear] => (function) "function: 0x000001506a31d230"
	[extend] => (function) "function: 0x000001506a31cc70"
	[is_demo] => (boolean) "false"
	[raw] =>  {	-- <table: 0x0000015069f64130>
		[bool-setting] =>  {	-- <table: 0x0000015069f63770>
			[name-test2]
		}
		[string-setting] =>  {	-- <table: 0x0000015069f631d0>
			[name-test3]
			[name-test4]
		}
	}
}

And then only 'startup' moved into separate variable.

Code: Select all

0.862 Script data-final-fixes.lua:50: [[settings]]
{	-- <table: 0x0000015069f6b5d0>
	[startup] =>  {	-- <table: 0x0000015069f6c1d0>
		[name-test1] =>  {	-- <table: 0x0000015069f6c290>
			[value] => (number) 5
		}
	}
}

But other settings like map-settings and map-gen-presets stored in data.raw.

I'm assume is better to place all settings in one place and as part of data array (data['settings']). It's simply helps to prevent cases of overwriting settings by accidentally.

[ZlovreD]

Also few bugs:

Name of settings partially cut on left side and need to add 4+ spaces before them in loc file.


And 'description' key has no effect. But works fine with 'name' key

Code: Select all

[mod-setting-description]
name-test1=description-test1

[Rseding91]

Also few bugs:

Name of settings partially cut on left side and need to add 4+ spaces before them in loc file.


And 'description' key has no effect. But works fine with 'name' key

Code: Select all

[mod-setting-description]
name-test1=description-test1

That's already fixed for the next version of 0.15

[Rseding91]

But other settings like map-settings and map-gen-presets stored in data.raw.

Those aren't mod settings. Mod settings are a completely different thing from the normal data prototype loading stage.

Also "runtime" settings aren't available in the normal data prototype stage because they're just that - runtime settings. They must have zero impact on how the prototypes are created because you can change them runtime and if they altered how prototypes are built it would cause desyncs when you reload the game or join an MP game.

[ZlovreD]

That's already fixed for the next version of 0.15

Sweet..

But other settings like map-settings and map-gen-presets stored in data.raw.

Those aren't mod settings.

But it's still settings =))

Also "runtime" settings aren't available in the normal data prototype stage because they're just that - runtime settings. They must have zero impact on how the prototypes are created because you can change them runtime and if they altered how prototypes are built it would cause desyncs when you reload the game or join an MP game.

Yeah, I know it. I've just suggested is to move all similar and / or logically related data into one "container", rather than distributing them to different ones. That's all.

[ZlovreD]

Btw, what is a real point to load settings-final-fixes before relative data stage ?

Code: Select all

   0.191 Loading mod settings ZTestMod 1.0.0 (settings.lua)
   0.192 Loading mod settings ZTestMod 1.0.0 (settings-final-fixes.lua)
   0.196 Loading mod core 0.0.0 (data.lua)
   0.207 Loading mod base 0.15.1 (data.lua)

[Rseding91]

Btw, what is a real point to load settings-final-fixes before relative data stage ?

Code: Select all

   0.191 Loading mod settings ZTestMod 1.0.0 (settings.lua)
   0.192 Loading mod settings ZTestMod 1.0.0 (settings-final-fixes.lua)
   0.196 Loading mod core 0.0.0 (data.lua)
   0.207 Loading mod base 0.15.1 (data.lua)

Because settings - again - are completely different from normal prototypes. They're run in their own Lua context and are built fully independent from any other prototype in the game.

After that the *startup* settings are available to read in the normal prototype setup process. The settings must always have the same values at startup independent of the rest of the prototypes because when you join an MP game it loads the settings from the MP game and the end result must be identical to what the running game has - meaning they can't change based off what the player sets unless they're the startup type (which can't be changed runtime).

[ZlovreD]

After that the *startup* settings are available to read in the normal prototype setup process. The settings must always have the same values at startup independent of the rest of the prototypes because when you join an MP game it loads the settings from the MP game and the end result must be identical to what the running game has - meaning they can't change based off what the player sets unless they're the startup type (which can't be changed runtime).

That means 'settings', 'settings-update' and 'settings-final-fixes' is simple copy-paste from data load stages and there is no reasons to search any hidden functionality for now?
Sorry if i'm looks like meticulous perfectionist.

[Rseding91]

After that the *startup* settings are available to read in the normal prototype setup process. The settings must always have the same values at startup independent of the rest of the prototypes because when you join an MP game it loads the settings from the MP game and the end result must be identical to what the running game has - meaning they can't change based off what the player sets unless they're the startup type (which can't be changed runtime).

That means 'settings', 'settings-update' and 'settings-final-fixes' is simple copy-paste from data load stages and there is no reasons to search any hidden functionality for now?
Sorry if i'm looks like meticulous perfectionist.

Yes

[swni]

Really enjoying the new mod configuration options, all I need now is to figure out how to use it! Thanks to Rseding91 and folk for your explanations so far; I was able to get a simple mod with a runtime-per-user setting working by following folk's example mod, but am about to embark on something more complicated and was looking for more information.

So:

What is the difference between startup, runtime-global, and runtime-per-user? E.g., which ones are accessible where (such as control.lua and data.lua). If a user changes a setting from the main menu (i.e., there is no game running), and then loads a game, does the loaded game see the old values for the settings or the new values? (I assume "startup" means it only changes new games, whereas runtime means it also changes existing games.) If a user changes a setting from within a game, and then loads a different game, what happens?

Specifically I'm interested in settings for a mod that affects map generation, so I'm assuming "startup" is most suitable for that use case.

What is the lua interface for reading the settings? I am aware of settings.get_player_settings(<LuaPlayer>)[<SettingName>].value but when I tried to dump the "settings" table to see what other interface options there might be I didn't see any. (I guess it's all hidden behind a metatable.)

I noticed that setting names are global across all mods. That's a bit inconvenient, because it forces the use of really long setting names to avoid accidentally clobbering someone else's mod. It would be nice if settings where namespaced by mod, and perhaps by default you only see your own mod's settings, but there was a way to examine settings belonging to another namespace if for whatever obscure reason you needed to look up the settings for another mod. (I don't plan on it myself.)

Finally, not really a question about the new interface, but my mod takes arbitrary lua code as part of its configuration... any suggestions from anyone on how to make that less painful on the user? I was thinking of providing several preset configurations in a drop-down box with an option for falling back to config.lua in case the user wanted the full customizability.

[apriori]

Is there any tutorial or documentation about how to realize mod's settings? Examples are welcome. I'd like to know, e.g. how to make a group of radio-options (if possible) and integer variable with upper and lower thresholds (textbox/slider).


EDIT: found right here viewtopic.php?f=34&t=32890&start=40#p258222

Please, post a tutorial/documetation, or it's a military secret?