Skip to content
This repository has been archived by the owner on Jun 28, 2021. It is now read-only.

Config_Flow.txt

Sterling Parker edited this page Oct 23, 2019 · 1 revision

For historical purposes only. Do not edit.

Permalink: https://github.com/caligari87/Oblige/blob/e3dbc44e1649e40a65df8da0cc65d13be592fa03/notes/Config_Flow.txt

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.
Clone this wiki locally