Jump to content

Versioning and server compatibility


Jay Avery

Recommended Posts

I'm trying to figure out how to name and define versions for my mod. I know that any version will only be compatible with a single minecraft/forge version - which will be defined in @Mod.acceptedMinecraftVersions, in "mcversion" in the mcmod.info, and in the minecraft version section in build.gradle. (Am I on the right lines so far?)

 

With other things as their default, the mod only allows a client to connect to a server which has the exact same mod version. So, say a 1.0.0.0 client can't connect to a 1.0.1.0 server. I'd like to allow clients to connect as long as their major version matches - so 1.0.1.0 should be able to connect to 1.0.0.0, but 2.0.0.0 shouldn't. I know there's @Mod.acceptableRemoteVersions. But I just tested that by setting it to the exact current version of the mod (i.e., I expected the result of this to be the same as if I hadn't changed this from the default at all), and ended up being able to connect to a server that wasn't even forge, let alone had my mod installed. Do I need to change a setting elsewhere, like in build.gradle or mcmod.info too? Have I misunderstood what acceptableRemoteVersions is supposed to do?

 

I'm just confused because there are settings and metadata in various different places and they seem to all be important in similar but distinct ways and I can't figure it all out. :S It would be great if there was a summary somewhere about what the different bits do and how they relate, if anyone can recommend such a source? I've looked at the forge docs and stuff, but information about the different aspects is quite disjointed and separate and that's what I'm having trouble with.

Link to comment
Share on other sites

22 minutes ago, Jay Avery said:

I'm trying to figure out how to name and define versions for my mod. I know that any version will only be compatible with a single minecraft/forge version - which will be defined in @Mod.acceptedMinecraftVersions, in "mcversion" in the mcmod.info, and in the minecraft version section in build.gradle. (Am I on the right lines so far?)

 

That's correct.

 

22 minutes ago, Jay Avery said:

With other things as their default, the mod only allows a client to connect to a server which has the exact same mod version. So, say a 1.0.0.0 client can't connect to a 1.0.1.0 server. I'd like to allow clients to connect as long as their major version matches - so 1.0.1.0 should be able to connect to 1.0.0.0, but 2.0.0.0 shouldn't. I know there's @Mod.acceptableRemoteVersions. But I just tested that by setting it to the exact current version of the mod (i.e., I expected the result of this to be the same as if I hadn't changed this from the default at all), and ended up being able to connect to a server that wasn't even forge, let alone had my mod installed. Do I need to change a setting elsewhere, like in build.gradle or mcmod.info too? Have I misunderstood what acceptableRemoteVersions is supposed to do?

 

@Mod#acceptableRemoteVerions expects a version range, not just a single version. It's parsed using VersionRange.createFromVersionSpec, which has a doc comment explaining the format.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

From the comment, it looks like a single version string should be interpreted as a valid version range - shouldn't it? And I don't understand how, even if I wrote the version range in the wrong format, it ends up letting me connect to a non-forge server. I would expect it to just not allow connecting to any server if it doesn't understand the version range I've given? :S

Link to comment
Share on other sites

5 hours ago, Jay Avery said:

From the comment, it looks like a single version string should be interpreted as a valid version range - shouldn't it?

 

You're right, I missed that.

 

 

5 hours ago, Jay Avery said:

And I don't understand how, even if I wrote the version range in the wrong format, it ends up letting me connect to a non-forge server. I would expect it to just not allow connecting to any server if it doesn't understand the version range I've given? :S

 

Looking into the code further, it appears that using a single version rather than one or more version ranges creates a VersionRange with a single Restriction (Restriction.EVERYTHING) that matches everything and completely ignores the version you passed it.

 

In addition to this, NetworkModHolder.DefaultNetworkChecker (the default implementation used to check if the remote mod list is compatible with the local mods) allows the client to connect to a server without the mod installed.

 

I'm not sure of the reason behind either of these.

 

You can work around the latter by providing your own NetworkChecker, just annotate a method with @NetworkCheckHandler. See the doc comment for the required signature.

  • Like 1

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

Thanks for the tip! I've implemented my own NetworkChecker, and then found that... it still ignores the version compatibility when connecting to vanilla servers. I tracked it down to FMLHandshakeClientState.HELLO, where it shortcuts all the checks and immediately returns DONE if it doesn't get an FML message from the server. So I don't even get a chance to intervene using my own NetworkChecker. So I guess this means that any forge client will always be able to connect to a vanilla server, and I just have to trust users not to be silly enough to do that? It seems like a strange arrangement..

Edited by Jay Avery
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • I had been using a mobile wallet to store around $200,000 worth of Bitcoin, and everything was going smoothly until my phone was stolen. At first, I wasn’t too worried. I thought I had written down the backup phrase somewhere safe, so I figured I could easily recover my funds. But after tearing my home apart, checking every drawer, notebook, and folder I could think of, I came to a horrible realization—I hadn’t been as careful as I thought. The backup phrase was nowhere to be found. Panic started to set in. Losing access to that much Bitcoin was like watching years of hard work and financial progress vanish right before my eyes. It wasn’t just about the money; it felt like my future had been snatched away in an instant. I couldn’t believe I had been so careless. It was a nightmare that I wouldn’t wish on anyone. Desperate to find a solution, I started searching online for recovery options. That’s when I came across Cyber Constable Intelligence, recommended by someone in a cryptocurrency forum. At first, I was hesitant—there are so many scams in the crypto space, and the last thing I wanted was to get ripped off while trying to recover my funds. But the positive reviews gave me a glimmer of hope, so I decided to reach out. From the moment I contacted Cyber Constable Intelligence on Email at support (AT) cyberconstableintelligence.com, they made me feel understood and reassured. They didn’t make me feel stupid for my mistake, which was something I really appreciated. They explained the recovery process clearly and thoroughly, and they reassured me that they had successfully handled cases like mine before. Even though I was still anxious—after all, this was $200,000 on the line—I felt like I was in good hands. The next few days were tense, but then I received the news I had been praying for: Cyber Constable Intelligence had managed to recover my Bitcoin. I honestly didn’t believe it until I logged in and saw my balance restored. It was like a second chance at life. The relief was overwhelming. If you’ve lost access to your wallet, no matter how hopeless the situation may seem, I can’t recommend Cyber Constable Intelligence enough. They turned my nightmare into a success story, and I’m forever grateful for their expertise and professionalism. Here's Their info below What Sapp Info: 1. (2. 5.  2.  ) 3.  7.  8.  (7. 6. 1. 1.) Website Info : www. cyber constable intelligence   com
    • So I'm creating yet another minecraft modpack and stumbled upon error I've never encoutered.. I tried to troubleshoot it myself and it always worked but this time I didn't manage.. Here is minecraft crash report: https://pastebin.com/EVqzdDKg I can't find how or from where to post debug.log  I'm sorry, can someone help me? (as a disclaimer - i've tried already reinstalling minecraft and java)
    • It works without mods, I've ran it through the launcher by itself and runs perfectly fine, when I open it through Forge I can get through to the launcher but when I go to open the world it loads then gives me the error code 1. Is there anymore info that could help diagnose it?
    • Also had the issue. GLAD TO TELL YOU I HAVE THE FIX! Create: Applied Kinetic literally says "Replace all inscriber recipes with Create's sequenced assembly recipe". When I turned off this mod it worked fine. I also didn't use that mod of the pack i played so it didn't matter for me.
    • Right now im trying to make an own mod for minecraft for the version 1.16.5 with forge but whatever i do it still doesnt fix the error this is my build.gradle : buildscript { repositories { maven { url = "https://maven.minecraftforge.net" } mavenCentral() } dependencies { classpath 'net.minecraftforge.gradle:ForgeGradle:5.1.+' } } apply plugin: 'net.minecraftforge.gradle' apply plugin: 'java' group = 'com.example' // Modify to your package name version = '1.0' archivesBaseName = 'flippermod' java { toolchain { languageVersion = JavaLanguageVersion.of(8) } } minecraft { version = "1.16.5-36.2.42" // Ensure this matches your Forge version mappings channel: 'official', version: '1.16.5' runs { client { workingDirectory project.file('run') property 'forge.logging.markers', 'SCAN,REGISTRIES,REGISTRYDUMP' property 'forge.logging.console.level', 'debug' mods { flipper_mod { sourceSets.main.output } } } } } repositories { maven { url = "https://maven.minecraftforge.net/" } mavenCentral() } dependencies { minecraft "net.minecraftforge:forge:1.16.5-36.2.42" } and this one is my settings.gradle:  pluginManagement { repositories { gradlePluginPortal() maven { name = 'MinecraftForge' url = 'https://maven.minecraftforge.net/' } } } plugins { id 'org.gradle.toolchains.foojay-resolver-convention' version '0.7.0' } rootProject.name = 'flippermod' this one is the mods.tml    modLoader="javafml" loaderVersion="[36,)" modId="flippermod" version="1.0.0" displayName="Flippermod" and the last one is the gradle-wrapper.properties distributionUrl=https\://services.gradle.org/distributions/gradle-7.6-bin.zip dc :"code_slivki"
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.