DH LODs further than server.properties view-distance not being sent to client.
Hey, i have just started my own home server and decided to host a minecraft Fabric server on it.
I'm using itzg/minecraft-server docker image with the following docker compose config: https://mclo.gs/Sdiiub3
My server-side mod list:
https://mclo.gs/NIzEK2J
As far as I know, these mods are intercompatible.
C2ME is running in Java 21 compatibility mode, from what I could see in the logs.
One note is that the world itself is not newly generated, but a migrated LAN multiplayer world, which was also ran with an older version of distant horizons (still 2.3+)
Upon migrating the save, i have deleted the .sqlite database with, what I assume after reading the FAQ, is LODs previously generated during LAN multiplayer sessions. I am not able to confirm this at the moment, but i have most probably only cleared the overworld LODs.
Upon joining the world as a server operator, distant generation turned on client-side, LODs have successfully generated for me in a config specified radius, F3 is showing "server has full DH" support, jobs running and queue progress. The behaviour is intended in that case aside for a fact that I can't for some reason access any of the /dh commands. Hints in the command line aren't popping up and running the commands results in unknown command error.
The other player, which used to be a previous host of the LAN world migrated to this docker minecraft server, upon joining as an operator, same client-side settings as mine, only gets LODs from the server when they load into player's view, the radius specified doesn't load by itself, there is no visual progress of the LODs loading until the player moves to the chunks. They still run a DH version used initially during LAN world setup, i am certain that it is 2.3+ and almost certain that I run this very same version on my client side, since i don't recall updating it manually ever. I haven't seen their F3.
My full SERVER-SIDE Distant Horizons config file: https://mclo.gs/vXGryn9
8 Replies
If diagnosing the issue requires any more info like logs or information from the client side (confirming the client side DH mod versions included) while on the server, I can't provide it at the moment, i can later edit this ticket or create a new one with additional attachments.
Shortly, i think what can be immediately addressed is
–Could this have anything to do with the previously generated LODs on the other player's side, while they were a LAN world host? Maybe for my client it's my LODs from the LAN world loading since in both cases i was a multiplayer world client. Chunk jobs running in queue in F3 suggest otherwise, but could this be possible theoretically?
–Why are /dh commands unavailable for a player logged in as an op? Gitlab suggests using them with minecraft chat hints, so i assume it's supposed to be available through that. I haven't tried running the commands through docker exec minecraft-fabric rco-cli "command" but even if it does work, this still seems like unintended behaviour.
I'd be really happy to get some troubleshooting steps if the solution is not immediately obvious with the info i was able to provide.
Need to see the other player's F3 screen
I'm guessing it says "incompatible protocol version"
does /help dh return the command list?
@Jckf (GMT+2) @пшш
I'll be able to get to you with any info that is not provided in my initial post later, for now i nor the player experiencing the lod loading issue are not able to log in and check anything
If that's the case, what would it mean?
Version compatibility issue?
if another player is running the nightly build, they'll not receive LODs because the protocol was updated for a new feature
I am fairly certain both me and the other player are running the same dh version client side. It was the latest one as of april 24 and we probably updated it to the first version to support 1.21.8. We only run stable builds available on modrinth, not nightly
I think i'll be able to find out which version they are running client side for sure
It's DH 2.3.4-b-1.21.8 fabric-neoforge
Try updating to latest one from Modrinth or current nightly
I'll try that later and come back with the results but there are no documented protocol changes on gitlab between 2.3.4 and 2.3.6 either way