The UI can handle updates now. Interacting with it in significant ways, like pressing a button or moving a slider, triggers a function which sends the full state of that display group to LUA, which then has the option to adjust any individual element as it sees fit.
It has a few strengths: First, having LUA take no action is trivial: just pass back everything you got without touching it. Changing things is also pretty easy, in that you only have to touch what you want to change. For instance, if you want to make pressing a button called button1 set slider3 to 0, look for the table where table.name == button1, and check if that table.modified=true and table.state = 1 (which means the button is actively being pressed), and if so, go to the table where table.name==slider3, and for that table set table.curVal = 0, then pass back everything when you’re done.  I’ve tried to make it simple and logical from LUA’s point of view, at the expense of additional complication on the C++ side.
The greatest strength is that doing almost anything to the UI is possible in LUA. Â Adding elements, moving them around, changing their state, or removing the entire display group is possible without touching any C++, and is therefore all available to any mod author. Â Having this sort of flexibility of UI is highly beneficial to a game once a few users start publicizing their modifications, because it lets any user selectively change the UI to meet their tastes, which are bound to vary. Â Unlike most applications where conformity is key, games have few standard UI designs.