Blazer Nitrox

I... well, that worked. I'm not exactly a fan, but that worked. I'll have to dig into this a bit more and see if there isn't some way an event can be added for this kind of stuff, because despite what Google turned up I can't imagine I'm the only one doing this kind of thing, and doing it this way just... ew.

When you say touching, do you mean which side they're bumping against, or which side they're clicking on? For clicking on, there's an event that gets fired (PlayerInteractEvent) that includes the face of the block they interacted with. Or, if you want a block to do something depending on which face the player interacts with, the Block class has onBlockActivated which takes a BlockRayTraceResult, which contains the side of the block that was clicked. For which side a player has run in to, that's a bit tricker. I don't think there's any event which gets fired off for that, so the easiest way would be to check PlayerTickEvent or some other similar event and just see if a player is colliding with any blocks, and then from there it'd be pretty simple (i.e. if the player is colliding with a block in the +x direction, then they must be touching the western face (since the block is to their east, the player is to the block's west)).

As the title says. A few months ago I had to mess around with creating my own texture atlas in order to render some GUI elements. A problem I ran into then, that didn't really fit the direction of the initial thread (which I'm also not really willing to necro at this point) is that despite the atlas registering itself as a reload listener with the texture manager, it doesn't get loaded at start up. It does, however, automatically reload any time a reload request is sent (either through changing resource packs or via F3+T). My interim solution was to simply request a reload in FMLLoadComplete. This is what we in the business call a "dumb solution." So: Where am I supposed to be registering the reload listener? I've been doing it in FMLClientSetup, but that was apparently too late, and the texture manager had already loaded (and for some reason doesn't like auto-loading any listeners that get added when they're added). I tried doing it in ModelBake, but that was also too late it seems. Near as I can tell, the TextureStitchEvent for each vanilla atlas is fired after FMLClientSetup, but before FMLLoadComplete. All of my searching both here and across Google has turned up nothing. What am I missing here?

There are absolute gods out there who occasionally make a TL;DR of the Forge changes and how to update to the newest version. 1.16 is still hot off the presses so it'll probably be a bit, but you can always download the MDK and troll through the provided code; except in rare circumstances (1.7 to 1.8, and 1.12 to 1.13) the changes are usually pretty small.

