Stav

Hello all, I recently tried to upgrade my Minecraft mod to version 1.21.3, and I seem to have a problem with the `RenderSystem#setShaderColor` method. Here is how the screen is usually supposed to look like: Here is how it looks at present: To further explain, the note labels atop of the note buttons are colored cyan (here) using `RenderSystem#setShaderColor`. The note buttons and labels get their colors from their native texture - white. This means that even though I set the coloring to apply to the label (top), it is applied to the button (bottom). What I conclude is happening then, in essence, is that this method (at least for my case) does not color the blit after - but rather the blit before..? This also blocks me from later resetting the shader, as I need to set it back to white before the blitting is done, and not when it's done. So like... what? I've tested this further with other components that require this method, and this preceding-like behavior seems to be pretty consistent for them too. I should mention that all the snippets I am about to show have all worked in past versions. In my class `ClientUtil`, the following methods are defined: public static void setShaderColor(final Color color, final float alpha) { RenderSystem.setShaderColor( color.getRed() / 255f, color.getGreen() / 255f, color.getBlue() / 255f, alpha ); } public static void setShaderColor(final Color color) { setShaderColor(color, 1); } public static void resetShaderColor() { setShaderColor(Color.WHITE); } //... public static RenderType guiRT(final ResourceLocation loc) { return RenderType.guiTextured(loc); } And here is the snippet from `NoteButtonRenderer#renderNote` using it: // "Note" here refers to those symbols in the middle of a note button protected void renderNote(final GuiGraphics gui, final InstrumentThemeLoader themeLoader) { final int noteWidth = noteButton.getWidth()/2, noteHeight = noteButton.getHeight()/2; ClientUtil.setShaderColor((noteButton.isPlaying() && !foreignPlaying) ? themeLoader.notePressed() : themeLoader.noteReleased() ); gui.blit(ClientUtil::guiRT, noteTextureProvider.get(), noteButton.getX() + noteWidth/2, noteButton.getY() + noteHeight/2, 0, 0, noteWidth, noteHeight, noteWidth, noteButton.getHeight()/2 ); ClientUtil.resetShaderColor(); } You may find the full source here. The odd thing is that Minecraft does seem to use this method the regular way I showed, for instance `SkyRenderer#renderSkyDisc` (not sure if I'l allowed to paste it). Could it be that I'm doing something wrong that leads to this issue..? I'm really stumped on this one. I couldn't really find any change logs or documentation for this rendering API (even in this Fabric blog post), so I'm sorry if this seems obvious or anything. Either way, any help would be appreciated.

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.