Using GitHub Patchsets to Mod Pumpkin

[spiral panther]

This thread is the result of a chat in #general . The observation comes from Pumpkin's website saying that Pumpkin has a Comprehensive Developer API, while other Minecraft server software don't.

This idea does not refer to modding minecraft, or adding support to Fabric and Forge. **But modding the server itself, modding Pumpkin's internal logic. **

Apparently, it's not possible to mod program developed in Rust. So this suggestion is about discussing about the concept of patches. Patches would be "mods applied to pumpkin at compile time", it wouldn't be meant to replace plugins, it's meant to prevent forking. Instead of shattering a community by forks, like what happened with Bukkit/spigot/paper, we could give the advantage of forking to "patches". That way, we could still be able to build great things around the same big project: Pumpkin; instead of being in a situation where everyone fork pumpkin.

For example, a fork would be able to

• reimplement different part of Pumpkin, like change Entities' AI behaviors, or make changes to the files in the assets folder.
• Forks like purpur (disabling or customizing a lot of minecraft's default behavior via config files) could be a patch.
• Minigame servers could be able to stop/delete behaviors they don't need without forking the whole thing (natural mob spawning, world generation, nether and the end dimension, disabling block placement without overusing events to block them)

It would also solve a problem we have: there's a lot of suggestions people make on this server that relies on internal logic, and it doesn't make sense to make this feature accessible from the plugin API. For example, the ability to customize the knockbacks for pvp servers, it wouldn't be a good idea to make knockback customizable from the plugin api because multiple plugin would be able to change it and cause conflict. And reacting to events to add or remove knockbacks has a performance impact. It could be handled via a "patch".

Modding Pumpkin itself

@minor sandal @primal void

[primal void]

I suppose, if Pumpkin were made much more modular and each individual thing was built as a library, it would be possible to dynamically load the library for each feature. These could then be substituted for modded implementations which would change the behaviour and work a bit like mixins.

But this would probably add a large runtime cost.

[limpid plover]

”Mods” can probably just be patchsets for versions. Iirc we plan to have maint branches for released versions, so mods could just make a patchset that adds some feature to that version. Then the patchset would be updated for each release like in vanilla

[spiral panther]

what do you mean by patchsets ?

[limpid plover]

Git patchsets

[primal void]

You can run git diff and pipe it to a file, then apply that patchset

[minor sandal]

you cant really make it a lib, because while the output is a dynamic library, it still uses the c abi, and since that does not have generics, rust uses a workaround, so if the library is replaced by another one that has the same pub interface (from the rust perspective), it does not necessairly mean it will work

[primal void]

then compile to apply

[limpid plover]

Its the same as a diff, but in a file, so you can git apply ”mod.ps”

[primal void]

that's true, didn't think of that

[spiral panther]

ohhhhh yeah... But it's just a soft fork then

[primal void]

Kind of. But you can take parts from multiple different forks

[limpid plover]

Not really, its basically mixins in git

[minor sandal]

yeah, but one where the ecosystem is not fragmented

[primal void]

Basically, it's composition rather than inheritance (I guess is an analogy?)

[limpid plover]

So a mod could consist of client side forge and pumpkin ps. But keep in mind also that most mods people use are performance mods, and those can be done directly in pumpkin as improvements instead of mods.

[primal void]

I think patches are the best option. They allow you to pick and choose multiple changesets you want to install, while also making it really easy to implement them into Pumpkin itself if Alex decides to do that.

[hoary pewter]

We should aim to make the plugin api be able to cover all situations instead

[primal void]

Yes definitely. But I guess improvements to the plugin API could first be implemented as patches

[limpid plover]

Yeah, opening access to register blocks and items would go a long way.

[hoary pewter]

Ye definitely

[primal void]

In other words, if you see something you need in the plugin API, you could first add it with a patch / changeset, then it could later be implemented into the core pumpkin api

[limpid plover]

The extractor supports forge (??) mods i think, so any mods that are written in clientside can be loaded in extractor and run, and put data in pumpkin, so then you can add the impl in the plugin.

[limpid plover]

Isnt that what a PR is?

[spiral panther]

i don't understand why you guys talk about forge

[limpid plover]

Just as an example. But iirc the extractor uses forge or neoforge

[primal void]

Yeah basically, you just can make a fork and submit it as a PR

But if you have something that can't possibly be modified with plugins, you could download multiple different patches and apply them all (instead of having to choose a fork which only had one of the features you needed)

[spiral panther]

I think there are situations where things shouldn't be part of the pluginAPI, I gave example for the knockbacks. But even entity AIs, I don't think it's a good idea to let plugin reimplement it, while patching pumpkin's core feels better.

I will soon try to work on a PoC of a minecraft minigame made with pumpkin instead of paper, there are features that will not be needed, and disabling them via forking pumpkin is nicer than using events to cancel them imo.

But I understand that it's not a concept that's not attractive for everyone

[limpid plover]

I mean, we could just give access to removing from the managers, if i understood your problem correctly.

[primal void]

That's true. I wonder if, once the plugin api is stable, Pumpkin should move towards implementing features through plugins instead of the core.

That way, it could also be used to accomplish tasks similar to Minestom where you don't need all the vanilla behaviour.

For example, you could have a 'pumpkin_entity_spawn' plugin. If the API is written well enough, this could be just as performant as implementing it into the base.
Or at least it would be nice to modularise Pumpkin more so you could choose what functionality you wanted through cargo features or something.

[kind steeple]

If rust had inheritance, modding would be much easier

[primal void]

Maybe, but I feel traits mostly make up for this

[kind steeple]

At that point you're just remaking valence

[primal void]

Oh wow, never heard of Valence, looks cool but isn't actively maintained like pumpkin is.

[kind steeple]

Mostly, but they don't work for everything

[minor sandal]

dyn Trait replaces everything that would help you with modding, while avoiding the hell of inheritance

[trim hollow]

that would absolutely tank perfomance

[primal void]

I'm not sure it would be too bad as, if no plugin was registered to listen to the events, those events could just be ignored.
I don't know, I feel even if it does lower performance a bit, it would be worth it as a server software without good plugin support wouldn't be great for most servers.

[hoary pewter]

Ye, only issue is that the overhead with dynamics is a lot

[minor sandal]

its just a table lookup?

[hoary pewter]

Ye, but it puts an unsized constraint on everything

[minor sandal]

thats so that the vtable can be constructed, otherwise its impossible to do from the language side

and when you use the virtual keyword in cpp, you also use vtables

[hoary pewter]

Ye

[radiant escarp]

if you are not able to do this id prob end up forking

which i feel will become a trend in others finding pumpkin

[hoary pewter]

Don’t worry

All inventory code uses dynamics

But I guess it shouldn’t be too hard to use in Player and so on

And we can always use boxed structs if we want sized

Hard part is that all logic would have to be traits tho

[minor sandal]

i dont see how inheritence would solve this tho

you have the same constraints in cpp

[hoary pewter]

It wouldn’t

[minor sandal]

oh

nvm then

[hoary pewter]

Issue is that if you just want to change a small thing you have to copy the whole trait

Which is not ideal

[minor sandal]

wdym?

[hoary pewter]

If you want to change knock back behavior you need to copy the whole trait including vanilla knock back code

And for small changes that’s not ideal

Like changing a variable

[minor sandal]

ohhh thats what you mean

hmm

unless you roll your own vtable

^ dont btw

[hoary pewter]

I think it’s best to try to have a good plugin API

And core changes would need to be forks

Cause there’s no middle ground that isn’t super inefficient or not customizable enough

[minor sandal]

you can use what @primal void proposed before, using git diffs and requiring the user to recompile manually when you use mixins

[hoary pewter]

Ye I guess, I don’t see any major mod that would require mixins though

[minor sandal]

wdym

[hoary pewter]

What features would absolute source control be able to provide that a plugin can’t

Apart from niche uses were a fork can be made

[minor sandal]

the feature is that you dont need to make it a fork, which also means you can have many mixins applied from different sources, while you cant really merge forks together (unless you do a manual git merge)

[minor sandal]

btw heres how (dont do this tho)

[primal void]

What window manager is that? Sway? I3?

[minor sandal]

hyprland

[primal void]

Oh yeah. I tried hyprland but it just seemed a little more complicated than I needed it to be 🙂
I'm happy with i3 and sway for now but maybe I'll switch sometime!

[minor sandal]

i was considering sway instead, but sway prob wont get a lot of updates, and i cant really be bothered to do another setup lol

[primal void]

That's true. I3 seemed to do the job, then when I needed Wayland, sway was just a drop in replacement for me!

[minor sandal]

yeah its really cool therse a drop in replacement while im out here stuck on wayland lol

[trim hollow]

i was going to benchmark plugin events but rust is so painfully slow idk if i can do it 😭

[minor sandal]

blazingly slow ⚡

[trim hollow]

its faster to check errors by doing cargo build than waiting for cargo check

[primal void]

Compile times are painfully slow if you don't have the latest Ryzen cpu!!

[minor sandal]

that doesnt seem normal

[primal void]

Cargo check is just cargo build with fewer steps, so not sure how that works :/

[hoary pewter]

In my understanding mixins are used mostly client side anyways

[primal void]

True, I'm not sure they're really necessary if you have a good events API.

[hoary pewter]

Ye

I’m all for opening up registries, but not sure if mixins are possible

[primal void]

That said, it would be nice if there was a way to modify the "vanilla" pumpkin behaviour

[limpid plover]

Would be technically possible to deregister the vanilla block and register a new one.

[minor sandal]

alex wants to support common use cases, so that its possible to do this by changing the config

[primal void]

It would be, though it would almost definitely need recompiling.

[hoary pewter]

Ye

[limpid plover]

Only the plugin in that case, which would need to anyway?

[primal void]

Oh, I thought you meant that could be done by modifying the main Pumpkin source code

[limpid plover]

Nah, i mean we could add support for deregistering handelers through plugin api

[primal void]

Oh yeah, absolutely!

[limpid plover]

The only problem is if multiple plugins do that, they will probably end up overwriting eachother, which is not good. But ig the same is true for java mods

[bronze crater]

🤓☝️Actually, mixins allow multiple mods to modify a single function of a class, so they usually don't overwrite each other, so it's (wayyyy) more versatile than just deregistering and registering a modified class

And I've seen multiple real-world cases of that so that's not that hypothetical of a situation

[limpid plover]

Yeah, but what if they overwrite the same parts. The granularity is just different

[bronze crater]

Depends - you usually don't "overwrite" per say, but rather add function calls or change return values, which most of the time doesn't cause conflicts

And this granularity is very useful for mod compatibility haha

[spiral panther]

I've read all the chat. It seems that:

• For some, pluginAPI should cover more behaviors, so that we don't need modding
• For the others, it's not an ideal solution, so you guys discuss about an alternative

Regarding the first one, there are things that (imo) shouldn't be accessible in the pluginAPI. In Bukkit's plugin API events are great because it's unlikely to cause conflicts. There's a priority list for event listeners, which means each listener react one after the other, and the no matter how many listeners cancel an event, only the first cancel it.

Giving plugins the ability to change global things at runtime feels weird to me, let's take the example of knockbacks: what happens if multiple plugins try to change the knockback's default value ?

There are usecases where plugins can't and shouldn't be the answer. And in those cases, people built forks.

Let's take a better example, purpur. It's a paper fork that lets the admin customize a lot of vanilla behavior thanks to config files. Things like "should all players go to sleep to skip the night ?" or "should advancements be broadcasted ?" It would be a nice addition to pumpkin, but it would also bloat its core, maybe it doesn't fit in it, or maybe it answers a really tiny portion of the community and isn't worth the effort. Someone might really need it, and Pumpkin's team has the right to disagree. In those cases, developers should have a way to make those changes to pumpkin without bloating the core.

I wanted to find a pattern that allows us to do all that without forking, Tekno suggested git's patchsets, which seems to be great for maintaining forks, rather than preventing them. Patches could be a way to build PoC for features that would be integrated in the cores, or be the thing that allows everyone to add things in the core without actually bloating it.

Sorry for writing so much

[lilac narwhal]

I havent read Everything, but 1.) patches are esentially what make up a fork of bukkit, so @spiral panther your idea doesn’t seem to be viable, and 2.) the current system doesn’t allow for implementing custom implementation of systems

