/version command shows [INFO] Unknown version, custom build?

[satoshinm]

When I run /version, it logs about a custom build, even though I am using an official build from https://www.glowstone.net/#downloads:

>version
21:30:15 [INFO] This server is running Glowstone version 2017.6.1-SNAPSHOT.b01b8fe-MC1.12 (Implementing API version 1.12-R0.1-SNAPSHOT)
21:30:15 [INFO] Checking version, please wait...
21:30:15 [INFO] Unknown version, custom build?

(where is it checking the version from?)

Glowstone build 544

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/46076757-version-command-shows-info-unknown-version-custom-build?utm_campaign=plugin&utm_content=tracker%2F14691067&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F14691067&utm_medium=issues&utm_source=github).

[mastercoms]

The version command is from PaperAPI. It needs to be overridden with a new command for Glowstone. I don't want a patch for it in Glowkit because a implementation specific command like version does not make sense there. We should change the version command in Glowkit to be implementation agnostic (like the original Bukkit command), and then provide our own version command in Glowstone.

[mastercoms]

Perhaps the best way to handle this issue is to add a version provider interface to the API command class. Then, the server would register a version provider to the API command class early on, and that would be used to get the current version, compare versions, get the latest version, etc.

[Pr0methean]

@mastercoms This sounds too complicated, unless we want to allow plugins to modify the version string. Otherwise, a program's version should be a compile-time constant.

[mastercoms]

It would only be able to be set once, and would allow the basic command logic to be in the API, while having most of the implementation on the server.

[Pr0methean]

Why shouldn't the version string just be a static final String populated at build-time by a template engine (which could live in GlowServer's package in source code and be inlined into GlowVersionCommand at build time)? I still don't understand why it has to be more complicated than that.

[mastercoms]

I think I didn't explain something correctly. I am talking about the version command in Bukkit. A remote version check was added to the version command, which lives in Bukkit. But this remote version check is implementation specific, despite being in the Bukkit API, which is supposed to be server agnostic.

I was proposing a way for Paper to add something to the version command that would allow the server to specify how to do those remote checks, without modifying source code. Of course we would still implement the Bukkit getServerVersion method as compile time. But we would need some sort of interface that can be set once at runtime by the server in order to specify how to get a current version string that can be compared to a remote version string which represents the latest server version. This is because some servers may have a different representation for their remote version string compared to the getServerVersion string.

[aramperes]

Paper abstracted their version command by creating a VersionFetcher API (thanks @zachbr!), which we can implement and set in the UnsafeValues implementation. This feature is only available in 1.14.

[Pr0methean]

Yet another reason to hurry up and finish 1.13!