[HN Gopher] Show HN: Pumpkin - A Modern Minecraft server written...
       ___________________________________________________________________
        
       Show HN: Pumpkin - A Modern Minecraft server written in Rust
        
       Author : alex_medvedev
       Score  : 245 points
       Date   : 2024-10-15 09:18 UTC (13 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | alex_medvedev wrote:
       | Hello. I recently developed Pumpkin, Its a efficent and fast
       | Minecraft server completely written in Rust from the ground up,
       | Check it out :D
        
         | lesuorac wrote:
         | > What Pumpkin will not
         | 
         | > Be a drop-in replacement for vanilla or other servers
         | 
         | It seems to me that unless it's a drop-in replacement its not a
         | Minecraft server? Akin to how say an Uno deck isn't a drop-in
         | replacement for a Hearts deck but still both card games but not
         | both Uno decks.
         | 
         | Or is it just meaning that Pumpkin (besides the network) do
         | things differently than vanilla and so you might not be able to
         | open a vanilla created world using Pumpkin?
        
           | looperhacks wrote:
           | The common problem with Minecraft server implementations is
           | that they are not bug-for-bug compatible, which will lead to
           | certain techniques (especially redstone contraptions)
           | breaking. The technical Minecraft community depends on many
           | implementation details which not all servers support
        
             | Scaevolus wrote:
             | In addition to the hundreds of blocks and mobs that would
             | need to be implemented properly and rarely are, the lack of
             | mod support is a killer.
             | 
             | The only "complete" reimplementation of Java Minecraft that
             | I'm aware of is Bedrock.
        
               | dmonitor wrote:
               | Far from it. The versions lack a lot of parity and
               | Bedrock is called "bugrock" by the community for a reason
        
               | Scaevolus wrote:
               | I edited in scare quotes for "complete" to make that
               | clearer, but I mean in terms of at least having matching
               | blocks/mobs despite many differing details.
        
             | sandworm101 wrote:
             | There are no bugs in Minecraft, only features that have yet
             | to be fully documented.
        
           | Dobbs wrote:
           | Minecraft has a lot of bugs or otherwise surprising
           | behaviours that parts of the community have come to rely
           | upon. This means that most non-vanilla minecraft servers
           | aren't 100% drop in replacements. You have to make a decision
           | what behaviours you want vs the performance and simplicity
           | gains you will gain.
           | 
           | For example there there are tricks that allow you to delete
           | bedrock blocks. Which then lets you either get onto the roof
           | of the nether, or drop below the bottom of the world. Not all
           | of these tricks will then work depending upon the specific
           | minecraft server.
           | 
           | Another example is that in vanilla you can "bomb" people with
           | experience orbs, the sheer number of orbs on the screen will
           | grind their game to a halt since there are too many objects
           | to track and render. Some minecraft servers work around this
           | by grouping up experience orbs into a single bigger orb. That
           | way you have fewer orbs on screen at once.
        
             | rft wrote:
             | One bug abuse that blew my mind recently is the ability to
             | have wireless redstone in vanilla [1]. I fell deep into
             | that rabbit hole after a previous post on here about Bad
             | Apple in Minecraft [2].
             | 
             | [1] https://www.youtube.com/watch?v=FLynwXDnETI [2]
             | https://news.ycombinator.com/item?id=41798369
        
         | gynther wrote:
         | Cool! Would be interesting to understand how to multithreading
         | works? Is it just the "easy" parts or actual operations related
         | to the world as well?
        
           | alex_medvedev wrote:
           | Currently Pumpkin has not much multi-threading but we want to
           | go all in. There is already a good structure for multi-
           | threading, We want to make everything multi-threaded what
           | benefits from it
        
       | pzmarzly wrote:
       | Similar projects:
       | 
       | - Feather (Rust, abandoned) https://github.com/feather-rs/feather
       | 
       | - Valence (Rust) https://github.com/valence-rs/valence
       | 
       | - Cuberite (C++) https://github.com/cuberite/cuberite
        
         | jedisct1 wrote:
         | Minecraft Server (Zig) https://github.com/regenerativep/zig-mc-
         | server
        
       | FrustratedMonky wrote:
       | 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 wrote:
         | 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 wrote:
           | 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'?
        
             | hakanderyal wrote:
             | 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.
        
             | p0w3n3d wrote:
             | 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?
        
               | Xeamek wrote:
               | But the world generation is already deterministic with
               | seeds
        
             | hoseja wrote:
             | 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 wrote:
               | "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 wrote:
               | 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 wrote:
               | If you need to separately convert files yourself, then it
               | is by definition not drop in
        
               | FrustratedMonky wrote:
               | 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.
        
             | Arch-TK wrote:
             | 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 wrote:
               | "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 wrote:
               | 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.
        
         | alex_medvedev wrote:
         | 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
        
           | giancarlostoro wrote:
           | > 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?
        
       | icepat wrote:
       | Reminded me of this existing
       | https://dayssincelastrustmcserver.com/
        
       | dangoodmanUT wrote:
       | this person is going gods work
        
       | mobeigi wrote:
       | Are there any benchmarks for it? How much faster is it than a
       | vanilla server?
       | 
       | I know Minecraft servers tend to get extremely resource intensive
       | as the player count creep and people run extremely beefy servers
       | to handle the load and still offer poor TPS.
        
         | alex_medvedev wrote:
         | Hey, Your lucky, i just made benchmarks all this time :D. Check
         | them out
         | https://snowiiii.github.io/Pumpkin/about/benchmarks.html
        
           | kridsdale3 wrote:
           | I literally said Holy Shit out loud. This is an incredible
           | improvement, and I'll refer to this in the future when I'm
           | asked if we should make something new in Java.
        
             | mouse_ wrote:
             | Yes but also consider the extensibility accessibility Java
             | gave us. EVERYONE was building Minecraft mods back in the
             | beta days. I might go as far as to say that extensibility
             | is what made Minecraft so great.
        
               | pphysch wrote:
               | No doubt about it. I don't think Minecraft would have
               | gotten as far as fast in the public consciousness without
               | content creators like Yogscast being able to produce so
               | much novel content from modded Minecraft.
        
               | somat wrote:
               | What I always found surprising was how many minecraft
               | mods there were despite mojang having absolutely no mod
               | support for the game.
               | 
               | After learning that to make a minecraft mod the process
               | was basically decompile minecraft fight the terrible
               | names provided by the decompiler to make your changes
               | then recompile it, I lost all interest.
        
               | nulltxt wrote:
               | Yarn[1] has pretty much fixed this along with fabric.
               | 
               | [1] https://github.com/FabricMC/yarn
        
             | alex_medvedev wrote:
             | I was suprised myself thats its that bad. Well optimized
             | binary is that what your CPU loves not a big JVM runtime
        
             | dpedu wrote:
             | Keeping in mind that this server appears to implement only
             | a tiny subset of the features the ones it is benchmarked
             | against do... No lighting, mob spawning, mob ai, redstone
             | functionality, tree or plant growth, water/lava flow, etc.
        
               | Aeolun wrote:
               | These wouldn't significantly affect the first 10 chunks
               | loaded?
        
           | canucker2016 wrote:
           | Please, just use one measurement unit across all measurements
           | for easier comparison (i.e. RAM in MB, time in ms).
           | 
           | Wow. Pumpkin's runtime is way better (faster, much less RAM
           | used) than the Java versions. Congrats.
           | 
           | I wonder what the Kotlin-based Minestom is doing differently
           | that causes it to have numbers between Pumpkin and the Java
           | versions.
           | 
           | For comparison's sake, do you have build times for Pumpkin?
           | I'll assume that's where critics may target.
        
       | ramenlover wrote:
       | Are you sharding the main thread into regions (ie. Like paper
       | folia) or is this just breaking of non block-entities to their
       | own threads.
        
       | saintradon wrote:
       | This looks great! Can't wait to check out the code in detail.
        
         | alex_medvedev wrote:
         | I would love to hear some feedback, tried my best so code is
         | clean :D
        
       | bbno4 wrote:
       | It has now been 0 days since a new minecraft server was written
       | in Rust https://dayssincelastrustmcserver.com/
        
         | xx_ns wrote:
         | Pumpkin is already on that list.
        
         | JadoJodo wrote:
         | It's pretty funny how many of these are "Is it a Minecraft
         | server? No. It's a framework with which you can build your own
         | rewrite of Minecraft server."
        
         | whazor wrote:
         | I was thinking it would be cool to have a Minecraft server
         | built with Bevy, but that has also already been done:
         | https://github.com/valence-rs/valence
        
         | whalesalad wrote:
         | This got me thinking - is Rust really the right tool for the
         | job? And I thought, Elixir/Erlang feels like the perfect tool.
         | Sure enough, someone did it! Great reference material for
         | someone learning how to do things on the beam
         | https://github.com/thecodeboss/minecraft
        
         | Imustaskforhelp wrote:
         | Lmao it is funny how we have daysinceX websites. is there a
         | list of all such websites of daysinceXofY like
         | dayssincelatestframeworkofnode I guess?
        
         | AbraKdabra wrote:
         | omfg haha.
        
       | bradhe wrote:
       | This weeks Minecraft server! Nice!
        
       | superlucky84 wrote:
       | looks good
        
         | alex_medvedev wrote:
         | thank you :3
        
       | WhereIsTheTruth wrote:
       | i wish minecraft was open source, i'd be able to fix their
       | inefficient protocol
        
         | WhereIsTheTruth wrote:
         | Downvoter, go check this: https://wiki.vg/Protocol, let me know
         | if that's a good way to sync a lot of fast moving entities
         | across a TCP network
         | 
         | This is why people struggle with their servers, not because the
         | game was written in java
        
           | giancarlostoro wrote:
           | Curious what protocol you would use, or how you would do it
           | differently? Are there small enhancements to the existing
           | protocol you would do? Genuine open question for the sake of
           | learning.
        
             | alex_medvedev wrote:
             | I would prefer the UDP Protocol over TCP like in Bedrock
             | edition. Im pretty sure many PVP players would love this.
             | Here is much non sense in the Minecraft protocol and things
             | made to work not to be optimized (deadlines). At our
             | discord we even already have a sticker :mojang_nonsense:
             | which will be used quiet often. I also don't understand
             | Mojang's tactic with packet changes, It sometimes looks
             | like they care about Packets not being broken and being
             | backwards compatible but them sometimes they change the
             | whole Networking system (1.20)
        
           | lucb1e wrote:
           | Basically any significant Java software uses disproportionate
           | amounts of RAM. My server can easily run a web server,
           | database server, ftp server, memory cache, etc., times a few
           | copies because various containers have their own web server
           | or whatnot, all at the same time. But a single copy of
           | Minecraft is too much, even when everything else is shut
           | down.
           | 
           | That's why I struggle with the server: it's written in Java.
           | Other game servers don't seem to have this problem. If the
           | network protocol were all, that'd be great
           | 
           | (I didn't downvote any of your posts in case you now wonder
           | if that was me)
        
       | kgeist wrote:
       | What does "modern" mean in this context?
        
         | alex_medvedev wrote:
         | Its written from the ground up and has a clean foundation
         | (which is not the case in vanilla minecraft server code). We
         | also want to use cool modern features like multi-threading or
         | the rust language which is a modern language designed to fix
         | mistakes from older languages
        
           | philipwhiuk wrote:
           | > cool modern features like multi-threading
           | 
           | Java 6 had multi-threading
        
             | Imustaskforhelp wrote:
             | I read this in the most satirical way possible like as if a
             | godly narrator said it calmly.
             | 
             | It was really funny. It felt like a Satire LMAO
        
             | nijave wrote:
             | The limitation isn't the Java version, it's the way the MC
             | code was architected.
             | 
             | Iirc part of original Minecraft's performance limitations
             | were high object create/destroy rate leading to lots of
             | garbage collection. With that in mind, picking a non-GCd
             | language isn't completely crazy.
        
               | kgeist wrote:
               | It was the other way around: say, the original code as
               | written by Notch had functions like setPosition(x,y,z)
               | and it was okay. When Jeb got in charge, he said "it's
               | not object-oriented enough" and rewrote everything to
               | setPosition(position). And boom, 1GB/sec allocations...
        
               | intelVISA wrote:
               | How horrifying!
        
             | giancarlostoro wrote:
             | While Java does, the Minecraft server architecture does
             | not.
        
             | plandis wrote:
             | I think they are being sarcastic because the vanilla
             | Minecraft server is heavily single threaded.
        
         | slgeorge wrote:
         | "Modern" seems to be used a loose adjective these days for "I
         | rewrote $thing [in Rust]". Minecraft was created in 2011, and
         | is Wikipedia says the last version of the 'classic' edition was
         | released in 2017. So anything after 2017 is now defunct.
         | 
         | I don't mind people rewriting things in <insert-name-of-tech-I-
         | like> but "modern" as a value seems pretty loose, and it's
         | often at least arguable whether it's objectively better!
        
           | codetrotter wrote:
           | "Modern" more usually means some new JavaScript thing. In JS
           | land, they consider anything that hasn't had a commit on main
           | branch in over 3 days to be a dead old project in need of
           | being replaced with something new and "modern" that is up to
           | date with the latest trends and breaking changes from the
           | previous 24 hours of their world.
           | 
           | Usually the hyperbolic superlative for Rust projects is
           | "blazing fast". Of course, any kind of benchmarks or
           | comparisons with other implementations are completely
           | optional. It is simply enough to "cargo init" and start
           | hammering out code. You don't even need to consider the
           | characteristics of the algorithms you choose to use! If it's
           | Rust, it's "blazing fast".
        
             | c-hendricks wrote:
             | Where's that meme of the guy painting demons then laying
             | down on the floor in fear when you need it.
        
             | renewiltord wrote:
             | Your most starred repo is inferior to a shell one-liner
             | lol. Talk about pot calling the kettle black. Just use the
             | system dict, shuf, grep, and head.
             | 
             | It's bad form to badmouth someone's earnest work for sure.
             | I wouldn't do it normally since I think it's nice that you
             | actually did something. But if you're going to sit in a
             | glass house and throw stones you should expect some back.
             | 
             | Fortunately, my house is an underground burrow so I can
             | throw stones with impunity. As ugly as it is to do.
        
               | codetrotter wrote:
               | > a shell one-liner lol
               | 
               | Dig a little deeper in the repos and you may eventually
               | find that this is exactly what that started as :^)
               | 
               | > badmouth someone's earnest work for sure
               | 
               | Was speaking generally. Not meant at OP. I think it's
               | awesome that they are making a Minecraft server in Rust.
               | 
               | > Talk about pot calling the kettle black
               | 
               | Of course! Anything else would be bad form.
               | 
               | > my house is an underground burrow so I can throw stones
               | with impunity
               | 
               | Sneaky, sneaky ;)
        
               | renewiltord wrote:
               | Haha fair play if you're in the "we're all clowns here"
               | camp.
        
           | alex_medvedev wrote:
           | Sorry, I may should not used the term Modern, Lets say the
           | foundation is newer and more optimized than from the Original
           | Minecraft server. Mojang developers have strict deadlines and
           | do not care about performance (like basicly any big Studio
           | today). This results in bad ugly code which only purpose it
           | is to work nothing more. Minecraft was created 2009 btw
        
             | ramenlover wrote:
             | I'd argue they care about performance, but they also care
             | about a whole slew of other things that also require
             | prioritization to maintain the game and its cottage
             | industry. Not a huge fan of the constant dogging on mojang
             | everyone loves to engage in...
        
               | bangaladore wrote:
               | People seem to forget that if you already know where the
               | finish line is, the journey on getting there can be made
               | quicker and more efficient.
               | 
               | This, at least in my experience, applies greatly to
               | software and hardware.
        
           | lucb1e wrote:
           | > "modern" as a value seems pretty loose, and it's often at
           | least arguable whether it's objectively better!
           | 
           | Well, there is research on this!
           | 
           | https://security.googleblog.com/2024/09/eliminating-
           | memory-s... writes:
           | 
           | > vulnerabilities decay exponentially. They have a half-life.
           | [...] A large-scale study of vulnerability lifetimes2
           | published in 2022 in Usenix Security confirmed this
           | phenomenon. Researchers found that the vast majority of
           | vulnerabilities reside in new or recently modified code
           | 
           | Where 2 goes to https://www.usenix.org/conference/usenixsecur
           | ity22/presentat...
           | 
           | A study limitation is that they looked only at security-
           | relevant bugs (vulnerabilities). As someone who writes code,
           | I would tend to think that this also goes for bugs without a
           | direct security impact, but I don't have the data to back
           | that notion up
        
             | Aeolun wrote:
             | Feels kinda obvious to me? As time goes on bug density can
             | only go on direction, and making no changes to a codebase
             | certainly doesn't make it go up.
        
       | tomasff wrote:
       | See also https://github.com/valence-rs/valence A "clean room"
       | implementation of the Minecraft server written in Rust
        
         | Imustaskforhelp wrote:
         | yes , I was also thinking about this . +1
        
         | alex_medvedev wrote:
         | Hi, Valence is a framework (similar to Minestom in Java). You
         | have to build everything you self. Pumpkin is not a framework
         | :D. Also Valence is bit unactive (look commits)
        
           | tomasff wrote:
           | That's why I said "clean room implementation". Any reason why
           | Pumpkin does not build on top of Valence? Would be great to
           | see a more cohesive ecosystem for Minecraft servers in the
           | rust community rather than reinventing the wheel
        
       | Imustaskforhelp wrote:
       | As someone who knew about this project from earlier (I had even
       | joined their discord) (currently have just deleted my discord
       | account for better state of mind) Its really made me happy that
       | hackernews really liked this project (140 upvotes is pretty good
       | in my opinion)
       | 
       | From what I remember , there was one other server as well which
       | also was written in rust but I am not exactly sure
       | 
       | Also , the last time I was at it , it was really really alpha
       | software but it was getting developed at good rate , so I am not
       | sure about its current state (I was there when the author had
       | gone to take his exams IIRC)
        
         | alex_medvedev wrote:
         | Hi. Im so happy there are so many people liking the project,
         | The Project is still pretty WIP but im really working hard on
         | this, i finished my exmans last week and currently in holidays
         | so commits are again back to normal :D
        
         | compootr wrote:
         | Maybe it's cuberite? written in C I believe
        
       | InMice wrote:
       | I will give it a try, Thanks for this project. The performance of
       | pure vanilla server jar is so bad. Thats one thing I wish mojang
       | would improve. I know new chunk generation is multithread at
       | least. I also wish they'd officially support some basic control
       | for SMP servers. Something as basic as areas defined by two
       | corner coordinates and basic permissions like place, break,
       | interact. Just a basic config file is fine I can manage the
       | requests/updates ot it using other tools - or a simple
       | commandline utilities in game to ops. Something that lets me not
       | have to always only use an excluse whitelist. I know
       | Paper/waterfall and the others have plugsins for this but theres
       | just something nice about staying pure vanilla. Ive been keep
       | servers alive for a long time now.
        
         | alex_medvedev wrote:
         | Hey, Im happy you want to try it out just keep in mind its not
         | done yet many features are missing, We want to have all the
         | things you listed be configurable in a config file, so i think
         | you will like it. If you have any problems may worth to take a
         | look at
         | https://snowiiii.github.io/Pumpkin/troubleshooting/common_is...
         | or just ask for help on our discord, Have fun :D
        
         | dleink wrote:
         | thank you for your service
        
       | SquareWheel wrote:
       | The performance differences look pretty impressive from the
       | benchmarks. I do notice that world generation and saving features
       | are missing though, and these tend to be pretty expensive
       | operations. Chunk gen especially can bring a weaker VPS to its
       | knees. I'm sure the benchmarks were taken at an idle state, but
       | I'd be curious to see how it compares once those features are
       | included and being used.
       | 
       | I don't see it listed, but is there support for block
       | breaking/placing yet? Presumably this would require light
       | recalculation and a chunk update on the server.
       | 
       | Finally, do you plan to add advanced features like scoreboard,
       | teams, or command block parsing in general? Mojang has at least
       | open-sourced Brigadier for that.
       | 
       | Cool project. Hope to see it mature to the point of making
       | servers easier to run on low-end hardware.
        
         | alex_medvedev wrote:
         | Hey. Im impressed with the benchmarks myself tbh.
         | 
         | Yep block placing and breaking is already supported, but light
         | currently don't so everything is dark :/, We are working on it.
         | Yep, We want to add all cool features like scoreboards, teams
         | and we already have a API which is similar to use to Brigadier
         | for our Commands.
         | 
         | Thanks, I would love to give players on low-end hardware the
         | possibility to host servers. I think i may test Pumpkin on a
         | raspberry PI or something one day
        
           | SquareWheel wrote:
           | I remember Notch talking about the lighting calculations
           | being one of the hardest parts to program, so I can
           | understand that being a challenge.
           | 
           | Mojang made large improvements to the lighting engine in
           | 1.20, bringing it in line with the performance mods
           | Phosphor[1] and Starlight[2]. Despite being deprecated now,
           | they might still offer some useful insight into how to
           | approach such a system in a performant way. You'll need to be
           | mindful of the licenses, but it's likely easier than reverse-
           | engineering Minecraft (even with mappings).
           | 
           | [1] https://github.com/CaffeineMC/phosphor-fabric
           | 
           | [2] https://github.com/PaperMC/Starlight
        
             | alex_medvedev wrote:
             | Will definitely take a look at this, Thank you. Im btw
             | studied the Minecraft code already so i often use the
             | decompiled code as reference.
        
         | kaylynb wrote:
         | Chunk gen makes sense to implement last or never. If you want a
         | performant Minecraft server you need to pregen all the chunks
         | anyway. You can still later regen chunks that have never been
         | visited to get new chunkgen on updates since chunks store the
         | inhabited time.
         | 
         | I think Minecraft server re-implementations are pretty neat and
         | I like to see when a new one comes out. There are also specific
         | purpose server impls like MCHPRS for doing fast redstone
         | compilation for technical minecraft.
        
       | zellyn wrote:
       | How does this compare to Dragonfly (IIUC, basically the same
       | thing, but in Go)? https://github.com/df-mc/dragonfly
        
         | mjtlittle wrote:
         | This looks like its for java while dragonfly seems to be for
         | bedrock
        
           | alex_medvedev wrote:
           | Your right
        
       | kamlaserbeam wrote:
       | Just to be clear this sever only works with the current vanilla
       | version of Minecraft? I've been interested in playing again, but
       | on the older Beta builds (1.7.3) prior to the full release
       | versions. These versions aren't supported are they?
        
       | dartos wrote:
       | Just waiting for Minecraft to be so reverse engineered as to be
       | its own protocol with multiple server and client implementations
       | that just work.
        
         | str3wer wrote:
         | it already is, the entire protocol is reverse engineered, there
         | are tools to automatically deobfuscate the code and there is
         | already a full reimplementation of minecraft that also supports
         | servers
        
           | INTPenis wrote:
           | Does that mean there are open source clients that can connect
           | to servers without a microsoft account?
        
             | beeboobaa3 wrote:
             | the client has to authenticate with a central server and
             | present a ticket to the server it wants to connect to.
             | otherwise clients could impersonate each other easily.
        
           | Cyberdog wrote:
           | If that's the case, how come nobody seems to be writing
           | improved Minecraft _clients?_
           | 
           | Ever since I started playing it in the beta days I've been
           | frustrated with how poorly Minecraft performs relative to
           | what it's showing on the screen. (Not that that stopped me
           | from pouring hundreds of hours into the damn thing.)
        
             | imtringued wrote:
             | Yeah, it was always weird how 32x32x48 extreme reactors
             | lagged the game whenever you looked at them, but the moment
             | you looked away everything was fine.
        
       ___________________________________________________________________
       (page generated 2024-10-15 23:00 UTC)