On the other hand, @minor sandal ‘s implementation does, which, after some reconsiderandon, works by dynamic dispatch

Other solutions would involve ECS and idk how else we could enable custom implementstions without reglection

The most viable solution would be to implement packet wrappers ong

This way we could map to different modding APIs more easily

[spiral panther]

Yup, I've seen lukas's implementation, but 4lve said it would have a performance impact, I feel like there'll never be a "perfect" way of doing it, so it won't happen

[minor sandal]

pls no, i said to please not use this, it was for educational purposes only and seems like a nightmare

[spiral panther]

yeah i saw your warning

that's why i'm saying it will never happen

[limpid plover]

I want to clear up what i meant by patchsets as mods. I did not mean that you should create a branch with the features. That would destroy the point. What i meant was something like this:

1. create a mods folder.
2. gitignore it.
3. add a script that applies all patchsets in that folder. First run the command with --check, to see if it will apply cleanly, or with --3way to add merge conflicts.

So, the patchsets are the mods. They modify the behaviour of pumpkin for a specific version. It never gets commited. That way, they are easy to share, and you don't have to decompile them to check that there are not backdoors like you have to with vanilla mods.

I am not saying that this is a perfect solution, but imo it's the best option considering rust does not allow modding, and the plugin api should not be made so that it hugely affects performance of the vanilla mechanics.

