is dynamic multi version support possible ?

[rom1504]

static multi version support is now implemented. What about dynamic ?

Reminder :

• static multi version support means you set the version in the config and once the server is start the version is fixed for all players
• dynamic multi version support means you don't set the version, and the version is adapted for each player

The difficulty is mostly about converting chunk to the correct version I think. Otherwise the code is almost ready for this.

I might try if I have some time.

[rom1504]

I think we could have a

const chunk = require('prismarine-chunk')('multi')
chunk.load('1.12')
chunk.dump('1.8')

[builder-247]

Any idea when you could implement this? This is pretty much a core feature for the authentication server I'm working on.

[rom1504]

what is that authentification server ? why does it need dynamic multi version ?

[builder-247]

Basically it kicks a player with an authentication code as a kick message as soon as they join, so their identity can be verified in e.g. web applications.

The minecraft community is pretty much divided to players using 1.8.9 and to those using the latest release. Having one server support all minecraft versions would make it easy for all players to use the authenticator.

[rom1504]

That sounds like you don't need a full implementation but only something very basic like the node-minecraft-protocol server. You could be using that to implement your authentication server. There's no dynamic multi version there either but it's much easier to.implement than here. Flying-squid is based on node minecraft protocol

…

On Thu, Jun 28, 2018, 23:37 builder_247 ***@***.***> wrote: Basically it kicks a player with an authentication code as a kick message as soon as they join, sbo their identity can be verified in e.g. web applications. The minecraft community is pretty much divided to players using 1.8.9 and to those using the latest release. Having one server support all minecraft versions would make it easy for all players to use the authenticator. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#342 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPN_ldFIcM_OSn7I6NLg8CeFU8XvFjdks5uBUx_gaJpZM4UPXwF> .

[builder-247]

Great idea! It didn't cross my mind that I could create a lower level server, now I'll get more familiar with minecraft protocol as a bonus!

[Deudly]

Shouldn't this be a separated plugin? If you take Spigot as an example, they do not support multiple versions. But there're plugins that can help you to reach that result.

[rom1504]

No, that doesn't make sense.
Flying-squid and spigot are 2 completely different things.
Spigot is a thin layer above the vanilla server, it completely reuses its code. So they can't easily change things.
Flying-squid is a complete reimplementation, the only things it uses from minecraft is the data (block names, item names, recipes ,..) and the protocol.
So the architecture choices for spigot and flying-squid are different.

Flying-squid already support multiple version.

Supporting them dynamically would also be a core feature and should be implemented that way, it's not a plugin.

[unixfox]

Sorry for bumping this issue.

I'm also interested into this feature. My use case is a lobby for AFK players and a server where the players go if they are too much players on the main server.

[unixfox]

As a workaround you can use Bungeecord with ViaVersion on top of flying-squid to make it work from 1.8.x to 1.14.x.

[Pandapip1]

With 1.18 taller chunks, is this still possible?

[rom1504]

Maybe but not trivial. You could just cut chunks for lower versions. I guess that's how via version does it

[extremeheat]

For chunks, this would require using the lowest supported version as the base for everything. Blocks, world gen, height, dimensions, etc. would just be cached/translated for newer protocol versions.

[Pandapip1]

This might be a stretch, but what if, as a workaround, a player movement packet was sent at the same time as a full chunk update when in the lower 25% or upper 75% of the chunk, to allow the full chunk to be used?

[extremeheat]

Would not be affected