Fixing Minecraft Realms support

Introduction to OneDot (Pre-Stardance)

I started this before Hack Club, so it’s worth the explanation. Since Mojang announced they would remove the “1.”, I felt like it was too iconic to be removed. So, I setup a mod template and combed through MC version code. It turned out that there is the SharedConstants class, which contains a “WorldVersion” and a human-readable “name” string. We just need to add “1.” to the start of the string. That is basically it.

Now since WorldVersion is an interface, I took the SharedConstants CURRENT_VERSION variable and basically just made another WorldVersion with my modification.

Finally on the client side, I have to call the SharedConstants.setVersion method. I thought I could just do this without the mixin but the game won’t let you change constants like that. But, if I don’t call the setVersion (that I modified to include the “1.”), nothing will happen. Probably because the setVersion is called before any mods are loaded (it’s like, one of the first things the game does as you launch it - possibly before the window is even made! I remember thinking the LAUNCHER did it via some java executable flag, but I’m not sure).

Realms fixing (Stardance)

A few weeks ago, I saw a bug https://github.com/JPeisach/OneDot/issues/1 about how Realms would say “client incompatible!”. Now I don’t use realms, but as hypothesized in the bug report, the RealmsClient in Vanilla does indeed send the client version number to the realm for authentication. And of course, with the “1.” at the start, that makes a version mismatch.

The nice thing about the SharedConstants solution is that it appeared everywhere - the window title, the title screen on the lower left corner, the F3 menu - but this is a case where we don’t want the version number to change.

I quickly traced down the call to WorldVersion.name. Thankfully in the code, Mojang abstracted all the execute functions that send the version in the request to the same function. After fighting around with Mixins and figuring out where best to inject my replaced String, I got a proposed patch. (Thankfully with the IntelliJ Minecraft modding plugin, it could provide a Mixin reference. But until then I forgot about it and tried to manually play with it. I looked at docs, and tried redirecting the method call, or injecting into the returns - I settled on ModifyArg). For simplicity, I just substringed the first three characters instead of trying to play with indexOf in case another “1.” appears in the version number.

Oh yeah, and that requires another mixin. Unlike the SharedConstants mixin, it actually lies in the client only, so there has to be a client mixin package now. No biggy.

Takeaways:

• As always, you are playing with fire when trying to modify a constant
• Thorough testing is needed, and if I had used Realms I probably would have thought about this long ago (It doesn’t impact regular Java servers, but it does for Realms - perhaps if needed I can remove the “1.” In any version requests to multiplayer servers)
• This new mixin will also need to be added to the Neoforge branch, which hopefully will be easy.
• The mod being so small, and the SharedConstants and WorldVersion class not changing makes the mod easy to “maintain”, because it stays compatible. I just need to check on Modrinth the “supported versions” and check every now and then that the mod launches. This may change that - if Mojang changes the RealmsClient class, things may need to change.
• Work smarter, not harder (should’ve used the Mixin target reference from the start instead of wasting like 10 minutes on it)

Testing needed

I don’t have access to realms, I need someone else to test to make sure they can still reach it. But this fix should work. If you have access to a realm, please let me know. (I’ve also contacted the initial bug reporter).