Assorted fixes

.github/FUNDING.yml

@@ -10,6 +10,6 @@ liberapay: # Replace with a single Liberapay username
 issuehunt: # Replace with a single IssueHunt username
 lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
 polar: # Replace with a single Polar username
-buy_me_a_coffee: # ferrumc
+buy_me_a_coffee: tempermc
 thanks_dev: # Replace with a single thanks.dev username
 custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -4,7 +4,7 @@ labels: [ bug, unconfirmed ]
 body:
   - type: markdown
     attributes:
-      value: Bug reports should only be used for reporting issues with how the server works / its features. For general questions, please use our [Discord Server](https://discord.gg/qT5J8EMjwk) instead.
+      value: Bug reports should only be used for reporting issues with how the server works / its features. For general questions, please use our [Discord Server](https://discord.gg/6QPZgUy4sA) instead.
 
   - type: textarea
     attributes:

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -4,44 +4,23 @@ labels: enhancement
 body:
   - type: markdown
     attributes:
-      value: This should only be used for new ideas / features. For general questions, please use our [Discord Server](https://discord.gg/qT5J8EMjwk) instead.
+      value: This should only be used for new ideas / features. For general questions, please use our [Discord Server](https://discord.gg/6QPZgUy4sA) instead.
 
   - type: textarea
     attributes:
-      label: Is your feature request related to a problem?
-      description: "A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Link the GitHub issue if applicable."
+      label: Description of the feature
+      description: "Please provide a clear and concise description of the feature you are requesting. Include any relevant details or use cases that can help us understand the value and purpose of this feature."
     validations:
       required: true
 
-  - type: textarea
-    attributes:
-      label: "Describe the solution / feature you'd like."
-      description: "A clear and concise description of what feature / solution you would like to be implemented."
-    validations:
-      required: true
-
-  - type: textarea
-    attributes:
-      label: "Alternatives you've considered."
-      description: "A clear and concise description of any alternative solutions / features you've considered."
-    validations:
-      required: true
-
-  - type: textarea
-    attributes:
-      label: "Additional Context"
-      description: "Add any other context or screenshots about the feature request here."
-    validations:
-      required: false
-
   - type: checkboxes
     attributes:
-      label: I have confimed that...
+      label: I have confirmed that...
       options:
         - label: ... such a feature does not exist already.
-          required: true
+          required: false
         - label: ... I ticked all the boxes without reading them
           required: false
         - label: ... such a feature request has not been submitted already.
-          required: true
+          required: false
 

.github/workflows/rust.yml

@@ -12,31 +12,41 @@ concurrency:
 
 env:
   CARGO_TERM_COLOR: always
+
 defaults:
   run:
     shell: bash
+
 jobs:
   formatting_and_security:
     name: Formatting and Security
+    if: github.event_name != 'pull_request' || !github.event.pull_request.draft
     runs-on: ubuntu-latest
     steps:
       - name: Checkout repository
         uses: actions/checkout@v5
+
       - name: Install Rust stable
         uses: dtolnay/rust-toolchain@stable
         with:
           components: rustfmt, clippy
+
       - uses: Swatinem/rust-cache@v2
+
       - name: Run cargo fmt
         run: cargo fmt --all -- --check
+
       - name: Run Clippy
         run: cargo clippy --all-targets -- -D warnings
+
       - name: Install cargo-audit
         uses: taiki-e/install-action@v2
         with:
           tool: cargo-audit
+
       - name: Run Cargo Audit
         run: cargo audit --ignore RUSTSEC-2023-0071
+
   build:
     name: Build and Upload Artifacts
     if: github.ref == 'refs/heads/master'
@@ -88,14 +98,18 @@ jobs:
     steps:
       - name: Checkout repository
         uses: actions/checkout@v5
+
       - name: Install Rust stable
         uses: dtolnay/rust-toolchain@stable
         with:
           targets: ${{ matrix.target }}
+
       - uses: Swatinem/rust-cache@v2
+
       - name: Install cargo-nextest
         uses: taiki-e/install-action@v2
         with:
           tool: cargo-nextest
+
       - name: Run Tests
-        run: cargo nextest run --target ${{ matrix.target }} --all-targets --all-features -E "not kind(bench)"
+        run: cargo nextest run --target ${{ matrix.target }} --all-targets --all-features -E "not kind(bench)"

CODE_OF_CONDUCT.md

@@ -1,4 +1,3 @@
-
 # Contributor Covenant Code of Conduct
 
 ## Our Pledge
@@ -29,7 +28,7 @@ Examples of unacceptable behavior by participants include:
 * Public or private harassment
 * Publishing others' private information, such as a physical or electronic
   address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
+* Other conduct that could reasonably be considered inappropriate in a
   professional setting
 
 ## Our Responsibilities
@@ -40,8 +39,8 @@ response to any instances of unacceptable behavior.
 
 Project maintainers have the right and responsibility to remove, edit, or
 reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
+that are not aligned to this Code of Conduct, or to temporarily or
+permanently ban any contributor for other behaviors that they deem inappropriate,
 threatening, offensive, or harmful.
 
 ## Scope

CONTRIBUTING.md

@@ -8,122 +8,58 @@ Keep in mind that clippy, rustfmt and cargo-audit are enforced on CI, so make su
 
 1. Make sure all tests and lints pass. PRs that don't pass CI will be rejected if your code is the cause of the failing
    tests/lints.
-2. Make sure all needed files are also included and not using absolute paths.
+2. Make sure all necessary files are also included and not using absolute paths.
 3. Include a sufficient explanation of your PR. What is it adding/fixing, why does this feature need to be added/fixed,
    who have you discussed this with, etc. If these questions were answered in a conversation on this Discord, mention
    who you talked with and what consensus was reached. Unexplained PRs will rarely be accepted.
 4. Check again that tests pass.
-5. Check a 3rd time.
-6. Check that Clippy passes with no issues. `cargo clippy --all-targets -- -Dwarnings` is used on CI.
-7. Check that Rustfmt passes with no issues. `cargo fmt --all -- --check` is used on CI.
-8. Check that Cargo-audit passes with no issues. `cargo audit` is used on CI.
-9. Submit PR.
+5. Check that Clippy passes with no issues. `cargo clippy --all-targets -- -Dwarnings` is used on CI.
+6. Check that Rustfmt passes with no issues. `cargo fmt --all -- --check` is used on CI.
+7. Check that Cargo-audit passes with no issues. `cargo audit` is used on CI.
+8. Submit PR.
 
-## Project specific guidelines
-
-Just some rules to try to keep the repo nice and organised
-
-### Branches
-
-#### `master`
-
-This branch is the main branch. This is where all PRs should be made to. This branch is the most up to
-date and should only be merged into with completed features.
-
-#### `feature/feature-name`
-
-This branch is for developing a feature. Once the feature is complete, a PR should be
-made to the master branch. This branch should be branched off of the master branch.
-
-#### `fix/fixed-thing`
-
-This branch is for fixing a bug. Once the bug is fixed, a PR should be made to the master
-branch. This branch should be branched off of the master branch.
-
-#### `rework/refactored-thing`
-
-This branch is for refactoring code. Once the code is refactored, a PR should be made to the master branch.
-
-#### `housekeeping`
-
-This branch is for stuff relating to the repo itself. This could be updating the README, adding
-new CI checks, etc. This branch should be branched off of the master branch.
-
-#### `docs`
-
-This branch is for updating the documentation. This branch should be branched off of the master branch.
-This is used for stuff that doesn't actually modify the code, but the documentation.
-
-### Project Layout
-
-```text
-+---.etc                    | Non-code files
-+---.github                 | GitHub specific files
-+---assets                  | Assets for the Readme
-+---scripts                 | Scripts for the project, usually python or bash
-+---src                     | Source code
-|   +---bin                 | The main binary that stitches everything together
-|   +---lib                 | The libraries that provide the business logic
-|   |   +---adapters        | Adapters and parsers for data formats
-|   |   +---core            | The core logic of the application
-|   |   +---derive_macros   | Derive macros. Split into directories for each macro
-|   |   +---ecs             | The ECS system
-|   |   +---events          | The event system
-|   |   +---net             | Networking code
-|   |   +---plugins         | Plugins interface
-|   |   +---storage         | Storage backend
-|   |   +---utils           | Utility functions
-|   |   \---world           | Code for interacting with the world
-|   \---tests               | Unit tests
-```
-
-If you add a new directory, please add it to the above list along with its purpose.
+> [!NOTE]
+> There is a template you will be prompted to fill out when you create a PR. This is not a hard requirement, but is a
+> good starting point for making sure you include all the necessary information in your PR.
 
 ### Code rules
 
 1. Tests that only generate/dump data must be `#[ignore]`d. These tests are not useful for CI and should not be run.
 2. No absolute paths. This will break the CI and make it harder to run the code on different machines.
-3. Try to avoid just chaining `../` to get to the root of the project. This makes it harder to move files around and
-   work
-   out where a referenced file is. There is a `get_root_path()` function that can be used to get the root of the project
-   as a
-   PathBuf.
-4. Don't be lazy and use `unwrap()`. If you are sure that a value will always be `Some`, use `expect()`. If you are not
-   sure, use `match` or `if let`. Please also have a more detailed `error!()` message if you are using `expect()`.
-5. Avoid `.clone()`ing data. If you need to clone data, make sure that it is necessary and that the data is not too
-   large.
-   Cloning is ok however in sections of code that only need to run once and small performance hits are acceptable (eg,
-   loading config files, starting up the database).
-6. New dependencies should be added to the workspace `Cargo.toml` file. This will make it easier to manage dependencies
-   and will make sure that all dependencies are of the same version.
-7. If you are adding a new feature that warrants major separation, add it as a new crate and then include it in the
+3. Try not to use `unwrap()`, do proper error handling. If at all possible, try to use `expect()` in place of `unwrap()`
+   so that if the code does panic, it will be easier to find the source of the panic. If you are sure that the code will
+   never panic, you can use `unwrap()`, but it is generally better to use `expect()` with a message explaining why the
+   code will never panic.
+4. New dependencies should be added to the workspace `Cargo.toml` file. This will make it easier to manage dependencies
+   and will make sure that all dependencies are of the same version, preventing dependencies being compiled multiple
+   times due to version mismatches.
+5. If you are adding a new feature that warrants major separation, add it as a new crate and then include it in the
    workspace `Cargo.toml` file. This will make it easier to manage the code and will make sure that the code is well
    separated.
-8. If you are adding an extra sub-crate, you must create a new set of `thiserror` based error types for that crate. This
-   will make it easier to understand where an error is coming from and will make it easier to handle errors.
-9. Use `cargo clippy` to check for any issues with the code. This will be checked in CI and will cause the build to fail
+6. Use `cargo clippy` to check for any issues with the code. This will be checked in CI and will cause the build to fail
    if there are any issues. There is no excuse for *your* code to fail the lints.
-10. Use `cargo fmt` to format the code. This will be checked in CI and will cause the build to fail if the code is not
-    formatted correctly. There is no excuse for *your* code to fail the formatting.
-11. Use `#[expect(lint)]` instead of `#[allow(lint)]` if you are sure that the lint is not an issue. This will make it
-    easier to find and remove these lints in the future.
-12. Use `#[cfg(test)]` to only include code in tests. This will make the code easier to read and understand.
-13. Where applicable, add doc strings to functions and modules. This will make it easier for others to understand the
+7. Use `cargo fmt` to format the code. This will be checked in CI and will cause the build to fail if the code is not
+   formatted correctly. There is no excuse for *your* code to fail the formatting.
+8. Use `#[expect(lint)]` instead of `#[allow(lint)]` if you are sure that the lint is not an issue. This will make it
+   easier to find and remove these lints in the future.
+9. Use `#[cfg(test)]` to only include code in tests. This will make the code easier to read and understand.
+10. Where applicable, add doc strings to functions and modules. This will make it easier for others to understand the
     code.
     Check https://doc.rust-lang.org/nightly/rustdoc/how-to-write-documentation.html for more information on how to write
     good documentation.
-14. Unsafe code is ok as long as it is well documented and the reason for the unsafe code is explained. If you are not
+11. Unsafe code is ok as long as it is well-documented, and the reason for the unsafe code is explained. If you are not
     sure if the code is safe, ask in the Discord.
-15. Limit the use of raw instructions as much as possible. This will make the code easier to read and understand. There
-    are some cases where raw instructions are needed, but these should be kept to a minimum.
-16. You will be asked to fix your PR if folders like `.vscode` or `.idea` are included in the PR. These folders are
+12. You will be asked to fix your PR if folders like `.vscode` or `.idea` are included in the PR. These folders are
     specific to your IDE and should not be included in the PR.
-17. If you are adding a new feature, make sure to add tests for it. This will make sure that the feature works as
+13. If you are adding a new feature, make sure to add tests for it. This will make sure that the feature works as
     expected and will help prevent regressions in the future.
-18. If you are fixing a bug, make sure to add a test that reproduces the bug. This will make sure that the bug is fixed
+14. If you are fixing a bug, make sure to add a test that reproduces the bug. This will make sure that the bug is fixed
     and will help prevent regressions in the future.
-19. If your code isn't sufficiently documented, you will be asked to add documentation.
-20. If your code doesn't have tests where it should, you will be asked to add tests.
+15. If your code isn't sufficiently documented, you will be asked to add documentation.
+16. If your code doesn't have tests where it should, you will be asked to add tests.
+17. Please don't submit massive PRs with 80k changed lines, you will be asked to split these into smaller PRs. It's an
+    absolute nightmare to review and verify massive PRs, so please try to keep your PRs small and focused on a single
+    feature or bug fix.
 
 ## Notes on formatting
 
@@ -142,8 +78,7 @@ performance hit.
 Automatic formatting is highly recommended as it will ensure that the code you write is correctly formatted as you go,
 instead of running `cargo clippy` when you are done and having 400 clippy errors to fix at once. You should still run
 the clippy and fmt commands before submitting a PR to make sure that the code is correctly formatted and passes the
-lints,
-but automatic formatting will help to catch most of these issues as you go.
+lints. However, automatic formatting will help to catch most of these issues as you go.
 
 ## Code of Conduct
 

Cargo.toml

@@ -30,13 +30,12 @@ members = [
     "src/entities",
     "src/game_systems",
     "src/game_systems/src/background",
-    "src/game_systems/src/mobs",
     "src/game_systems/src/interactions",
+    "src/game_systems/src/mobs",
     "src/game_systems/src/packets",
     "src/game_systems/src/physics",
     "src/game_systems/src/player",
     "src/game_systems/src/world",
-    "src/world/block-placing",
     "src/inventories",
     "src/messages",
     "src/net/codec",
@@ -54,6 +53,7 @@ members = [
     "src/text",
     "src/utils",
     "src/world",
+    "src/world/block-placing",
     "src/world/db",
     "src/world/format",
     "src/world/gen",
@@ -165,7 +165,7 @@ tokio = { version = "1.50.0", features = [
 
 # Logging
 tracing = "0.1.44"
-tracing-subscriber = { version = "0.3.22", features = ["env-filter"] }
+tracing-subscriber = { version = "0.3.23", features = ["env-filter"] }
 tracing-appender = "0.2.4"
 tracing-tracy = { version = "0.11.4", features = ["timer-fallback", "ondemand", "fibers", "context-switch-tracing", "delayed-init"] }
 log = "0.4.29"
@@ -239,7 +239,7 @@ yazi = "0.2.1"
 flate2 = "1.1.9"
 
 # Database
-heed = "0.22.1-nested-rtxns-6"
+heed = "0.22.1-nested-rtxns-7"
 
 # Misc
 deepsize = "0.2.0"
@@ -252,7 +252,7 @@ num_cpus = "1.17.0"
 typename = "0.1.2"
 bevy_ecs = { version = "0.18.1", features = ["multi_threaded", "trace", "debug"], default-features = false }
 bevy_math = "0.18.1"
-once_cell = "1.21.3"
+once_cell = "1.21.4"
 mime_guess = "2.0.5"
 
 ## TUI/CLI
@@ -261,15 +261,15 @@ ratatui-core = "0.1.0"
 tui-input = "0.15.0"
 ratatui = "0.30.0"
 tui-logger = { version = "0.18.1", features = ["tracing-support", "crossterm"] }
-clap = { version = "4.5.60", features = ["derive", "env"] }
+clap = { version = "4.6.0", features = ["derive", "env"] }
 indicatif = "0.18.4"
 colored = "3.1.1"
 unicode-width = "0.2.2"
 heck = "0.5.0"
 
 # I/O
 memmap2 = "0.9.10"
-tempfile = "3.26.0"
+tempfile = "3.27.0"
 walkdir = "2.5.0"
 include_dir = "0.7.4"
 
@@ -283,8 +283,9 @@ phf_codegen = { version = "0.13.1" }
 axum = { version = "0.8.8", features = ["tokio", "ws"] }
 
 # Stats
-sysinfo = { version = "0.38.3", default-features = false, features = ["system"] }
+sysinfo = { version = "0.38.4", default-features = false, features = ["system"] }
 dir-size = "0.1.1"
 
+# Compression is a real bottleneck that we can do little about, so compiling it with optimizations is needed in dev mode.
 [profile.dev.package.yazi]
 opt-level = 3