wehttam664

Thanks for the info. For the toml, I assume you're referring to earlyWindowControl? I tried that setting and it either doesn't work too, or something else is the root cause. We also tried injecting a patched libglfw but it hasn't help either. Unsure if there is a path forward with this still or if the only option is to just upgrade to 1.20.2+.

Hi! I am working with a team for a Forge-powered modded server which, for various technical and logistics reasons, utilizes a custom launcher (specifically a fork of HeliosLauncher). This works well for most of our uses, but specifically our Wayland Linux users (Arch, Fedora, SteamOS, etc.) are unable to start the game due to a crash. This is the entire game log file: Most users report that a crash report is never generated by the game, however, there is more information available in the launcher's console: In doing research, I found information that Minecraft and Wayland generally don't get along without this patch and these extra JVM options for Forge, but this hasn't helped. It actually looks as though Forge is ignoring my JVM flags and starting its early window anyway. The usual driver and systems updates have been done in all cases to no avail. This issue occurs for a dozen or so of our modpack users on different distros, but all using Wayland. Forge: 47.2.20 Minecraft: 1.20.1 Any ideas?

If I use the simulated InventoryCrafting, "where they already are" is the first nine slots (no matter where the grid they used to be), leading to the issue I described.

I originally tried this, but the issue because immediately apparent after the crafting completed. There's no real way to distinguish where on the grid the "remaining items" should be placed, and they usually just get placed in the first 9 slots (with is not the upper left 3x3, but rather the first row of five then four from the second row). The "remaining items" do work off the given inventory size and faking it a 3x3 causes it to behave incorrectly. Trying to avoid this, as copying recipes out of the vanilla manager tends to leave several mod recipes behind, since Forge loads mods that do not depend on one-another in a pretty random (and inconsistent) order and I miss recipes loaded after my mod. I'm starting to like the idea of patching this class more and more, but I'm not entirely sure how to do so.

It appears the image's alpha is being raised to 1 above a certain threshold. Taking a look at the pumpkin blur code in net.minecraft.client.gui.GuiIngame, the major difference in yours versus the pumpkin (which appears to have functional alpha transparencies from the image), is that "depth" and "alpha" are being disabled, and the depth mask flag is set to false before drawing the image. It also appears to be using the blend function differently. Here's what I'm referring to: protected void renderPumpkinOverlay(ScaledResolution scaledRes) { // this stuff is what's different. GlStateManager.disableDepth(); GlStateManager.depthMask(false); GlStateManager.tryBlendFuncSeparate(GlStateManager.SourceFactor.SRC_ALPHA, GlStateManager.DestFactor.ONE_MINUS_SRC_ALPHA, GlStateManager.SourceFactor.ONE, GlStateManager.DestFactor.ZERO); GlStateManager.color(1.0F, 1.0F, 1.0F, 1.0F); GlStateManager.disableAlpha(); // the draw code looks like yours. this.mc.getTextureManager().bindTexture(PUMPKIN_BLUR_TEX_PATH); Tessellator tessellator = Tessellator.getInstance(); // .. tessellator.draw(); // re-enable the things you disabled. GlStateManager.depthMask(true); GlStateManager.enableDepth(); GlStateManager.enableAlpha(); GlStateManager.color(1.0F, 1.0F, 1.0F, 1.0F); } Try adding in those calls and see if that makes a difference. I know the pumpkin blur does something similar but on a smaller scale, so this may solve the issue.

Long story short, I've got a 5x5 crafting grid that I want to be able to handle 3x3 recipes, much like how 3x3 grids can take 2x2s. The 3x3 recipes work, but only in the upper left 3x3 of the grid, and it seems to completely ignore any items in the remainder of the 5x5, even if those items are a valid shapeless recipe, which work perfectly fine. Upon further investigation, it seems that ShapedRecipes is the only class at fault. ShapelessRecipes, ShapedOreRecipes, and ShapelessOreRecipes all behave exactly as I want them to, so I investigated and source and discovered the actual issue in the matches(InventoryCrafting, World) method. It seems that the shaped recipes class has hard-coded a 3 into the code, while the other three recipes all utilize the width and height of the given inventory. The code in question, ShapedRecipes:58: public boolean matches(InventoryCrafting inv, World worldIn) { for (int i = 0; i <= 3 - this.recipeWidth; ++i) { for (int j = 0; j <= 3 - this.recipeHeight; ++j) { // those 3's are the issue, I assume // all the other implementations use inv.getWidth() and inv.getHeight() // ... I'd like to solve this issue without going through the mess of CoreMods and ASM (primarily because I have no idea how to do that), but I don't mind doing it if I have to. Is there a solution to this?