[minor sandal]

i dont see why plugins cant just be zip files which contain the library itself, and a folder with mixins, and when it exists, you need to use some cli to run pumpkin

seems like a bit of work, but also the most intuitive

[primal void]

I guess the main benefit of patchsets is that you can already do them. Just send someone a patchset and they can apply it themselves, no need to change anything about Pumpkin or add mod loading support or anything.

But it would be much better if sometime, we could get an actual mod / mixin loader in Pumpkin, just as you said, it would be a lot more work.

[minor sandal]

thats true, but also no one is using pumpkin yet

[limpid plover]

How would the mixins work though? Rust is compiled to a binary with few ways to tell what is where.

[minor sandal]

mixins dont necessarily have to be put in at runtime, what @primal void proposed, was to make git diff files, which then can be applied to the codebase and recompiled

the goal should be for the plugin api to be large enough for that to not be needed for most people (since recompiling is a pain), but it will be more user friendly than including plugins with the valence approach

[primal void]

the goal should be for the plugin api to be large enough for that to not be needed for most people
Definitely. API support is much better than Mixin hacks!

mixins dont necessarily have to be put in at runtime
In that case, how would it differ from a patchset?

[limpid plover]

So, then we could just combine my idea with plugins, and then we have everything we need.
Plugins for stuff that is possible, as it creates less problems, and patchsets for mixins.
The plugin devs can just distribute both. Instead of putting a zip file, you put 2 files. In plugins/, and in mods/

[minor sandal]

not very much, same thing but included in a plugin

[minor sandal]

why seperate them tho?

[primal void]

They achieve different things

[limpid plover]