1a) Forge 1.12 is no longer supported, as in nobody on this forum is working on the 1.12 version, and so if you want support here you need to use a newer Forge version (most mods I've seen are updated to 1.15; you might give that a try.) 1b) Your thread was locked by a mod for the above reason 2) If you want to use 1.12 mods, I'd recommend downloading from CurseForge; if you need support with your mod setup, go over to the official Minecraft Forums. I'm not sure if they will be able to help you, but it's worth a try.

Right, and that's how I've been doing it. I think you actually might have touched on the underlying problem... data structures have always kind of confused me for some reason, and I think part of the problem is in some ways I'm still thinking of this as a tree when in reality what I need is a graph, just with a pseudo-root node.

@Draco18s I took another look at the advancements screen and realized I was a complete moron lol. I had been avoiding doing a proper parent/child hierarchy because I want the player to be able to loop around the tree like so: (excuse the terrible quality, I threw this together in like 2 minutes in Paint because I didn't feel like waiting for GIMP to load) At the time, I had thought that a parent/child hierarchy wouldn't be capable of this because the last node in the sequence (top right) wouldn't have it's parent node active, and so it would think that it couldn't be activated. And I only just now realized that when the player tries to activate the node I could just... check if any child nodes are activated as well. All of this is to say that I've been a miserable fool who wasted his time because his solution was only half-baked. Nice.

Under normal circumstances I would have done it that way, however I know that over time I'm going to be adding nodes to the tree (and potentially letting other mods add nodes to the tree as well), so I want to be able to programmatically add the nodes to the tree, meaning I won't know their textures or positions until they are registered. While it does mean I have to do more work in building the screen, theoretically it will also allow me to simply register a new node without having to modify the tree itself. It would also potentially allow me to create a tool later on which allows me to visually build the tree out and then simply export it as a JSON which the mod could then load, although it'll be a looong time before I pursue that route.

Okay, having taken a bit to mess around with everything, I think I understand how I need to go about this. I did notice that SpriteUploader doesn't seem to have any markers for being called on reload, is there some way I should be registering it with the resource manager, or does it take care of that itself somewhere that I'm not seeing? There certainly doesn't appear to be any events I can attach to for registration or to manually call reload(), nor does TextureManager provide any such functionality.

I hadn't even thought of that, but since it would have to grab each advancement's icon as it draws, that could be very useful. Good call

Oh, hey! In the process of updating my MCP mappings I noticed that for some reason Forge was claiming it was 1.15 (and downloading Minecraft 1.15), but it was using the 1.14 MCP mappings, so I had no idea that AbstractGui#blit had a version which took a TextureAtlasSprite. So SpriteUploader seems to do exactly what I was originally expecting, with the added bonus of being able to be called whenever the resource engine reloads. That is very useful, although SpriteUploader#getSprite is set to protected, limiting its use pretty drasically IMHO. I assume the idea is that I would ask it to bind the texture atlas and then access the atlas directly from there. As far as checking the rendering thread, I figured that the relevant methods would always be called on the rendering thread, but since bindTexture does it I figured it wouldn't hurt. All of this has been extremely helpful, thanks a bunch!

Okay, I did some poking around with AtlasTexture, and I think I figured out how to do what I need to. I'm going to record it here for future generations, and as a second post because it just doesn't make sense to me to combine this with the above, since they're mostly unrelated (and the separation will help identify this as me explaining what I think I need to do). AtlasTexture texture = new AtlasTexture(new ResourceLocation(MODID, "atlas")); Stream<ResourceLocation> stream = list.stream(); //We get a stream of all of the textures we want, probably using Collection#stream() SheetData data = texture.func_229220_a_((IResourceManager) Minecraft.getInstance().getTextureManager(), stream, Minecraft.getInstance().getProfiler(), 0); //Last argument is mipmap level, we use 0 map.upload(data); So, first I must actually create a new AtlasTexture, passing in a ResourceLocation which will act as a registry name. Then, to actually generate the stitched texture, I must call AtlasTexture#func229220_a_. It seems I should pass in Minecraft.getInstance().getTextureManager() (which I can do because I'm specifically doing this on Dist.CLIENT) for the first argument, a Stream containing the ResourceLocation's of all of the textures I want to stitch (so this will be done after all of the nodes are registered, no surprise there), an IProfiler (whatever that is, it seems to be used to track the progress of the texture stitching), and an integer mipmapping level (I would assume I'd use either 0 or 1, since I won't need mipmapping for a GUI I don't think). I would capture the output of this and pass it to AtlasTexture#upload, which would actually create the texture information I would then use for drawing. At this point, the AtlasTexture is ready for use. if (!RenderSystem.isOnRenderThread()) { RenderSystem.recordRenderCall(() -> { manager.func_229263_a(texture.func_229223_g_(), texture); texture.func_229148_d_(); }); } else { textureManager.func_229263_a(texture.func_229223_g_(), texture); texture.func_229148_d(); } When we first start drawing, we have to bind the texture. First, we must ensure we are actually on the rendering thread, and ask the rendering thread to do it if we aren't. Then we call TextureManager#func_229263_a, which takes two arguments, a ResourceLocation we want to use as a key for our AtlasTexture and the AtlasTexture itself. We can cheat the first argument here by calling AtlasTexture#func_229223_g_, which is essentially getRegistryName. This will set up our texture so it's ready to be bound to OpenGL (the above is ripped directly from TextureManager#bindTexture). We then call Texture#func229148_d, which actually binds the texture. ((I would provide a code example, except that Screen doesn't seem to provide any way to draw textures using UV coordinates which is all TextureAtlasSprite provides, and directly drawing via OpenGL requires calling Tessellator to get a BufferBuilder, and none of the methods in BufferBuilder (or, for that matter, Screen) have been deobfuscated yet.)) Now, in order to draw a texture from the Atlas onto the GUI, we call AtlasTexture#getSprite and pass in the key for the particular texture we want. That returns a TextureAtlasSprite, which contains the coordinates of our texture on the Atlas in absolute pixels as well as the relative min/max UV coordinates of our texture. Asking OpenGL to draw the part of the texture from min UV to max UV will draw our chosen texture and only that texture.

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`?

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.

OH, I CapabilitySerializable! I'll be honest, I haven't messed with it, as I could never seem to find any resources for how to use it. I honestly just have an interface defining methods for reading to/writing from NBT, and then use those in my ICapabilityStorage implementation. I'm pretty sure what I'm doing violates diesieben07's coding guidelines, but it's how I first learned to do it back in... was it 1.10? Anyway, I'm going to defer to DavidM's judgement here, as he's clearly more experienced than I.

Could you post the relevant code? It sounds like there might be some confusion in the naming somewhere (i.e. you're saving it as "3_x_3_array" and loading it as "3x3_array"). Either that, or it's calling your constructor somewhere you don't expect it to. But without the code, those are just guesses.

Yep, that fixed it. It's NetworkHooks.getEntitySpawningPacket(this), btw. Thanks a bunch for your help. Hopefully something can be done about the official documentation once the API's settled down a bit more.

So, uh... I think I discovered the problem. In net.minecraft.client.renderer.WorldRenderer#func_228428_a_: Breakpoint on line 944 shows that this line is never reach where `entity` is an EntityDart, even if one exists in the world. Problem is, the line immediately before it (943): for(Entity entity : this.world.getAllEntities()) { So... somehow... my EntityDart doesn't exist in the client-side world. Interesting. And AFAIK I'm not overriding anything that would be taking care of that - it should be doing it on its own. -----EDIT #2----- Well, this rabbit hole just goes deeper and deeper. I stumbled across FMLPlayMessages.SpawnEntity, and realize "oh, hey, I can just use this!" And then I realized, "shouldn't this already be called?" Lo and behold, it's not. I have yet to figure out what should be sending the SpawnEntity packet, but it isn't doing its job - it never trips any of the breakpoints I put in it. In the mean time, I'm going to attempt to build my own implementation and see if that accomplishes anything at all. -----EDIT #3----- Well, I finally got something to render. I ended up implementing my own packet specific to my entity and had ItemDart send it when it constructed the entity. It's super dirty (the best I could figure for who to send the packet to was just anybody tracking the chunk the dart was in), but it works... which begs the question of why FMLPlayMessages.SpawnEntity wasn't doing its job. I dunno, but at least I got something to show up on my gorram screen.

First, please put your crash logs into spoilers (or upload them to PasteBin). Second, this is something you should bring up with either the GLSL Shaders Mod or the FTB Infinity Evolved support crew (probably Shaders Mod since it's a problem specifically with shaders). Third, this is the mod development forum, not the general user support forum. That would be in the "Support & Bug Reports" section.

Sure thing I think you noticed the same thing I did, but near as I can tell the itemRef should be fine, since I'm instantiating ItemDart multiple times, once for each item instance. Here's that GitHub repo. I appreciate the help!

Oh Am big dumb. I see what you mean about singletons now, although that doesn't seem to be the cause of my current issue - it's never getting far enough to have undefined behavior. I know for a fact that my DartRenderer isn't being called from debug calls, and stepping through shows that indeed neither is ArrowRenderer. Near as I can figure, I somehow convinced Minecraft that I don't have any renderer registered for the entity, although I don't see anything in the logs that would indicate that. Actually, looking back on it, I'm still treating the items as though they're singletons... where were you seeing behavior that indicates otherwise?

Entities, Renderers, and Registers, oh my! So the gist of the issue right now is that I've created a custom arrow (ItemDart) that is just an ArrowItem modified to allow for setting the damage an arrows does and what item the arrow should give when picked up by the player (otherwise it would always return an arrow). This then creates a custom AbstractArrowEntity (EntityDart) which takes the reference item and returns it in getArrowStack. Then, to render that entity, I have a custom ArrowRenderer (DartRenderer) which overrides getEntityTexture and returns a ResourceLocation whose path is generated based on the item the EntityDart refers to. Two problems. First, DartRenderer is being constructed as it should when registered, but isn't being called in order to render the EntityDart. Second, EntityDart no longer has a renderer, as it seems not even ArrowRenderer is being called for it. As always, here are the relevant bits of code. Some of this is kind of messy simply because I'm relearning Forge (and its best practices) for the first time, so if something is blatantly wrong, please let me know. ItemDart EntityDart (I'll do JavaDocs on this once I get it working lol): DartRenderer: This next few I'm included because the problem might be something to do with how I'm registering everything. To be frank, for the life of me I couldn't find any explanation as to how Entity/Renderer registration is done, so I lifted some code of the Web (Thanks, Cadiboo!) and modified it until it """worked""". ModItems: ClientModEventSubscriber: ModEntityTypes: I'm not including them, but I am initializing the DeferredRegistries in my main mod file's constructor. Also, I'm calling ItemDart#setItemReference in my main EventSubscriber class's item register event, as according to my testing the deferred register fires before the registry event does. That being said, I have no idea if that a safe assumption to make in the wild, so I intend to test that a big more unless someone can shoot it down right here. As far as I know, everything should be working properly. At the very least, Minecraft seems to know that EntityDart is using a custom renderer, but it's not properly attaching it. I haven't seen any related errors in the logs, however. I'd include debug.log, but Forge insists on generating a 3M dump of every single class it loads and I've yet to find a way to tell it to not.

Yeah, I had noticed that when I was reading through his document. I gotta admit, part of me is sad to see magic metadata numbers go, if only for nostalgia's sake. On the other hand, I would much rather avoid magic numbers entirely. Yeah, I'm loving the changes you guys made so far. Now that I'm getting used to it again everything feels a lot... I dunno, cleaner? It just seems like a much nicer experience than it used to be Oh, I suppose I should mark this solved now lol

Theoretically, if you used an installer for Java it should have associated with .JAR files, so you should be able to just double-click the Forge installer and launch it that way. I assume you're using Windows?