This repository has been archived by the owner on Jun 28, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 8
Config_Flow.txt
Sterling Parker edited this page Oct 23, 2019
·
1 revision
For historical purposes only. Do not edit.
Config Handling between GUI and Lua code
----------------------------------------
The "config state" is all the variables which control how
levels are built and which the user can change in the GUI,
like the game, seed, length, size, etc...
THE LUA VM CONTAINS THE DEFINITIVE STATE
Since the Lua code always has an up-to-date picture of the
config state, nothing needs to be send before level building
can begin. [ Of course there is a small period between the
user selecting a new value in the GUI and that value propagating
into the Lua code. ]
All the "core" state is stored in the OB_CONFIG table,
including the values of the panel modules ("Architecture",
"Monsters", etc). The state of normal modules, whether they
are enabled or disabled and all their option settings, are
stored in each module definition in the OB_MODULES table.
When the user changes a setting in the GUI, such as the "game"
button, the new value is sent to the Lua code via two special
functions:
ob_set_config() -- for core state
ob_set_mod_option() -- for modules and their options
The Lua code will handle inter-dependencies between all the
settings. For example, selecting a different "game" may mean
a different set of engines or a different set of themes become
available. The Lua code will handle that and call various
API functions, like gui.enable_choice() and gui.show_module(),
to update the GUI.
Parsing of the configuration file, "CONFIG.txt", is handled
simply by sending the settings to the Lua code, via the two
functions mentioned above, and letting the Lua code update
the GUI buttons.