Because creating a cli to load them and stuff will just create more problems? Why overcomplicate this?

[primal void]

E.g. plugins are more for event handling and stuff, while mixins change vanilla behaviour in a deeper level

[minor sandal]

i know you understand that, explain that to my 12 yr old cousin

they both modify the game right?

[primal void]

The good thing about patchsets is that they let us try out this system without even using a CLI: just a git patch command. Then if it turns out to be a good idea, we could make a CLI in the future for making it easier.

[limpid plover]

No, plugins add functionality, mods modify existing functionality

[minor sandal]

if you want the plugin api to be extensible, then it also needs to be able to modify it to some degree

[primal void]

While they both change the game,

• Plugins work with the existing game to add functionality, through things like handling events and sending packets and things to players. But if something is hardcoded into Pumpkin, plugins can't really change that.
• Mods on the other hand could be used to change the base game, if the plugin API isn't able to. For example, you could completely change the AI of a skeleton with a mod. That wouldn't be possible with plugins as plugins mainly just listen to and act upon events.

[primal void]

Yes, definitely. But there are some things that will be hardcoded into Pumpkin, and so you would need to directly change Pumpkin's source code to modify this. The plugin API unfortunatly will never be able to do everything

[minor sandal]

i know that, im saying eli5

what is hardcoded? what is an event?

[limpid plover]

Mods are very much more dependant on the source code, while plugins act upon events sent through an api.

An event can be anything, like a player joining, or jumping, or hitting an entity.

[primal void]

• Hardcoded = in the pumpkin code, there are some things that pumpkin just does that plugins can't change. E.g. mob AI.
• An event = ^^^ (@limpid plover explained above)

[minor sandal]

what is an api then, it continues to be an unnecessary spiral

[primal void]

An API is just something that Pumpkin gives plugin developers to allow them to listen to events and things. APIs allow plugins to talk to Pumpkin and tell it what it needs to do after it recieves an event

[minor sandal]

wait i need to find someone and ask them if these explenations are enough

[primal void]

https://www.reddit.com/r/explainlikeimfive/comments/628y0c/eli5_what_is_an_api/

That's not necessarily what Pumpkin is, but it may help somewhat

[minor sandal]

omfg i know what it is

[primal void]

Imagine you are in a restaurant, you can see the menu, and you know the kitchen is making food, but how do you order it? You use the waiter.

The waiter is the API, it takes your request (your order) and takes it to the kitchen (the server) where it is prepared and brought back to you (the meal).

https://www.reddit.com/r/explainlikeimfive/comments/628y0c/comment/dfkpwog/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[limpid plover]

I mean, most server admins should be familiar with the concepts, as mods and plugins have been in the vocabulary of minecraft since before i started playing (1.1 - 1.2). If you want to change the lighting engine in minecraft to something more performant, you don't go looking for plugins.

[minor sandal]

maybe, for me at least it seems unnecessary to divide those two, but sure ig?

[primal void]

If we didn't divide them, you'd have to recompile half of pumpkin from scratch every time you made a change to the project

As mixin-style plugins can't be done with rust -- without recompilation

[limpid plover]

And, you couldnt add plugins without compiling again. That would mean that the distributed binaries would never be able to run plugins

[minor sandal]

you can check if it has mixins, you dont need to do it every time

[minor sandal]

again, its one if statement away

[primal void]

The way you have to add mixins is by recompiling. But plugins you can just add the .so to your plugins folder

[limpid plover]

No it’s not. You cant have a binary modify itself

[minor sandal]

you can check if it has mixins

[primal void]

Exactly, the issue is that plugins can currently be just dragged and dropped into your plugins directory and linked at runtime. As mixins can't be linked at runtime, your plugin would somehow have to download the source code and patch it to compile a new binary while still running the server.

[primal void]

That's not how this would work though: as with patchsets, mixins would need to be compiled completely differently, while plugins could just be linked at runtime.

Pumpkin could check if a plugin contained mixins, but as Pumpkin is already compiled, it wouldn't be able to do anything about it as it would need to recompile Pumpkin to apply the mixins.

[minor sandal]

my biggest problem is that mixins in mods are usually not used for the core logic, they are tiny patches which interact with the rest of the code, so then you might need plugins which need certain mods, or you need to have mods which are actually also plugins

which becomes confusing

[limpid plover]

How is it confusing? You would just have two parts that you put in different folders. If you want to install mods in vanilla you usually first have to add a modloader, then a mod API, and then the mod. How is that less confusing?

[primal void]

You should almost never need patches, unless your server is particularly different and custom.

In general, plugins are fine.

But mixins can be released, used and then merged into the main Pumpkin when stable.

[spiral panther]

