• Posts

    • 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.    
    • I haven't been modding much after 1.15, so I guess I'm quite a noob now.    @Turtledove I'm not sure what some of the data meant, but it seems that you are storing the data that is meant to be the same in two places: the int array and the data manager (corresponding to the 9 integer data parameter). You should keep them in one place instead (I would suggest the data manager instead of the array). bindedArtes[0] = ArteHandler.ARTES.QUICK_SLASH.ordinal(); bindedArtes[1] = ArteHandler.ARTES.QUICK_SLASH.ordinal(); bindedArtes[2] = ArteHandler.ARTES.QUICK_SLASH.ordinal(); bindedArtes[3] = ArteHandler.ARTES.SCATTERING_SLASH.ordinal(); bindedArtes[4] = ArteHandler.ARTES.SCATTERING_SLASH.ordinal(); bindedArtes[5] = ArteHandler.ARTES.SCATTERING_SLASH.ordinal(); bindedArtes[6] = ArteHandler.ARTES.DEMON_FANG.ordinal(); bindedArtes[7] = ArteHandler.ARTES.DEMON_FANG.ordinal(); bindedArtes[8] = ArteHandler.ARTES.DEMON_FANG.ordinal(); //... privateData.register(R0C0,0); privateData.register(R1C0,0); privateData.register(R2C0,0); privateData.register(R0C1,0); privateData.register(R1C1,0); privateData.register(R2C1,0); privateData.register(R0C2,0); privateData.register(R1C2,0); privateData.register(R2C2,0); As you can see there are parts like this, in which the values in the two places are de-synced with each other. My best guess is that during the reading/writing, this happened.   You also seem to be using the capability as a non-direct handler for certain events, which I would not suggest. Capability is only meant to be a method of storing data, and routines that use the data should be in their corresponding places instead of the capability class. This will make debugging easier.
  • Topics

  • Who's Online (See full list)