octarine-noise

Okay, so I managed to get it working in the end, after poking inside the internals of the ForgeGradle tasks. It seems the forgeSrc artifact will be used for compiling if it's available in the gradle cache, and forgeBin otherwise. I had to run setupDecompWorkspace once on the Jenkins server to create the decompiled artifact, and now all is well. It just threw me off, because this makes builds not "stateless", i.e. not completely deterministic from its input, but dependent of previous actions taken outside of the build. I did not expect that. I'd be grateful if someone with more in-depth knowledge of ForgeGradle could explain this to me. Is this normal? Why are the exceptions not in the signatures of the forgeBin artifact - is this also part of Mojang's obfuscation?

So after digging some more, I have concluded that getting forgeBin into the project dependencies must have been a fluke, it's strictly runtime-only, and I should always compile against forgeSrc. However, the same buildscript and gradle version will always use forgeSrc on my desktop for compiling, and use forgeBin on the Jenkins, so it could be server-specific. Except no other project on the same machine is having this problem. Has something similar happened to anyone?

Hello I was trying to move to Jenkins recently, and have run into a problem that prevents my code from compiling. It seems to me that the binary and source patches do not match. To be more precise: the signature of the method net.minecraft.client.resources.IResourceManager.getResource() has a different signature in the forgeBin and forgeSrc artifacts. It has a throws IOException clause in forgeSrc, but not in forgeBin, and since implementations are not allowed to break the interface contract, this leads to compile errors. So if I use setupDecompWorkspace I can compile my code just fine in Eclipse, and if I use setupDevWorkspace I could correct my code so it compiles against forgeBin. But I would lose source attachment in that case, which I don't like. It also leaves me confused. Which signature is the "true" one I should code against? Is this a bug or just a misunderstanding on my part?

I'd like to use the SimpleNetworkWrapper in a setup where the client sends a Request packet to the server, and the server answers with a Reply packet. I have the wrapper set up to a channel, and an appropriate Handler<Request, Reply> registered to a discriminator value. However, when I return new Reply(); from the handler, things start getting seriously weird. In SSP, things kind of work all right. If I open the game to LAN, and connect with a second client, all reply packets will go to the second client, wherever they originated from. If a third client joins, all reply packets go to the third, etc. If I then disconnect with the last logged in client, the one that got all the reply packets, their target doesn't revert back to the second-last, but the packets will instead disappear into the void. If I log ctx.getServerHandler().netManager.channel().toString() however, it looks all right, with the correct socket endpoints depending on the source of the request packet. They just get turned around somehow. With a dedicated server, even one client will have problems. The reply packets sometimes arrive, sometimes not. I did not observe any pattern to it, but I didn't look too long either (I was getting royally frustrated by this point). I took a look at the SimpleChannelHandlerWrapper class, and it was suspiciously devoid of any mention of FMLOutboundHandler.OutboundTarget.REPLY, which is surprising, since FMLEventChannel uses it when routing reply packets from the packet event. I tried this just before returning the reply packet: ctx.getServerHandler().netManager.channel().attr(FMLOutboundHandler.FML_MESSAGETARGET).set(FMLOutboundHandler.OutboundTarget.REPLY); It didn't work out so well, it set up an infinite loop. Then I sidestepped the whole issue by doing the following: simpleNetworkWrapperInstance.sendTo(new Reply(), ctx.getServerHandler().playerEntity); return null; Now everything is perfect, works as intended. Did I miss a setting somewhere, or is SimpleNetworkWrapper borked? Using Forge 10.12.1.1098.

I'd like to make a multi-page GUI, and have certain Slots hidden/shown based on which page the player is on. It's easy enough to hide them by overriding GuiContainer.drawSlotInventory(), and stop them from receiving mouse events by overriding getSlotAtPosition(). But they'll still render highlight boxes, and since isMouseOverSlot() is private, I see no easy way around that. Is there an established method of implementing this? I'd like to avoid copy-pasting large chunks of GuiContainer code into my class, or messing with the Slot list on the fly.