i do agree naming have an impact on how people will perceive the difference in plugins and mods. Both plugins and mods are terms already used in minecraft community. Plugins in Pumpkin have the same purpose and work the same as plugins in spigot/bukkit. But mods work differently as the ones in fabric and forge (if we take the example of teknosom's proposition)

Calling them "mods" and placing them in a "mod folder" would confuse people, while patches are pretty selfexplainatory, they patch the server itself, there's no mod loader when applying patches for photoshop cracks or stuff like that

[minor sandal]

ok tbh maybe thats what made me dislike this, thanks for pointing it out

[limpid plover]

But… the patches would be used to mod(ify) the server? So how is it bad naming?

[spiral panther]

cuz they'll think it's a new modding api and will compare it to fabric and forge

[primal void]

I think patches is a better name than mods, you're right.

[spiral panther]

i can already see KasaiSora saying "a new minecraft server software appeared, they support both plugins and mods, but not compatible with forge and fabric ! they have their own mods, and we can't even create blocks with it" like it's a different purpose and it's confusing

[limpid plover]

I mean imo, mods are a better name for them, but it does not really matter. As long as we can agree that this is a good solution.

[spiral panther]

i agree that it's a good solution

[minor sandal]

im fine with it

[minor sandal]

polls outside of #polls are useless

they never get more than 5 votes

[primal void]

This mostly concerns just this thread though, so I think it's fine

Most people in #polls wouldn't have a clue what we're talking about 😂

[minor sandal]

for the time being, but most people also dont know this thread exists

[primal void]

True, but do we wan't people who don't know what this is even about voting?

[spiral panther]

tho i don't really see how the code in the "mods folder" would be able to change pumpkin's behavior, since it's not called in pumpkin's codebase

[minor sandal]

for the name? why not

[minor sandal]

theyre git patches

to the source itself

[limpid plover]

Run a script that checks collisions and applies

[primal void]

Yeah you'd need to have some sort of CLI tool to apply them (or just teach server owners how to use git patch

[limpid plover]

A ”mod loader”

[primal void]

They may not understand how patches work, and see them similar to Fabric's runtime-linked mixins (which they're quite different to)

[primal void]

Basically, a patcher and compiler

I guess

[minor sandal]

yeah ig, but it also shows how other people think

[spiral panther]

I don't understand how can changes to a codebase can be placed in a mod folder

basically you make changes to pumpkin's codebase in a patchset, you can "download" that patch and put it in a folder that's ignored when you commit, and when you compile pumpkin git knows it should patch the codebase with the patch ?

[primal void]

Yes, this wouldn't work. You can't just have a patches / mods folder that changes the source code, without also baking in some sort of recompiler into the server binary itself (which is a bad idea)

[spiral panther]

i'm coming from the web development world, never heard of git patches, i'm sorry

[primal void]

So you'd need to run a separate tool which patched and built a new, different binary

[primal void]

They're basically just change sets to code, so you can run a command and, say, change a feature in a function

[limpid plover]

They are the same things as commits, just in a file instead of version history

[spiral panther]

ohhhh

okok

that sounds great and it seems like it doesn't require efforts/a lot of changes to the codebase

[primal void]

Yeah, you just run one command and then rebuild

.... unless you have to deal with merge conflicts... 🙁

[spiral panther]

i mean in that case that's on the "patch maker" 's responsibility

[limpid plover]

Yeah, right now, popular (vanilla) mods already make an effort to be compatible with mods in the same area

[spiral panther]

It would be great if someone could sum up tekno's proposition so that alex doesn't have to read the 215 messages we exchanged, so that we get his opinion on the topic

i'll do it when i come back home tomorrow if no one is able to

[primal void]

Sure, I'll get to that after I've documented some more of the codebase!

[spiral panther]

nice ^^

[limpid plover]

We could also make a draft pr with the proposed script and folder

[primal void]

I mean, I don't think we need to actually do anything? We can just run git patch and compile the project. I guess in the future we could have a CLI tool, but I think it's just as simple as running a git patch and then cargo run, no?

[spiral panther]

i used my whole lunch break to talk about pumpkin 😢 going back to work...

[primal void]

And distribute the patch files

[primal void]

Oh no!

[limpid plover]

That would not check for collisions though. So imo we could add a bash script that checks and applies. Its only like 2-3 lines, so not very complicated

[spiral panther]

i was just realizing that patches could be very powerful for anticheats

see you guys ^^

[primal void]

It wouldn't, so obviously a CLI tool / simple bash would be nice. I just mean that we could technically already use this method of mixins.

[hoary pewter]

Patches should be their own things. Pumpkin plugins should also support modded clients

[spiral panther]

what do you mean by "Pumpkin plugins should also support modded clients" ?

[hoary pewter]

Pumpkin plugins should be able to create custom blocks so it can work together with neoforge

And so on

[spiral panther]

oh

that would be great

but it's a different topic

both neoforge and fabric mods can create new blocks dynamically.

Pumpkin could send a json that describe blocks (their hardness, the took to break it, its texture in base64), and the neoforge or fabric mods could use it to register them on their end.

But I don't know how to make pumpkin support already existing mods

that's how a block looks like in the blocks.json file, i think it gives you what information minecraft mods need to make a proper block

[primal void]

I don't think Pumpkin will really ever get to the stage where it can function as a Fabric/Neoforge/other modded server. You'd need to be able to load jar files as mods, and at that point you might as well just use Fabric/Neoforge

Any sort of client-mod support would mean that Pumpkin needed to support the Fabric/neoforge api

[hoary pewter]

No, not jar files, you have to rewrite the plugin but server sided

[primal void]