I'm trying to work with custom OBJ models for a block, but I cannot seem to get the model to render. There is absolutely no tutorials for doing this in 1.9, so I have to do a large amount of playing around by myself. I have found that I no longer need (nor can use?) a TESR, and can simply just use a ICustomModelLoader and OBJModel. I have this as my loadModel method: @Override public IModel loadModel(ResourceLocation modelLocation) throws Exception { OBJModel.MaterialLibrary materialLibrary = new OBJModel.MaterialLibrary(); materialLibrary.parseMaterials(resourceManager, "textures/blocks/crystal_seelum_block.mtl", new ResourceLocation(AuroraProjectBase.modId + ":blocks")); return new OBJModel(materialLibrary, new ModelResourceLocation(AuroraProjectBase.modId + ":block/crystal_seelum_block.obj")); } After cleaning all the lines that upset the parser from the .mtl, it appears to load without errors, but the block is invisible in-game. What am I missing here?

You could technically just check entities near the block and apply a velocity vector to them whose magnitude varies with distance.

I'm trying to use an IBakedModel for my block since Forge block states don't quite do what I need and it works fine in the world, but I'm not really sure how I would go about rendering it in the inventory. What do I have to do to the blockstate JSON and/or in the getQuads() method to make this work?

Upon playing around a bit, I found that PropertyEnum.create(String, Class<T>) will work fine when called inside createBlockState() or in a static context, but not in object context. Basically: final static PropertyEnum<FrameType> frameTypeProperty = PropertyEnum.create("type", FrameType.class); // Works final PropertyEnum<FrameType> frameTypeProperty = PropertyEnum.create("type", FrameType.class); // Doesn't work. Any thoughts, or should I go bug report this?

Now, I'm not really sure why, but for some reason PropertyEnum.create(String, Class<T>) is returning null. This is what I have: final PropertyEnum<FrameType> frameTypeProperty = PropertyEnum.create("type", FrameType.class); // ... @Override protected BlockStateContainer createBlockState() { System.out.println(frameTypeProperty); return new BlockStateContainer(this, frameTypeProperty); } The console has null printed to it then the game crashes on an NPE in BlockStateContainer:99. Why is it null?

Somehow I am surprised I did not see that one line up from mcDefaultResourcePack. Sometimes it takes a second pair of eyes, I guess. Thank you, I'll play around with that.

I'm trying to do a number of things with the game's Languages and I found that resource packs are fully capable of doing what it is I need to do. However, I need to ensure this pack is activated at start and cannot be deactivated, much like the DefaultResourcePack loaded by Minecraft. I chased the loading of such down to ResourcePackRepository and spotted the setRepositores(List<Entry>) method, but the entry it accepts is not publicly accessible. func_188565_b() appears to get an Entry from the last call to setResourcePackInstance(File), but that method accepts a file. While I'm not above reflection, I'd like to avoid it if possible. Is there a way to inject a permanent resource pack?

For a few different reasons, I wanted to try adding another language to the game that Forge can find the associated lang files in mods. I noticed the constructor for Language is public, but I don't know where to put the resulting object. At the moment I'm reflecting the LanguageManager, and, as with most reflection, it feels dirty and unsafe. Is there an actual way to do this?

I'm not really sure why, but for some reason my block is having its texture culled when it really shouldn't. I'm using forge blockstates for a block that uses minecraft:farmland as a model under a certain condition, replacing the #top and #dirt textures. Noteably, the model is being culled on all non-top faces despite a block not being present next to them. While normal farmland is not affected by this, my block is. I confirmed it was a culling issue after copying the model and removing the `cullface` key, wherein the model rendered fine. What's going on here?