HuskHomes

repository·master·Indexed 41 days ago

https://github.com/wiiiiam278/huskhomes

A flexible teleportation plugin for Minecraft: Java Edition servers (Spigot and Fabric). It supports cross-server teleportation via MySQL/MariaDB for BungeeCord or Velocity networks and provides a suite of player and admin commands for managing homes and warps, including /sethome, /home, /tpa, and /rtp.

Tokens
27.5K
Snippets
88
Records
138
Agent score
48%

What's inside HuskHomes

  1. Overview of HuskHomes features

    master

    HuskHomes is a teleportation plugin for Minecraft: Java Edition (Spigot or Fabric) that provides player teleportation features such as homes, warps, and teleport requests.

    Key capabilities include:

    • Cross-server support: Using MySQL/MariaDB, players can set homes and teleport across a proxy network (BungeeCord or Velocity).
    • Built-in commands: Familiar commands like /sethome, /home, /tpa, and /rtp are available out of the box.
    • Interactive chat menus: Uses robust chat-based menus instead of traditional chest GUIs.
    • Admin tools: Includes /tp and /warp along with management tools for player homes.
    • Plugin hooks: Integrates with Plan for analytics and Dynmap/BlueMap for displaying homes on web maps.
    • Extensibility: Provides an API for developers to extend functionality.
  2. HuskHomes Features and Functionality

    master

    HuskHomes provides a wide range of home and warp management features, including:

    • Command Management: Core commands for users and admins.
    • Hooks: Support for Plan, Map, and Economy hooks.
    • Security: Strict TP-after-teleport (Tpahere) and Restricted Warps.
    • User Experience: Back command, Cooldowns, Global Spawn, and Global Respawning.
  3. Explore HuskHomes Features

    master

    HuskHomes provides a comprehensive suite of teleportation and management tools. Key features include:

    • Commands: A full set of commands for managing homes, warps, and teleports.
    • Hooks: Integration with Plan, Map, and Economy plugins.
    • Teleportation Controls: Features like Strict Tpahere, Back Command, Cooldowns, and Global Respawning.
    • World Management: Global Spawn and Restricted Warps to control player movement across different worlds.
  4. Understand the difference between Warps and Public Homes

    master

    HuskHomes provides two distinct ways to manage locations: Warps and Public Homes. Use the following comparison to decide which to implement:

    Warps

    • Ownership: No one owns a warp; it is a server-wide object.
    • Management: Intended for admins. By default, only admins can create them.
    • Limits: There is no limit to the number of warps that can be created.
    • Access: Accessed via /warp.
    • Naming: Warp names must be unique globally across the entire server network.

    Public Homes

    • Ownership: Owned by a specific player.
    • Management: They are regular player homes that have been made public. Only the owner (or an admin) can edit or delete them.
    • Limits: They count towards the player's total home slot limit. You can limit the number of public homes a player can have via permissions or configuration.
    • Access: Accessed via /phome, or via /home by the owner.
    • Naming: Names must be unique per-player. If names are not unique, they can be accessed using the syntax /phome <OWNER_USERNAME> <HOME_NAME>.
  5. Configure home limits via permission nodes

    master

    You can override the default home limits set in the plugin configuration by using specific permission nodes. If a user has multiple nodes, HuskHomes uses the highest value.

    To make these limits stack instead of taking the highest value, set stack_permission_limits: true under the general section in the plugin config.

    Available Nodes:

    • huskhomes.max_homes.<amount>: Sets the maximum total number of homes a user can have.
    • huskhomes.free_homes.<amount>: Sets the number of homes a user can set for free before economy checks apply (requires an economy hook).
    • huskhomes.max_public_homes.<amount>: Sets the maximum number of homes a user can set to public.
    # Example permission nodes:
    huskhomes.max_homes.10
    huskhomes.free_homes.3
    huskhomes.max_public_homes.2
  6. How global respawning works

    master

    When global_respawning is enabled, HuskHomes manages player spawn points across the network using the following lifecycle:

    1. Setting the Spawn: When a player interacts with a bed or respawn anchor, HuskHomes updates that player's global respawn position to match the coordinates on the current server.
    2. Player Death: Upon death, the player is sent to the specific server where their global spawn was last set using a special RESPAWN teleport type.
    3. Arrival: Once the player arrives at the target respawn server, the game completes the teleport to the stored position.

    Note on Failures: If the stored respawn position is missing or obstructed on the target server, the player will be moved to that server's default world spawn instead.

  7. Use fallback namespaces to access HuskHomes commands

    master

    All HuskHomes commands are registered with a fallback namespace. If a command is being intercepted by another plugin (like EssentialsX), you can bypass the conflict by prefixing the command with huskhomes:.

    For example, instead of using /home, you can use /huskhomes:home to ensure the HuskHomes version of the command is executed.

  8. Handle asynchronous API calls with CompletableFuture

    master

    Many HuskHomesAPI methods return CompletableFuture objects to prevent database queries from blocking the main server thread. Use #thenAccept() to process the result once the future completes.

    Warning: Never call #join() on futures returned by the HuskHomesAPI. Since these are processed on asynchronous server tasks, calling #join() can lead to thread deadlocks and crash your server.

  9. Configure Cross-Server RTP

    master

    To enable Cross-Server Random Teleport (RTP), ensure the following three conditions are met:

    1. Set rtp.cross-server to true in the configuration.
    2. Use Redis as your messenger_type.
    3. Ensure the server names listed in rtp.random_target_servers exactly match the names defined in your server.yml and your Proxy configuration.
  10. Choose a database type for HuskHomes

    master

    HuskHomes supports several database types depending on whether you need local storage or cross-server synchronization.

    Warning: There is no automatic migration between database types. Changing the type in your configuration will result in data loss.

    TypeStorageDescriptionCross-server Support
    SQLITEFileDefault and recommended for single-server setups.❌
    H2FileFile-based, similar to SQLITE but with slightly faster query times.❌
    MYSQLServerHosted on a MySQL server.✅
    MARIADBServerHosted on a MariaDB server.✅
    POSTGRESQLServerHosted on a PostgreSQL server.✅
  11. HuskHomes Developer API and Events

    master

    Developers can extend HuskHomes using its public API. The documentation provides specific guidance on:

    • API Usage: How to interact with the plugin's core logic.
    • API Examples: Concrete code snippets for common tasks.
    • API Events: A list of events that developers can listen to for custom logic.
  12. Setup HuskHomes API with Maven

    master

    To use the HuskHomes API in a Maven project, add the william278.net repository and the platform-specific dependency to your pom.xml.

    Note: Replace VERSION with the latest HuskHomes version (e.g., 4.11). For Fabric platforms, you must append the Minecraft version to the version string (e.g., 4.11+1.20.1).

    Use the provided scope as the API is expected to be present at runtime via the HuskHomes plugin.

    <repositories>
        <repository>
            <id>william278.net</id>
            <url>https://repo.william278.net/releases</url>
        </repository>
    </repositories>
    
    <dependency>
        <groupId>net.william278.huskhomes</groupId>
        <artifactId>huskhomes-PLATFORM</artifactId>
        <version>VERSION</version>
        <scope>provided</scope>
    </dependency>