True, but would any mod developer actually do that?

[kind steeple]

Well if we provided a good enough framework, it might be possible to rewrite or port the plugins to pumpkin, but it will be hard to do since rust isn't made for that

[hoary pewter]

Not sure

[kind steeple]

Depends if pumpkin catches on

[primal void]

Maybe one day we'll have pumpkin-client 😂

[kind steeple]

xD

Like, it wouldn't be bad to rewrite the client as well, it's design isn't much better than the server's

And realistically we can reuse pumpkin's existing networking and packet stack, just swapping which are sent and received, so realistically we'd mostly just be writing the rendering engine and a couple UIs and interactions

Like I'm not saying it would be easy, but it wouldn't be impossible

[primal void]

True, actually. I mean, people make optimised 'Minecraft clones' all the time in a short period, so maybe it would be possible. Difficult to implement all the animations, client-side prediction, etc. though.

[kind steeple]

Yeah, but you don't need most of that for just the basic game itself

[primal void]

Lots of plugins (e.g. SimpleVoiceChat) work by interacting with client-side mods. So if people would have to rewrite anyway, they could probably rewrite their Fabric mod into a Pumpkin plugin and have the plugin interact with the client-side mod.

So I don't know if it's worth making a new API for this or just improving the existing one.

[hoary pewter]

What do you mean? That’s what im suggesting?

[primal void]

Oh, I thought you were suggesting making a new API for interacting with client-side mods.

[spiral panther]

it's pretty unrealistic to think that mod developers (who are already bothered by the stupid amount of mod loaders they have to support) will make a rust port for pumpkin, no matter how much popular it gets.

