• Recently Browsing

    No registered users viewing this page.

  • Posts

    • I don't know of any tutorials which really lay it out for 1.15, but the Forge docs are helpful. First thing you'll need is a class which implements IRecipe<C extends IInventory>. When you create the recipe JSON (i.e. a crafting table recipe), that JSON will get converted into one of these objects. All the JSON says is what should be used as inputs and what should be used as outputs. Your object is a code representation of that data, which provides methods for getting the input list, checking if a given inventory matches your crafting requirements, getting the result of the crafting, and so on. Once you have that, you will need a factory which will take the provided JSON and convert it into your IRecipe object. The factory should extend ForgeRegistryEntry<IRecipeSerializer<?>> and implement IRecipeSerializer<((whatever your IRecipe class is))>. The factory will have methods for getting the recipe from either JSON or from the network, and will produce your IRecipe object.   I hope I've helped to clarify some. As I said, the docs are a great resource (when they actually have what you're looking for, that is), and a lot of what my code is based on what I've read from the docs, examples I've found online, or just trolling through Minecraft's code until I find what I'm looking for.
    • That's what I'm doing, sorry I didn't make that clear. As part of the node's data I've got the position and the resource location for the appropriate texture. My main concern was that since I won't know where the node will be located until it gets registered I can't just include the path as part of the background texture, so I would have to dynamically draw it.   I suspected this would be the case, but thanks for confirming it. I assume I can still use Screen for a convenient way to access the GUI, and then override the various rendering methods in order to actually draw what I need? Side note: how did you code-ify `Screen`?
    • You could specify the position of the node as part of its data, which should be part of the instance you use as the registry entry, and draw each node according to its position data. This allows you (as well as other mods that use your mod) to have more control over where the newly added nodes should appear. This also circumvents the "dynamically position the node and draw line between" problem.   Directly using OpenGL should be the easier approach, as it has more flexibility (and Screen uses OpenGL anyways). Create a texture of a line and scale/rotate it to point it to other nodes. Some trigonometry will be needed.
    • Ah you're right, if I print the data parameters every tick server-side, none of them are initialized until I send my packet from the client after editing the grid in the inventory. I'll get back to you on that and see what happens if I fix it.   Unfortunately having both is kind of necessary, it makes some of the referencing I need to do 100x times cleaner, for example it's used to determine which attack the player should do on a certain number of clicks:      
    • Okay, so admittedly this is a really complex thing I'm trying to do, but I figure I'd learn some things along the way, so I decided to give it a shot. My goal is to recreate something like a skill tree in Minecraft. Specifically, my inspiration comes from the Passive Skill Tree in Path of Exile. I definitely do NOT expect to replicate the kind of complexity they've got, as the skill tree has evolved over the course of many years. I've (mostly) figured out my implementation for the skill tree, and now I need to have a GUI allowing the player to actually allocate their skill points. This, unfortunately, seems to be much harder than the tree implementation itself, while also being extremely important to using the tree (I suppose I could implement the whole thing using commands, but I'm going to have to create a GUI at some point so I might as well ask now). Currently, I'm trying to future-proof by using a custom registry for my SkillNodes. While this will allow me to easily add nodes programmatically (and will allow other mods to expand upon the skill tree), it also means that I have no way of knowing what nodes will need to be drawn to the tree at compile time, so I have to dynamically generate the GUI. I likewise have no way of knowing what positions I will need to draw the nodes' textures at, which means I won't know until runtime how long I will need to make the paths between each node. So, here are my questions: 1.  I expect I will need to take advantage of Minecraft's built-in texture stitching, that way I don't have to rebind the texture every time I draw a node. Near as I can tell, there is no built-in GUI TextureAtlas, so I would need to create my own. How would I go about doing that, and would it need to be registered somewhere in order to still fire TextureStitchEvents? 2a.  Since I also don't know each node's position until runtime, I will need to dynamically draw the paths between them, which means I won't know the lengths of each path and therefore can't just draw a texture 1:1 between each node. 2b. I would like to make the paths straight lines between each node, which means I could potentially be dealing with diagonals as well. Can  `Screen` handle either of these scenarios, or would I need to directly access OpenGL?   This situation is something I'm not very experienced with at all, so please bear with me. I'll probably be asking several more questions to make sure I understand what I need to do here. And as I said, I know I'm probably biting off more than I can chew, but I find that I learn best by bodging a solution together at first and then rewriting it with the knowledge I gained.    
  • Topics

  • Who's Online (See full list)