"Are you trying to display some data that a separate script is generating in a widget?" Yes, exactly.
Tried script_environment on a dummy script (also tried reqscript now; same result) and dwarfmoniter alike, adding/editing variables in during runtime, didn't work even with disable-enable or by editing variables from console before enabling dwarfmonitor for first time in current process. It looks like the environment dwarfmonitor generates and the environment console generates are different. (Adding something to BASE_G obviously failed too; wildly speculating might be that they're on separate C lua states).
They are! Yeah, that might cause some issues. That's almost certainly why dfhack.timeout and persistent storage aren't available, as you mentioned - widgets haven't needed those, and running Lua code from DF's render() as the widgets do can sometimes break in weird ways, which I think is why I isolated it by using a separate Lua state.
I feel like reqscript and script_environment ought to work, but I could be wrong (and can't say I've tested it). One thing that trips people up: those only give you access to the global state from the last time the script was run, so calling them more than once
won't re-run the script in question (only running the script from the console will do that). But if you're already aware of that, and aren't seeing things populated on the dwarfmonitor side after running the script and accessing its environment again, then it probably is related to the separate Lua state as you suggested.
Now that I think about it, passing data between Lua states might not be easy without going through C++, since they have separate Lua stacks and may be getting accessed from different threads.
Author
Topic: DFHack 50.14-r1.1 (Read 889113 times)