· Tutorials  · 11 min read

Install Distant Horizons on Your Minecraft Server: Bukkit, Spigot, Paper, Folia Guide

Want to bring stunning, far-reaching views to your Minecraft server? This guide makes installing the Distant Horizons server plugin a breeze for Bukkit, Spigot, Paper, and Folia servers.

Want to bring stunning, far-reaching views to your Minecraft server? This guide makes installing the Distant Horizons server plugin a breeze for Bukkit, Spigot, Paper, and Folia servers.

Hey Minecraft server adventurers! Many of your players might be using or want to use the Distant Horizons mod client-side for breathtaking, long-distance views. To ensure the best and most consistent experience for these players on your server, the Distant Horizons Server Plugin is essential. This guide focuses on getting the Distant Horizons server plugin installed and optimized on your Bukkit, Spigot, Paper, or Folia server, enhancing long-distance views for your players.

(If you’re also interested in setting up a cost-effective Minecraft server, you might want to check out my guide on creating a Free and Fantastic: My Zero-Cost Oracle Cloud Minecraft Server with Docker.) I’m happy to report that the Distant Horizons server plugin runs wonderfully on that very setup!

The Role of the Client Mod (Briefly)

The Distant Horizons client mod allows players to see simplified terrain far beyond Minecraft’s standard view distance, improving performance and visual immersion. Players install this on their own game.

Our focus here is the server plugin. This plugin works in tandem with the client mod, providing the necessary data from your server to ensure that players using the mod have a synchronized and enhanced visual experience. We’ll delve into the specifics of what the server plugin does and why it’s beneficial in the next section.

Important Considerations Before You Start!

Before we dive in, here are a few crucial points from the Distant Horizons team:

  • Strict Version Support: The version numbers for the mod (and by extension, compatibility with the server plugin) are strict! If a version says it supports MC 1.18.1, it will NOT work on 1.18.2. Always ensure your mod and server plugin versions are compatible with your Minecraft version.
  • Alpha Software: The mod (and potentially the server plugin) is still in alpha. This means things may change, break, crash, or otherwise go wrong. You have been warned!
  • Found an Issue? If you encounter problems, it’s best to leave an issue on the project’s GitLab page.

What You Need to Know First (Server Plugin Specifics)

  • What it does: The Distant Horizons Server Plugin (DH Support) transmits LOD data to players using the Distant Horizons mod.
  • Why use it: Ensures clients load distant chunks correctly and receive updates for those chunks when they change.
  • Compatibility: Works with Bukkit, Spigot, Paper, and Folia server types.

Installation: It’s Seriously Easy!

One of the best things about this plugin is how easy it is to install on your Bukkit, Spigot, Paper, or Folia server.

  1. Download the Plugin:

    • Head over to the official Distant Horizons Server Plugin releases page: https://gitlab.com/distant-horizons-team/distant-horizons-server-plugin/-/releases
    • Find the latest release. You’ll notice the download link often leads to a Google Drive folder.
    • In that Google Drive folder, you’ll find different JAR files for various Minecraft versions. Download the JAR file that matches your server’s Minecraft version.
  2. Drop it in Your Plugins Folder:

    • Once downloaded, take that .jar file and place it directly into the plugins folder of your Minecraft server.
    • If your server is running, you’ll need to restart it (or use a plugin manager to load it, if you have one).

And that’s it! You’ve successfully installed the Distant Horizons Server Plugin. Your players using the client mod will now benefit from server-synchronized Level of Detail (LOD) data, ensuring those breathtaking distant views are consistent and up-to-date.

Tip: Adjust Server view-distance for Performance

When using the Distant Horizons server plugin, consider adjusting your main server view-distance in the server.properties file. I recommend lowering this to around 10 chunks. Since Distant Horizons handles the far-off views with its LOD system, a lower server view-distance can reduce server load without sacrificing the expansive vistas your players will experience. Always test to find what works best for your server.

Frequently Asked Questions (FAQ)

