MCRcortex / MCRcortex/voxy

[feature request] tell the server that my render distance is higher than it really is

Open
#613 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
1.2k
Forks
1.1k
PR merge metrics
No merged PRs in 30d

Description

I’m not sure if what I’m about to say will make any sense, but it’s something I’ve been thinking about for a while.

Basically, the point of using voxy is to be able to use a low render distance for the sake of performance while still being able to see distant chunks. There are two problems with this.

First, entity render distance is capped by your chunk render distance, so even though i can see the blocks that are far away, the entities disappear at my true render distance limit.

Second, in order to generate voxy LODs on servers, your client needs to load the chunks within your actual render distance. If that render distance is quite low (i.e. lower than the server’s max render distance), you won’t be caching as many chunks for voxy as you could be.

My suggestion is to, if possible, have voxy always tell the server you’re connected to that your client render distance is 32 chunks (regardless of what it actually is), so that the server will send your client further away chunks (not to be rendered by the client directly, but to be used by voxy to generate LODs) as well as further away entities (to be rendered in the distant terrain).

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points. Start by locating how the mod communicates client render distance to the server, then investigate whether a higher reported distance can provide distant chunks and entities without changing local rendering. Done means the request is technically feasible and the behavior is implemented or the limitation is documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
game-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.