Initial plugin support #213
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merged
Defman
reviewed
May 7, 2020
| /// # Safety | ||
| /// This function may not be called from multiple threads | ||
| /// at once. | ||
| pub fn init_vtable(s: FStr) -> Result<(), serde_json::Error> { |
There was a problem hiding this comment.
Could we enforce this by having a static lock, for initialization?
There was a problem hiding this comment.
Cost will likely be significant, since this is hot code. This is an internal API, so there's not too much need for enforcing safety, as long as we're careful. For now, though, I can switch this to a safe implementation.
There was a problem hiding this comment.
If the function has safety implications for calling, wouldn't it be better to make it an unsafe fn rather than wrap that up with a note in the docs?
Defman
reviewed
May 7, 2020
| #[repr(C)] | ||
| pub struct SystemSpec { | ||
| /// A pointer to the function to run when the system is invoked. | ||
| pub f: fn(*mut GameState), |
There was a problem hiding this comment.
Can we change the name to something more descriptive than f, like run, invoke, or step?
Defman
reviewed
May 7, 2020
| /// | ||
| /// The function may assume the `OpaqueEvent` pointer | ||
| /// points to the event type associated with `event`. | ||
| pub f: fn(*mut GameState, *mut OpaqueEvent), |
There was a problem hiding this comment.
Better field name like, handle, act, run?
Defman
reviewed
May 7, 2020
caelunshun
added a commit
that referenced
this pull request
May 11, 2020
Implement survival mode This PR implements survival mode. Resolves #40. #213 is blocked on this as we are developing the design we will use to approach gamemodes, and moreover, how we will implement gameplay features with regard to component architecture. The current approach is heavily based on data-oriented design. Rather than checking a player's gamemode in systems, there are a number of marker components—e.g. CanBreak, CanInstaBreak, CanTakeDamage, CanFly—which describe the capabilities of a player. These are inserted based on gamemode on player join, but the architecture allows for extensive customization of functionality through plugins. Ideally, we would have a /gamemode command, but this is blocked on #209 being merged. I may merge it early, depending on how complete people deem it to be. Currently, the only way to affect a player's gamemode is through the default-gamemode setting in the config or manual editing of the player data files. # Inventory handling Only basic survival mode inventory handling (i.e. single clicks) has been implemented. I will hold off on the rest until our inventory indexing situation has improved. # Block breaking Survival mode digging has been implemented, for the most part. All which remains is to write down the harvest tools for all blocks (currently, only stone and dirt are in the list). This file is in definitions/data/tool.ron.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR will implement an initial design for
fapi, our plugin API, and the associated API bindings and plugin loader infeather-server.The current design is based on dynamic loading of shared libraries using a C-compatible FFI interface. The decision was made to hold off on the use of WebAssembly as the WASM ecosystem lacks the maturity we desire. For example, networking is still unimplemented in WASI (and has been for well over a year since the issue was filed...). Networking is a critical feature for plugins needing database interaction.
The current API can be ported to WASM with a bit of effort, should WASI implement the features we need.
Resolves #106, at least initially.
Checklist
plugin_initproc macro to mark a plugin's initialization function. (Question: this naming isn't ideal; ideally it would be calledplugin, but that's taken by the Rust compiler. Other ideas are welcome)fapito crates.io