[FrustratedMonky]

Love the idea. Especially as a learning example. Always fun to learn a language by implementing a popular game.

Am confused by these two lines. Maybe it is just difference between the 'goal' and the 'current state'.

Goal:

"Compatibility: Supports the latest Minecraft server version and adheres to vanilla game mechanics. "

But NOT:

"Be a drop-in replacement for vanilla or other servers "

Will it be a replacement for Vanilla or not?

[hexmiles]

Compatibility: refers to the ability for client of the latest mincraft server version to be able to connect to the server (pumpkin) unmodified with all mechanics working.

Drop-in replacement: refer to the ability of a server operator to simply exchange the current installation/executable of the server (be vanilla, paper, cuberite, etc...) for pumpkin while maintaining data, configuration, scripts and mods installed.

edit: grammar

[FrustratedMonky]

Tell you the truth, that doesn't help clarify to me much.

If it is compatible, then can't I 'drop it in'.

They sound like they are saying the same thing.

It is compatible so clients can connect to the server and be fully operational, and thus, I should be able to drop in this server, and use it as a server?

How can it be compatible if it doesn't maintain data, configuration, etc..

Edit: or is this about Pumpkin files. Pumpkin will maintain it's own files, data, configuration. So it can't just use existing Minecraft data files.

So if it was a new world, Pumpkin would generate new pumpkin formatted files. But couldn't just 'drop it in' on an existing world and use the existing Minecraft data files.

Not sure of long term viability as far as effort, but if it is files, couldn't a converter from MineCraft to Pumpkin file structure, make the server 'drop in'?

[Arch-TK]

Maybe some more concrete examples may help:

* nginx is not a drop in replacement for apache

But from a client perspective, both implement HTTP/1.1.

* podman is not a drop in replacement for docker

But from a client perspective connecting to a service hosted in docker, that connection can still occur over TCP.

On the other hand:

* pkgconf is a drop in replacement for pkg-config

* cronie is a drop in replacement for vixie-cron

[FrustratedMonky]

"But from a client perspective, both implement HTTP/1.1."

This seems too low level example to apply for Minecraft.

Minecraft has a lot going on, back and forth. For something to be 'compatible' it would need to be so detailed an implementation of the server, that it could potentially also be a 'drop in'.

[Arch-TK]

When it comes to game servers, especially for highly modified games like minecraft, there's the client facing side, including how the game behaves, and then there's the server administration side.

If I were to interpret the statement made here I would assume that not-a-drop-in while being vanilla compliant means things like:

* It won't support server side mods without you re-writing them in rust

* It won't support bukkit plugins without you re-writing them in rust

* It doesn't support the configuration file format that the java server uses

* Maybe it doesn't support the world file format (which would be server side only)

* Maybe it doesn't support the same administrative commands (which you would only see as an administrator)

etc.

So it can definitely be compatible from the client perspective while being woefully incompatible with any prior experience anyone running a minecraft server might have.

[hakanderyal]

Drop-in means replacing an existing thing with a new one without changing anything.

This is not compatible with other servers plugins/data/configurations, so just replacing the binary and expecting to continue where you left off is not possible.

[hoseja]

Compatible: You start a Pumpkin server, vanilla clients can join and play.

Drop-in: You run a server for some time. You decide to switch the software by replacing the executable. Everything works as before.

[bombcar]

"Drop-in" is what enterprise software calls "bug-for-bug compatible" - e.g., replacing RedHat with CentOS (RIP) should work exactly the same, even if the CentOS team found bugs - they report them upstream and do NOT fix them themselves, because code may be relying on the bugs.

This is especially true with complicated vanilla Minecraft setups and red stone machines (Java Minecraft red stone has "bugs" that "shouldn't be there" but cannot be removed now since so much depends on it).

[FrustratedMonky]

Guess this gets to my other point.

By the time you are 'compatible' then you have implemented everything needed to also be a 'drop-in' but data file formats might need a conversion.

So convert from Minecraft data files to Pumpkin data files. Then it could drop in.

[nickitolas]

If you need to separately convert files yourself, then it is by definition not drop in

[FrustratedMonky]

Didn't really mean 'myself'. But if Pumpkin detects an existing world, and does the conversion to their own format. Then it is drop-in.

Even if they supply a tool, isn't it drop-in.

Otherwise I'd so no software in existence is really drop-in. Most of them have some update that has to happen.

[p0w3n3d]

I would say that Minecraft servers by some qualities are really hard to implement (for example generate world as Java would - using Java's random number generator to generate exactly the same world in Rust) or even impossible. But other usages, like walking through existing world with 1000 of your colleagues might be worth of writing a very fast but not a "drop in replacement" server. Or a massive minigame maybe?

[alex_medvedev]

Hey, There were already efforts made to rewriting the same random generators from Java, And they work. Same seed as in vanilla, Same Result as in vanilla

[Xeamek]

But the world generation is already deterministic with seeds

[IX-103]

It's only deterministic if you feed the seeds into the exact same pseudorandom number generator and fetch random values from it in the exact same order. If you take a single extra random value out of order, then everything ends up different.

[alex_medvedev]

Hey, With Compatibility i mean be compatible with existing Minecraft vanilla client's and also use vanilla logic. With "Be a drop-in replacement for vanilla or other servers" i mean that if you just replace the existing server file with pumpkin, pumpkin will not load configs/plugins from vanilla/other servers

[FrustratedMonky]

Hello

I see it is not a drop in when using other tools, plug ins, 3rd party things.

But what about just a plain vanilla world.

Can Pumpkin read in and use the plain vanilla files? Does it do some kind of conversion and have it's own file structure?

So if I had a simple server, it could be a drop-in.

Or does the world need to be generated new inside Pumpkin? I can't use existing worlds.

[giancarlostoro]

> i mean that if you just replace the existing server file with pumpkin, pumpkin will not load configs/plugins from vanilla/other servers

Will it ever though? Is this a goal?