If you truly want the mod community to consider pumpkin, you need to make the first path towards them. Porting a mod to pumpkin requires to learn a new programming language (rust), rewrite your whole mod for pumpkin and ensure feature parity (since the client needs to be compatible with the server mod you're talking of) and maintain it.

I think if you want pumpkin to be compatible with mods, you have no choice but to make a transition layers between pumpkin and the mod loader you want. And this will be hard without source code access. Happily, there are open source mod loaders, fabric for example.

It wouldn't have a big performance impact since the java code would call fabric API that will call pumpkin's internal API, so at the end of the day it's rust code that runs.

https://github.com/giovanniberti/robusta

fabric itself is open source, but the minecraft mapping they used is open source too. It should be very helpful in that regard

[trim hollow]

its not possible

most mods use mixins, which we've already established arent really possible in rust, and even if they were, theres no way to reliably translate some arbitrary vanilla mixin to pumpkin's codebase

also mods can achieve the same thing in different ways, no gurantee that translating fabric api calls will cover a mod

[spiral panther]

I'm not very interested in that, it's a lot of work, and it makes sense for fabric modding community to use fabric for servers, can't compete with that. What I was implying is that you should run a jvm that runs fabric and its mod loader, and use the mapping to make a transition layer with some kind of interoperability. Which is a lot of work.

[trim hollow]

its not possible

[spiral panther]

expecting modders to make a rust port is unrealistic

[trim hollow]

yes but its possible

possible > impossible

[spiral panther]

possible but no one uses it is the same as impossible, gg you got a great piece of tech but no one uses it

[trim hollow]

if you want pumpkin to be some ace of all trades, its guranteed to fail

the scope is way too big

[spiral panther]

that's not my goal, i was giving my opinion on 4lve's messages

[trim hollow]

my point is, pumpkin will never support vanilla mods and thats ok

[spiral panther]

and I agree with that !

I do think though that you can create a mod that allows plugins to create new custom blocks, like a client side receptor for server modding

that would be great

but that's something different

[primal void]

As you can mind of add custom blocks through Bukkit plugins and texture packs/ (through different block states) it would be nice maybe if Pumpkin implemented something like that! Not sure if it's possible with the current design of things, though.

[trim hollow]

that would be another huge feature that bloats pumpkin

if someone wanta to implement polymer as a pumpkin plugin, go ahead ig

but please dont make it part of pumpkin

[primal void]

To be fair, it's not actually much bloat. It's just the ability to change the block state or something

I did it with Bukkit before, can't remember exactly what it's called though

[limpid plover]

I’m pretty sure you can already implement custom blocks as easily as vanilla blocks

[trim hollow]

cant we just focus on implementing vanilla first

no one will use pumpkin if it has lots of cool features but all of them are unfinished and buggy

[primal void]

I'd generally agree we shouldn't be focusing on proper mod / mixin support, which is why I think the git patch system works quite well. As they can later be implemented into pumpkin if it fits the project.

[spiral panther]

could be a patch tho ^^

Using GitHub Patchsets to Mod Pumpkin

[primal void]

I will say that this git patchsets thing is definitely not the best solution. It will probably cause lots of issues. But for now, as it's incredibly easy to set up, I think it's the best choice.

[trim hollow]

there could be a system like mixins to prevent conflicts, but it'd only work on source code

maybe, if you have 10 years of rust experience, understand how cpus work, and have a year to spare, you could figure out a way to mixin compiled native code

[primal void]

I don't think it's really worth it... at least for now!

But maybe at some point in the future, we'll realise we'd missed something and there's an obvious solution :D

[spiral panther]

Surprisingly I like this solution, it's like sharable little forks

I wish we could do modding at runtime, but we can't get everything I guess

It also prevents people to use modding for everything when plugins are enough (99% of use cases)

[wide bone]

I might absolutely be wrong, but including debug informations in the binary (e.g. the address of each and every function and variable) would allow mixins, no? However, if I am right and Rust does not have a stable ABI, this is yet another problem to solve
(Excuse me for my absolutely terrible English ^^)
EDIT - It's not a good idea, Rust's ABI is unstable, plus most ISA don't care about variables to use memory adresses and registers instead, so trying to do it would probably (certainly) result in an undefined behaviour

[primal void]

Well this one got 6, so you were wrong 😂

[minor sandal]

thats because i mentioned the rule

therefore it must be broken

if the rule is kept silent, it does function

[spiral panther]

Suggestion: Using Git Patchsets to mod pumpkin

What observations led to this suggestion ?

• The desire to mod pumpkin
• Prevent Pumpkin to follow Bukkit's fate of forking hell cycle (bukkit > spigot > paper > pufferfish > purpurmc > leafmc)

Why is there a need for modding/ why aren't plugins enough ?
First, I want to empasize on the fact that we're not referring to supporting Fabric and Forge (client-side modding) on Pumpkin. We're talking about modding pumpkin itself, its internal logic.

There are two reasons why people made forks regarding the bukkit ecosystem:

• Performance (spigot, paper, leafmc)
• Specialized forks (purpurmc, pufferfish, tacospigot)

Pumpkin prioritizes vanilla feature parity, but it's not the case for everyone, one could argue they need mobAI, but not as powerful as vanilla, and implement some AI that's simpler and less performance hungry.

Regarding specialized forks, people made them because implementing their feature in the original project would bloat it. PurpurMC is a fork that lets admins fine tune their server via config files (for example, they can disable achievements broadcasting, or disable water in the end dimension completely). Since Purpur is pretty popular, you can see that there was a need for that, and it could be part of paper, but it doesn't fit in their vision, it would bloat it.

The goal here would be to give developers enough control on internal logic, without bloating the core, and without encouraging a forking hell cycle.

But it's also worth saying that everything shouldn't be part of the pluginAPI. Anything global, such as knockbacks, could be accessed from multiple plugins. What happens if multiple plugins modify the default knockback value ? Which plugin takes priority ? It could cause conflicts.

Why patches instead of mods ?/ What are patches
Cuz modding is not possible in rust, so the idea of patches is to save changes made to the codebase, in a sharable way, so that we all build around pumpkin instead of forking it and creating different projects

And I kind of like the idea that you have to compile pumpkin to mod it, as I said we're addressing really tiny usecases that's not in the scope of plugins, handling modding at runtime make it too easy to make drastic changes to the internals of pumpkin, and might cause more issues than benefits.

[spiral panther]

@solid oriole sorry for the ping, but i wrote that whole thing so that you could give your advice on patches without having to read the whole conversation

[lilac narwhal]

For the knockback thing: I will add the ability to change knockback per player once the plugin api provider thing works

[spiral panther]

i still don't think it's a good thing but ok...

I mean, I see the purpose

[hoary pewter]

What about feature flags for plugins?

Choose between performance and plugin compatibility

[solid oriole]

I have nothing against people making patches 😄

also supporting Fabric and Forge would theoretically be possible since these mods communicate via packets

but at least the Server side mod would have to be desgined for Pumpkin them

[lilac narwhal]

How would patch-sets be distributed? Like github repos? And how is compatibility between conflicting patches handled? Is that all up to the dev?

[kind steeple]

Conflicts would be a huge pain

Hey here's an idea, what if someone made like compile-time mixins

Like it would work on the same principle as mixins, it would just be done at compile time (which does mean that you'd have to recompile each time you want to add something, but it would actually achieve the goal that we're aiming for)

[limpid plover]

You can distrubute them like you usually distrubute mods. They are just files. remember when i helped with the macros? Those were patchsets.

So, conflicts would probably be a small issue. Most mods will probably not conflict, and if they do, it can either be raised as an issue to patch devs, or the server admin could resolve it themselves. Most server admins of bigger servers will probably want to be able to do that anyways.

[spiral panther]

you can download them, it's a .patch file that you can apply thanks to git cli if i'm not mistaken

[spiral panther]

how would that work ?

[lilac narwhal]

Yeah I’m just confused like

If you want to apply multiple patches

That target the same internal server files

Is there some way to determine the ideal load order

[limpid plover]

I think we can create a makefile so that we would have a ServerStart that checks for conflicts between patches, applies, builds, unapplies, and runs the compiled bin.

[lilac narwhal]

Like a system that tries every possible combination until it compiles 💀💀💀

Also, is there a way for github actions to fetch the latest version of pumpkin and check if the patch file can be applied?

[spiral panther]

from 5min compile time to 7hrs, nice idea lol

[lilac narwhal]

No I think it’s very easy to check if a patch can be applied (because it doesn’t need to be compiled)

It takes like 2 seconds

But idk how one would automate that

[spiral panther]

i never worked with github actions, can't say

[kind steeple]

Well mixins work by changing or overwriting methods during runtime (so basically it's injecting code into the JVM), this would do the same except during compile time

[limpid plover]

I don't think order should matter much. It will probably be the same ammount of conflicts either way.

There are:
git apply -3 patches/.ps - Will create merge conflicts that you can manually solve
git apply --check patches/.ps - Will check if the patches will apply cleanly

[lilac narwhal]

Oh I just always did git apply patch.ps lol

[spiral panther]

oh ok, but how does that differ from patchsets ? I guess patchsets would be able to change code, like even a variable, while mixins can overwrite whole methods ?

[lilac narwhal]

And it told me if it didn’t work automatically

But ig order actually does matter

In the same way the order of merged commits to upstream matters

[trim hollow]

mixins have very specific rules to satisfy the jvm and prevent conflicts

[limpid plover]

Yeah, but if you have patchsets that are based on a pumpkin version, then all patches will apply cleanly on source. But if you check then, you will see if the patches themselves will conflict

[trim hollow]

some of those rules can be ignored since source code isnt hard to target (as compared to bytecode)

but there still need to be compat considerations

for example, directly modifying a line should always be discouraged

[lilac narwhal]

Ohhhh I didn’t know such an approach is possible

[trim hollow]

or overwriting a method

[lilac narwhal]

But what happens if the patch would apply on an update version normally, but the baked in versioning presents the patch from being applied?

[lilac narwhal]

Is that a thing?

Like if nothing in the affected file changed between commits

[kind steeple]

Patchsets could also achieve the same thing, but a bit differently and I'd say they're more prone to merge conflicts. With patchsets you're modifying the source code and saving only the changes without any context. If two mods try to change the same code, you run into a conflict, since git doesn't know how to handle these two changes at once. With mixins, it's more like hey, find the tick method, and add a call to one of my methods, which is stored in a separate file somewhere. Because of these very specific rules (add line before/after, remove function call, overwrite, etc.) it's much easier for the computer to automatically resolve the same area being changed by multiple mods

[limpid plover]

Yeah, patchsets are version agnostic as long as the file in source does not change, but the further it goes from when it was written, the more chance for conflicts. But The patch devs will have a pretty easy time updating and checking, so should be pretty easy to have a webhook on new pumpkin version, and check for conflicts.

[limpid plover]

You can also do the same with patchsets, you can add a new file with the patch logic that will remain over versions, and just have one line calls. Which will avoid most conflicts. So it will just be up to the devs to learn how to best work with patches.

[spiral panther]

so the debate here is: do we use git, or our own system, to basically make the same thing, inject code in the source code at compile time

[limpid plover]

Our system can just wrap git

[kind steeple]

Well not entirely, I'm quite sure that if you have two patches that both add some different line after the same line in the original source, git will flag that as a merge conflict

[limpid plover]

Yeah, probably. I think the managers for pumpkin_block has had that a few times. Will see if there is a way to do optimistic merging.

[spiral panther]

i just fear that it will add complexity and needs for maintenance, while the idea was to find a pattern to mod pumpkin without adding weight on the main contributor's shoulders

if it's just git patches, no one else than the patch dev will have to manage it, if we do our system, it's our responsibility to maintain it with alongside pumpkin so that the tool continues to work

[limpid plover]

I mean the tool i have been thinking of is just 3-4 lines in a bash or make file. So i can make a POC tonight to show how that would work.

[spiral panther]

i'd be glad to see 🙂

[kind steeple]

Also you've got to admit that having something like

#[inject(target = "pumpkin::entity::player::Player::tick", at = "HEAD")]
fn my_mod_player_tick_mixin(self: &Arc<Player>, server: &Server) {
    // This code will be inserted at the very beginning of the PlayerEntity's tick method.
    println!("My Mod: Player {} is ticking!", self.gameprofile.id);

    // You could also call your own custom functions here.
    my_mod::player_events::on_player_tick(self, world);
}

Would be cool

[limpid plover]

Yeah, very cool, would be a good option if it's possible in rust.

[kind steeple]

Yeah, that would be the hard part, but rust's macros are quite powerful, I'd be willing to bet it would be possible in some way or another

[spiral panther]

that would be great ngl

[wide bone]

That's definitely very cool to write

It looks a lot like Fabric/Forge mixins'

[limpid plover]

Here's a patchset (😢 ) for the demo:

[kind steeple]

Imma try and make a poc for this. Anyone got any good name ideas?

[limpid plover]

You mean for the mixins? Maybe ”Pumpkin seed”?

[kind steeple]

That sounds interesting, thanks!

[spiral panther]

omg...

[limpid plover]

So then we will have Pumpkin Seeds and Pumpkin Patches 🤔

[kind steeple]

Good question, might be a while

[radiant escarp]

https://tenor.com/view/writing-fire-gif-523038869044733220

[sick trellis]

I was here when this legendary idea was born. Holy crap that sounds good

[serene lichen]

Huh

[radiant escarp]

is this still gonna happen ?

[trim hollow]

it doesnt really matter, its far future

[lilac narwhal]

I don‘t really know about that

Shouldn‘t bee too hard