Here are some common questions server administrators have about the Distant Horizons plugin and its impact on Minecraft servers:

  • Q: Does the plugin use multiple threads for LOD generation?
    • A: Yes, the Distant Horizons server plugin performs LOD generation on separate threads to minimize impact on the main server thread. You can configure the number of threads using the scheduler_threads setting in the config.yml file, which we cover in the “Configuration” section.
  • Q: Can I control the maximum LOD distance visible to players?
    • A: Yes, you can control the maximum render distance for Distant Horizons. This is managed via the render_distance setting in the config.yml file, detailed in our “Configuration” section.
  • Q: Can I control how detailed the generated LODs are?
    • A: Yes, the level of detail in the generated LODs can be adjusted. Settings like builder_type and builder_resolution in the config.yml file allow you to balance detail with performance. We discuss these in the “Configuration” section.
  • Q: Does Distant Horizons (with the server plugin) work with player-created structures?
    • A: Yes, the plugin is designed to include player-created structures when generating LODs. The overall LOD generation process, governed by settings such as distant_generation_enabled and the chosen builder_type (which are detailed in our “Configuration” section), will naturally incorporate these structures into the distant views.

Configuration (Optional)

The developers have set up the default configuration to work well for most servers. However, if you’re the type who likes to tinker or have specific needs, you can adjust the settings.

All the configuration options are found in the config.yml file, located in the plugins/DHSupport/ directory. This directory and the config.yml file will be automatically generated by the plugin the first time you run your server with the plugin installed. The comments within config.yml are very helpful and should guide you through what each option does.

Let’s look at some of the key settings you might want to adjust:

Understanding the config.yml

Here are some of the notable options you’ll find in your config.yml:

General Settings

  • render_distance

    • Default: 1024
    • My Recommended Value: 128. I find this value provides a good balance between enhanced visuals and server performance.
    • What it does: Sets the maximum supported render distance for Distant Horizons. Clients using the mod will be capped to this value.
  • distant_generation_enabled

    • Default: true
    • What it does: Enables or disables all LOD (Level of Detail) features. You’d typically keep this true unless you’re using the plugin only for level key info in a proxied server setup.
  • real_time_updates_enabled

    • Default: true
    • What it does: Determines if LOD updates for changed blocks are sent to players in real-time. Keeping this true ensures players see changes in distant terrain as they happen.
  • real_time_update_radius

    • Default: 128
    • What it does: Defines how close (in blocks) players need to be to an updated area to receive the real-time LOD update.
  • login_data_sync_enabled

    • Default: true
    • What it does: Allows clients to request updates to LODs they’ve previously downloaded when they log in. This helps keep their distant views consistent.
  • login_data_sync_radius

    • Default: 128
    • What it does: Sets how far away a player can request LOD updates for during the login sync process.

Performance and Quality Tuning

  • full_data_request_concurrency_limit

    • Default: 20
    • What it does: The number of parallel LOD requests that can be processed per client. Higher values might offer faster initial LOD loading for clients but could increase server load.
  • builder_type

    • Default: FullBuilder
    • My Recommended Value: FastOverworldBuilder. I use this for my overworld because it’s optimized for speed and generally provides excellent results for typical landscapes.
    • What it does: Selects the LOD builder: FullBuilder (more detailed, slower), FastOverworldBuilder (optimized for overworlds, faster), or None (disables LOD building).
  • builder_resolution

    • Default: 2
    • My Recommended Value: 4. I set this to 4 because sampling every fourth block on the Y-axis significantly improves performance. While it might slightly reduce vertical detail in the LODs, the performance gain is often worth it.
    • What it does: The number of blocks to advance between each sample on the Y-axis when generating LODs (e.g., 1 for every block, 2 for every other).
  • scheduler_threads

    • Default: 2
    • What it does: The number of worker threads used to generate LODs. This does not affect Folia servers. Adjusting this might help balance LOD generation performance with overall server CPU usage.
  • generate_new_chunks

    • Default: true
    • My Recommended Value: false (by uncommenting #generate_new_chunks: false and setting it to false). I recommend false to prevent the plugin from generating new terrain solely for creating LODs, which helps save server resources.
    • What it does: If enabled, the plugin will generate new chunks if needed to build LODs. If disabled, LODs can only be created for areas where chunks already exist. Disabling this can save resources if you don’t want new terrain generated solely for LOD purposes.

World-Specific Settings

The worlds section in your config.yml is powerful, allowing you to override any of the global settings on a per-world basis. This is incredibly useful for tailoring performance and visuals to different dimensions (like the Overworld, Nether, or The End) or even custom worlds if you have them.

To define settings for a specific world, you create a subsection under worlds: with the exact name of your world’s folder. For example, if your main Overworld folder is named world and your Nether folder is world_nether, your configuration would look something like this:

worlds:
  world: # Settings for your main Overworld
    builder_type: FastOverworldBuilder
    # scan_to_sea_level: true
    # border_center_x: 0
    # border_center_z: 0
    # border_radius: 5000
  world_nether: # Settings for the Nether
    render_distance: 64
    # perform_underglow_hack: true
    # builder_resolution: 1
  # world_the_end: # Example for The End
  # render_distance: 128 # You might want a different render distance for The End
  # builder_type: FullBuilder # Perhaps more detail is fine here

Let’s break down some common settings you might override per world, using my setup as an example:

  • builder_type (Per-World)

    • What it does: Overrides the global builder_type for this specific world.
    • My Approach: For my main world (Overworld), I ensure this is set to FastOverworldBuilder for optimal performance on typical landscapes. You might choose FullBuilder for a dimension where detail is paramount and performance impact is less critical, or None if you don’t want LODs for a particular world.
  • render_distance (Per-World)

    • What it does: Overrides the global render_distance for this specific world.
    • My Approach: For world_nether, I reduce the render_distance to 64. This is a common and effective optimization because the Nether’s enclosed spaces, fog, and generally chaotic terrain naturally limit long-distance visibility. A lower value here significantly helps with performance in the Nether.
  • builder_resolution (Per-World)

    • What it does: Overrides the global builder_resolution for this specific world.
    • My Approach: While I use a global builder_resolution of 4 for performance, for world_nether, the example in the default config often shows # builder_resolution: 1. If Nether LODs appear too blocky or lack detail with a higher global resolution, you might consider setting builder_resolution: 1 specifically for the Nether to capture more vertical detail, at the cost of some performance for Nether LOD generation.
  • scan_to_sea_level

    • Default: false (usually commented out)
    • What it does: When enabled (true), this option can be useful for worlds with significant floating islands or large overhangs above sea level, potentially improving how LODs are generated for such structures.
    • My Approach: I keep this commented out (false) for my standard Overworld and Nether as it’s not typically needed. Enable it if you have unique world generation where this might be beneficial.
  • border_center_x, border_center_z, border_radius

    • Default: Not set (usually commented out)
    • What it does: These settings allow you to define a circular area within which LODs will be generated. border_center_x and border_center_z define the center coordinates, and border_radius defines the radius in blocks.
    • My Approach: I don’t typically use this, but it can be very useful if you have a world border and only want to generate LODs within that specific gameplay area, saving resources.
  • perform_underglow_hack (Primarily for Nether)

    • Default: false (usually commented out)
    • What it does: This is a specific hack intended to improve the appearance of lighting on the underside of terrain, particularly the Nether ceiling. The plugin’s comments often note “with caveats,” suggesting it might have unintended side effects or not work perfectly in all situations.
    • My Approach: I leave this commented out (false). If you experience issues with Nether ceiling lighting in LODs, you could experiment with enabling this, but test thoroughly.

Remember, any setting not explicitly overridden in a world’s section will inherit from the global settings defined at the top of your config.yml.

Other Notable Settings

  • include_beacons

    • Default: false
    • My Approach: I have this set to true (by uncommenting #include_beacons: true) because I want beacon beams to be visible in the distant LODs.
    • What it does: If set to true, beacon beams will be included in the LOD data. The plugin authors generally suggest generating initial LODs with this false and enabling it later if desired, as it can add to processing.
  • level_key_prefix

    • Default: Not set (empty)
    • What it does: Used when running DHS on a proxied server (e.g., BungeeCord/Velocity). Set this to a unique value for each backend server to prevent conflicts.

Remember to restart your Minecraft server after making any changes to the plugins/DHSupport/config.yml file for them to take effect. The comments within your specific config.yml are an excellent resource and may contain the most up-to-date information for your plugin version.

With the Distant Horizons server plugin installed and configured, your Minecraft server is now equipped to offer a truly immersive visual experience with enhanced Level of Detail (LOD) rendering for your players. Keep an eye on the official Distant Horizons Server Plugin GitLab page for updates and new features.

Enjoy the stunning, far-reaching views on your server!


Happy adventuring!

Share:
Back to Blog

Related Posts

View All Posts »