Hello to all,

I was going to make a post under modder support, but after some consideration, this seemed like a better call. Apologies if this post does not belong here though.

To start, I am fully willing to admit I am way in over my head here, so if someone wants to just point me in the right direction in order to actually start doing things properly rather than trying to fix this mess I created, I understand and appreciate it.

If you have any suggestions, I would grateful to hear them! Thank you for your time!

Basically, I am working on a modpack for some friends of mine and myself which I plan to make very difficult, but hopefully not too tedious. One of the ways that I intend to do that is by adding backpacks that are small. I found the mod "Useful Backpacks" by U Team and it seemed great, but the backpacks were just too big. So I downloaded and modified the source code to make them smaller, and it worked out great! The backpacks were way smaller and I could test them out fine by running the forge version client (it is a multiloader setup). However, when I went to publish the mod, I could not for the life of me get it to publish. Whenever I tried to, it throws the error "Publishing artifacts is only allowed when property createBuild is supplied." Digging around in the gradle files lead me to find that the setup was seemingly never mean to output a local file, but rather to publish directly to mod sites and Github (I think). Despite my attempts to tinker with the gradle files to add local publishing and strip out as much (hopefully) unneeded code (for forge) as possible, I still have not been able to get it to publish (still runs the client though).

This was a bit of a surprise as I had tinkered with some other mods and had no issues publishing them before.

Attempt number two saw me trying to rebuild the project in a separate directory after outputting an archive of the desired branch. By merging the files from "common" into the forge directory along with the core mod files I saw some progress, but also plenty of errors. Needless to say, that did not go far, but I did try a few times.

Which leads me to attempt number three. I decided that rather than trying to modify existing code directly, that it might be best to try and make an addon mod that changes a very small amount of code in Useful Backpacks. I was able to import the mod as a dependency, so I can call on files from the original mod. Sadly the one java file I need to modify is a public enum so no directly overriding that (I think). Instead I figured I would just override everything that calls it instead and point the new files to my own public enum. Would this even work? Does this make any sense? No idea! Regardless, it shows some promise I believe, but it still is giving me a bit of a rough time.

I still have some other ideas: do attempt two again but import the core files instead of directly adding them, mess around with the gradle files from the original project some more, etc etc.

Honestly, at this point I wonder if I should just make my own backpack mod from scratch.

That is basically it. Hopefully whoever is reading this is not cradling his or her head in pain right now. I have learned quite a bit from the constant failures so I think I will figure this out at some point.

Thank you once more for your time!

Info:

MC: 1.20.1

Forge: 47.2.20 or 47.4.0

(depends on whether I am using the latest version or the one used in the Useful backpacks' source code)

Useful Backpacks: 2.0.1

Mapping Channel: parchment

Mapping Version: 2023.09.03-1.20.1

OS: Arch Linux x86

IDE: VSCodium

Logs:

Attempt one: https://pastebin.com/i23fbxTW

The one java file I need to modify (modified): https://pastebin.com/71uYJhP2

(I also need to modify three image files, but I figure that should be no issue)

Edited 13 hours ago13 hr by NewIron

This is a good question!

First off, I'd like to start by saying that you probably should NOT be rewriting the entire source code of another mod only to change so little. No offense, but it is a bit unorthodox, but in all honesty, if a mod is open source, and I can save the time from writing code to manipulate the mod FROM ANOTHER MOD, I'm downloadin' that source code, so I can't blame you too much for takin' the "easier" option 'cause then I'd be a bit of a hypocrite...

However, if you don't want your time spent trying to rewrite the code to go to waste, you could just create a new mod project, copy the forge code for the backpack mod into your new project, and assemble the raw mod from there. But it seems that for some reason you want to push this mod as an artifact, which I honestly don't really see the point when it's just a mod for you and your friends, as you could just as easily slap that thing in ya' google drive and call it a day. Alternatively, you could make your own github repository and change the references in the gradle project to that instead, but this is probably the MOST unorthodox thing you could possibly do, and I honestly think that if you were to do this then Satan himself might personally drag you into hell. So to save yourself from eternal damnation, you might not want to do this.

But from a more practical and orthodox standpoint, it is MUCH more appropriate to make a mod that modifies the code for the original mod in some way. There are two ways this can be done: the orthodox way and the unorthodox way. Let's start with the unorthodox way, as it's a lot easier to explain. Basically, you can change the code for another mod by making sure your mod loads in first into the JVM, which is easily done by just putting a bunch of "a"'s in the mods name. Next, find whatever piece of code you want to add in, and create a class with that same code in your mod with the exact same path as the class you wish to change (e.g. net.minecraft.entity.Entity if you wanted to change code in the entity class). The goal here is to trick the JVM into using your class instead of the original. This also means that you don't even have to do like any setup, not even including the backpacks mod as a dependency, so it's SUPER simple. However, this might not be that easy for you to do, because you mention that you need to change enums. I haven't looked too deep into the mods code, and by that I haven't actually looked at all, but if there is one thing I think I remember about enums, it's that they might be treated similar to CONSTANTS after compiling, which means that changing the enum class will have no effect because every usage of the enum is treated like putting in a constant number. If you choose the unorthodox route though, then I could be wrong, so it's still worth a shot.

Finally, you have the proper orthodox way to do it, which is with an assembly transformer. If you don't want to go through the headache of having to set up your own bytecode transformer and learning java assembly bytecode, then I would recommend just using mixin. Basically, mixin or any other ASMTransformer are special tools that can be used to modify the code for certain classes. If you have used Harmony for c# or c++ unity mods, then it's much the same thing: give the transformer a class to do it's magic in, give it a function to use for it's magic, and tell it where to do it. For mixin, this is done by using the @Inject thingamabob (legitimately forgot wth this kind of thing was called). If you want examples of the ASMTransformer route and how to set it up, I would recommend looking at the source code for Galacticraft, as it uses transformers EXTENSIVELY. If you wish to use mixin, then there is extensive documentation on it's usage.

Hope this helps!