These were preventing b89731c7ac48 from being fully effective, since those calls resulted in the scroll label
scrolling top the top. However, it still doesn't fix this happening on initial show.
Plus a bunch of changes which were necessary for the script to work:
* The "simulate lobby activity" plugin now exits when the server is shut
down.
* The plugin now uses wesnoth.random() for random number generation.
Math.random() uses a fixed seed, which would make all the clients
perform the exact same actions.
* Exposed wesnoth.random() to plugins to allow the change above.
* --nogui no longer implies --wconsole on Windows. With implied --wconsole
the clients attached themselves to the standard output of the Python
script, which made it impossible to see the output of the script itself.
Previously, these would still get included in the final options config and result in a [type] id = tag being saved
in prefs with no [option] tags. When loaded in the constructor, this would pollute the options_data_ map, which would
then in turn pollute the resulting config further, ad infinitum.
Both are slightly wider than before. In the latter case, 750 would have matched the old automatic width, but
for some reason, the window's scrollbars were showing. Need to investigate further.
This fixes 797613f760
which changed the luaW_pcall code from.
if(lua_pcall(..)) {
...
lua_pop(L, 2);
return;
}
lua_remove(L, error_handler_index);
to
int r = lua_pcall(..);
lua_remove(L, error_handler_index);
if(r) {
...
lua_pop(L, 2);
return;
}
so that three values were removed from the stack in case of an error which caused random segfaults later.
This moves the tab update code to on_game_select from update_details, since the latter is called when
regenerating random maps and doing so has no possibility of changing tab contents. The only thing that
can do that is selecting a new game. If this ceases to be true in the future, this can be reverted.
This probably should have been done in 80115b11faa3 - in fact, the commit message makes it sound like
it was, but it was not due to an oversight on my part.
We should evaluate whether this should be done for all widgets. Right now, having them private makes a public get_state
rather useless, since it can't be stored or compared against anything.
Previously, on_tab_select was called every time update_details was called (including on game selection), as well as
when a tab was manually selected. I had enabled the updating of tab 3 (game settings) on every call to fix an issue
where game settings were incorrect if that tab had not been selected. However, it was recently discovered that the
same issue affected tab 2 (custom options). Since the only time the contents of the tabs change is when called from
update_details anyway (manually selecting a tab did not), it made sense to move the updating code out of on_tab_select.
This is also a performance optimization, since it prevents tabs' contents from being updated every single time a new
one was selected, when in reality there would be no change unless a game was changed. This will also prevent any future
issues of the same ilk and ensures the state of all widget is always in sync with the settings of the selected game.
