-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow passing arbitrary data to mapgen Lua env (also at runtime) #14451
Comments
I initially wanted to design something one-way that is specific to mapgen threads but I guess there's no way around just adding a general IPC mechanism. Here's my proposal:
As for the implementation the Edit: Locking primitives intentionally don't exist here because most of MT's threads are not supposed to be blocked at random points. I can see myself adding CAS however if it turns out to be useful. |
To prevent API users from doing the wrong thing in the first place, wouldn't an API like What use cases do you have in mind other than the one described in this issue? |
I considered that but thought that the usability/readability improvement from a metatable is better.
It works very well to transfer global data into async or mapgen env (like configuration). |
I think the metatable-based API, while providing nice syntactic sugar, is not worth the footguns it brings. Modders can usually expect tables to behave reasonably, with pretty much the only exception being This "table" however is special: Some values can't go in it. Subtables can't go in it. I don't think it's good to create the illusion that this is anything like a table. Too many footguns in that direction; it's better to be explicit here. If experienced modders think they want the syntactic sugar, it's easy enough to implement in < 10 lines of Lua. As a "compromise" solution, having something like a global |
FWIW we no longer support PUC Lua so this would actually not be a problem.
Well that's not so different from
I planned to not support iterating the global IPC data table. Mods should know what they set. |
Problem
Mods with custom mapgens may want to generate terrain differently in response to game events. This use case is not currently handled by the asynchronous mapgen API, as there is no way to pass information into the isolated mapgen environment.
Solutions
The idea is that the main environment should be able to write data at any time into some sort of shared storage, which the mapgen thread would be able to retrieve whenever a new area is generated. Ideally, this would only be writeable by the main environment, so locking could be performed optimally in the form of a read-write lock.
Alternatives
As @sfan5 suggested, a workaround that currently works is passing temporary files across environments. I have tested this to good results.
Additional context
#14450
The text was updated successfully, but these errors were encountered: