HashtagShell

Any plans? Browsers look like they'll be slowly but surely breaking anything that doesn't use at least military grade encryption, jeez.

Rebuilding reflections against guava 21 just works out of the box, seems there were no relevant API changes. Minecraft does start loading in the devenv, which means the binary compatibility problem is fixed (thx MDW and diesieben for pointing that out). It's still a good idea to shadow reflections (and javassist) if it needs to be present in production. Guava doesn't need to be shaded, since v21 comes with forge (thx loordgek). Since reflections is under the WTFPL, here's the jar (reflections 9.11 against guava 21.0 and javassist 3.21.0-GA). It's literally just a maven build with the version changed in the pom. (Keep in mind that once you're including the library from the filesystem, and not maven, you have to depend on its deps manually somehow) reflections-0.9.11.jar

Heh, I just ran into the same problem today. What a coincidence. Anyway, I tried shading both reflections and guava (and javassist too while I was at it) using forge's reobf task. Reobfuscating them to a unique package should fix this collision as far as I can tell. The jar builds correctly and, while I haven't tested it yet, should work in an obfuscated environment. In the devenv however, since the reobf task doesn't run (why would it), the collision remains. The reobf task can be run on arbitrary artifacts since FG 2.3ish, but I'm not sure how the devenv runClient task works, there might technically not be any gradle artifacts involved in the process. Just my two cents.

Or apparently it *does* run over https, but with a cert for the mercurius subdomain, and nginx doesn't route it. At least the login page should be running over HTTPS imo. (Personally I don't really care that much because password manager, but others might not be using one)

Depends on how much you already know. If you have almost no knowledge of Java at all, you should go through a tutorial/course/JLS first, you won't learn what alien syntax means by just looking at it (unless you already know C# or the like). If you have quite good knowledge of the syntax, but not the APIs or quirks (return-in-finally, reflection, ASM, unsafe, etc.), it is well worth going through some example code, for instance, ASM is used quite heavily in Forge. Still, expect to be reading lots of papers and manuals; the likes of ASM will hardly make any sense without a prior understanding of the internals of the JVM, ie. having at least skimmed through the JVMS. If you already know how Java and all its quirks work, there is still a lot to learn in public domain code - best practices, keeping good code readability, algorithms and ideas. For example, once you already know how to render stuff in OpenGL, going through a few examples of how people have solved some rendering concepts will over time make you understand how to render your own shapes in the most efficient way (Though, rendering might not be the best example since it also requires a lot of knowledge outside the field of informational technology - math; rendering is a no-no without knowing trig and vectors). TL;DR: You will profit from reading open-source code, if you already know the language syntax and API basics, if you don't, do a tutorial or something first.

Usually, the method names chosen by the MCP team already describe the purpose of a method well enough, and if not, many methods have a JavaDoc added as well. When a method is either unnamed or without a JavaDoc, you are welcome to name it and its parameters according to its purpose, adding a JavaDoc if necessary, and submit it either via the MCPBot_Reborn bot in #mcp on the Esper IRC, or by submitting an issue on the MCP github.

To toy around with vanilla minecraft code only, setting up an MCP workspace directly might prove more useful.

Tip 1: Try avoiding copy&paste. Tip 2: If you do have to copy&paste, make sure to read through and understand what the code is doing. Avoid "blind" copy&pasting. Tip 3: Refactor and optimise the code to your liking and your style of coding. Example: When I had to copy the elytra motion logic, I went through it and analysed every statement, commented it with what it did, and, in this concrete example, removed all the Mojang derps. (https://gitlab.com/snippets/1657880) If I may ask, where was this specifically copied from? If it was vanilla minecraft, then the decompiler might have been confused by how enums work in Java, producing this mess.

A few notes: In EnumType: Field meta is obsolete, use the autogenerated enum method Enum#ordinal() instead. Returns the index of the enum in the declared order starting from 0. Static field META_LOOKUP is obsolete, just do Enum#values()[index] on demand. The compiler generates a VALUES array, which is then directly returned by Enum#values() The field name is obsolete, every enum stores its declaration name as a field, which can be accessed with Enum#name(). It returns the exact field name (often uppercase), so you have to toLowerCase() it before using it in this case. The getName() method can thus be overridden to return name().toLowerCase(); Also note the Enum#valueOf(String) method, which looks up an enum by its field name (often uppercase). It might be worth your time disassembling a simple enum with a few fields to see what the compiler does to it (you can also use the ASM plugin for idea/eclipse to see the bytecode): user@machine:~$ javac TestEnum.java; javap -l -p -c -s -constants TestEnum.class Instead of you private getResourceLocation(), use getRegistryName().toString(). Same result, but avoids the code duplication. Set the registry name in the constructor with setRegistryName(new ResourceLocation(MODID, name)). I'm surprised Forge didn't scream at you for not doing it. Unlocalized names are per convention in the form MODID:NAME. Although other things will work, they don't follow convention. Set your registry name first and then set your unlocalized name with setUnlocalizedName(getRegistryName().toString()). This follows the convention and makes sure your registry name is symmetric with the unlocalized name, which makes things more organised.

Wouldn't throwing around events for received events be something for Forge to be able to do?

Why am I not surprised that Windows handled something smartly again. </sarcasm>

Following the calls, you will get from gradle calling ant to ant calling the jarsigner tool and throwing an exception when it returns non-zero. Thus, oracle's jarsigner tool failed. Debugging where exactly the failure was is hard, since the call to it is wrapped in an ExecTask. It does tell us about code 1 though. Citing the doc for the jarsigner cmdline tool: Meaning SOMETHING went wrong. (well, isn't that a new one) You'll probably want to run the jarsigner cmdline tool directly with an attached debugger and the exact same options that gradle would have constructed from your configs. Step through it step by step or put a breakpoint on the (I assume there is one) method call that terminates the program with an error code, and then look a level up the frame stack to see where the code is being 'thrown' exactly.

Pretty sure timeout is not a thing forge or minecraft do, ie. probs no events. Isn't it like a socket/packet/networking/connection deal?

Stack traces are useful! Also, ForgeGradle is a (kinda) separate project from Forge, and has its own wiki https://forgegradle.readthedocs.io/ Googling got me this: https://gist.github.com/matthewprenger/9b2da059b89433a01c1c Searching the FG git repo got me this: https://github.com/MinecraftForge/ForgeGradle/blob/c438b06df6339a6763e1549ebfa7b039100c1c0c/src/main/java/net/minecraftforge/gradle/tasks/SignJar.java#L94 Which delegates the signJar call to ant: https://ant.apache.org/manual/Tasks/signjar.html Which delegates the call to JDK jarsigner: http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html

The renderers for entities, apart from rendering themselves, also render a list of extra layers. For the player renderer, that would be the elytra, the cape, armor, arrows, held item, DeadMau5's ears, etc. Say I want to add one myself, for, say, rendering a cupcake on the player's head. Is this the correct approach to rendering extra stuff around vanilla entities? If not, which one is? If yes, how exactly does one add extra layers, when one doesn't have access to the RenderPlayer constructor, where they are added? There are Post and Pre render events, which seem viable, but do they have access to parameters that the LayerRenderer#doRenderLayer() method has (stuff like limbSwingAmount, etc)? RenderLivingBase#doRender(), which calls doRenderLayer() for all the layer, calculates all these parameters from the entity's fields. Thus one could calculate them for oneself in the event, but that seems wasteful since the values are already being calculated every tick.