Stav

Sorry for the lack of response. I was occupied the whole week. ------ EDIT: I just ran the game (something that I should've done 🤦‍♂️), and the same unmapped vanilla method error occurred - exact same one. This time, though, it happened with even just the regular Jar files, with no sources attached. Any help with that will be appreciated... More details below for when I blindly believed my IDE ------ I explored the link you provided, and I can say that it has indeed worked; both the sources and the Jar get picked up via this method! Thanks a bunch. I ended up constructing a local Maven repository in my user directory, attaching the sources after the publish task was done. However, I'm quite certain this process could be automated as stated here; though, I didn't get this to work at all in this project. The following is what I tried: java { withSourcesJar() } publishing { publications { mavenJava(MavenPublication) { artifact jar } } repositories { maven { url "file://${project.projectDir}/mcmodsrepo" } } } artifacts { archives sourcesJar } Also regarding the topic, I'd wager that if I want my mod to be easily extensible, then I should upload it to a remote Maven repository. According to the comment under the 'repositories' block, "ForgeGradle automatically adds the Forge maven and Maven Central for you". Should I, then, publish it to Maven Central? And, how would I go about doing this? Please forgive my ignorance and lack of knowledge in this matter. Thanks yet again.

Hey there. Thank you very much for the fast reply. I sincerely apologize for lacking more details. I believed this snippet was enough to determine the problem, but I was mistaken. So, allow me to expand on details: The mod that I am attempting to reference is a mod that is present in the libs directory: repositories { flatDir { dir 'libs' } } In there, the files genshinstrument-2.3.jar and genshinstrument-2.3-sources.jar are present - such that the mod and its sources are different jars. I've seen a similar issue here (#736) - However, theirs revolved around a hosted dependency, whereas mine is a local one. I don't know if it makes the difference, though. That being said, the mod and its sources are also hosted on GitHub. Other than that, I don't have much more details to share with you, as the rest is just the boilerplate build.gradle. Yes, I am. Thank you for the helpful article, too - however, their method is workspace-only, and does not apply to build tools such as Gradle. However, even if the implementation method is absolutely not intended for loading source files; the fact is, it still did load them after I declared the statement. This heavily leads me to believe that Gradle (at least in VSCode) is responsible for handling this kind of stuff, but I'm simply not doing it properly. I do believe so, too. As per se, when loading Minecraft with the implementation on, it shows an error stating that an unmapped Minecraft class has been attempted to be called. The debug.log is attached below. Everything does, however, function normally without the source implementation statement. I hope this information was of use to you. Please let me know if I missed anything else... Thanks again.

Hey there, I have a mod I'd like to depend on, and I also have its sources jar file. fg.deobf did not load it automatically as I expected, even though the jar has the "-sources" name suffix. I then attempted the following inside of build.gradle: dependencies { minecraft 'net.minecraftforge:forge:1.19.3-44.1.23' implementation fg.deobf("com.cstav.genshinstrument:genshinstrument:2.3") implementation "com.cstav.genshinstrument:genshinstrument:2.3:sources" } This results in a configure successful output, but an unresolved dependency issue of the same mod. VSCode does, indeed, load the sources, but Minecraft fails to load complaining that an unmapped (vanilla) method does not exist. What am I missing? I've been stuck on this for a couple of good hours now.