praryboy

whelp I guess I'm SOL

maybe I should report it as an issue?

Thats funny. Going back through the different versions of the docs, this feature has been around since 1.13. Did it ever work?

From the Forge Documentation (1.19.2) : Am I misunderstanding what this is supposed to be doing?

Hey there, I'm trying to remove stuff from a tag using the "remove" option, but it isn't working for me. Can you tell me what's wrong? The original item tag json looks like this: { "values": [ "minecraft:chicken", "minecraft:rabbit", "#forge:raw_chicken", "#forge:raw_rabbit", "#forge:bread", { "id": "simplefarming:raw_chicken_wings", "required": false }, { "id": "simplefarming:raw_sausage", "required": false }, { "id": "simplefarming:raw_horse_meat", "required": false } ] } and my json looks like this: { "remove": [ "#forge:bread" ], "values": [] } If I put the ["replace":true] entry in there, it does clear out the tag, so I'm pretty sure the file is at least the right name and in the right place.

Found the answer, so I'll post it here for future me's LoadingModList.get().getModFileById(modid) != null works instead of ModList.get().isLoaded(modid)

Hey guys, I'm trying to write an `IMixinConfigPlugin` for a mod I'm writing that more or less just handles integration between a few different mods. I'd like it to only load certain Mixins when the mod they're intended for exists, but it seems that `ModList` is not initialized at that point in the launch. Or at least, `ModList.get()` returns null. Searching on github I could only find code that calls forge code that no longer exists, or are for a different modloader. So my question is, is there any way for me to tell if another mod exists, at the time `IMixinConfigPlugin.shouldApplyMixin()` is called?

I see. Is there another forum that it is supported on, or a solution for a newer version that might work?

Hey there, I'll give you a brief overview of what I'm trying to do, and what I think will be the best solution. I hope someone can tell me how to implement my solution, or has a better idea. Right now what I have is a custom inventory slot that renders an item on the player's back. I also send out a "SyncBackItem" packet whenever a player changes the item in that slot, so anyone within eyeshot will see the other player's model update. The problem is, if PlayerA has an item on his back, and PlayerB approaches him from far away, the item doesn't render unless PlayerA takes it out of the slot and puts it back in. I COULD just send out the packet every tick, but that would be terrible. Is there an event that triggers once, and only once, when another player gets close enough to get rendered? I could use that to send the packet so that the players are synced. Or does someone have a better idea?

This is a bit of a necro, so I assume you've solved the problem already, but for posterity I'm going to post my solution and description of the problem. The issue you're running into is https://github.com/MinecraftForge/MinecraftForge/issues/981 It's been closed and labeled as "not my problem" but as far as I understand it, it IS a forge bug, or at least a propagation of a vanilla bug. As of build 1448, anyway,looks like it was fixed in later builds Apparently, if a block is rendering in the alpha pass, but is surrounded on all sides by opaque blocks, the tessellator is passed no vertices, which results in a crash. The methods in Block that determine whether a block renders on the second pass, canRenderInPass and getRenderBlockPass can't be passed coordinates, and as such will always return true on the alpha pass, if you intend to do so. In the render code itself you can check all the sides of the block, or tell a block/tileentity to do it for you, although that can be pretty expensive and really shouldn't be necessary. If you can render the first pass when the block is completely hidden, I see no reason why you shouldn't be able to render the second. A quick, hacky workaround is simply to pass some dummy vertices to the tessellator when you call the render. for example in your code @Override public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) { Tessellator t = Tessellator.instance; for(int i = 0; i<8; i++) { t.addVertex(0,0,0); } renderer.renderStandardBlock(block, x, y, z); return true; } If there is a better answer I welcome someone to correct me, but this is what I've found.

He's aware of the issue and has a patch on his website. Thanks again for your help!

sigh... yep, I can confirm it. I removed a random other mod, Witchery in this case, and dumped the ID logs. This time the block IDs didn't shuffle around, the IDs that witchery had were left empty, as would be expected. Apologies again for assuming forge was the culprit, I didn't know a forge mod could do something like this to the underlying workings of FML. This now leaves me dependent on Reika to maintain compatibility with other mods just so I can keep the server current, which is annoying as I only added Reika's mods as a novelty, one that I quickly found no one was interested in pursuing. Before I go to his thread on the minecraft forum, is there anything you guys can suggest to fix this myself? I'm proficient enough to write my own code or use any tool you could suggest

Fair enough , I'm glad to hear this isn't what's supposed to happen! I'll admit I was frustrated beyond belief and assumed the worst. I tried to isolate the problem. So I created a new singleplayer game with the old mod loadout, made a complete copy of the .minecraft folder and removed the mods I needed to remove, in this case being Rotarycraft and Reactorcraft and their prerequisite DragonAPI. This way there are no new mods or a different save file, this is two identical setups with only a couple mods taken out of the second one. For the record I'm using the recommended 1.7.10 build, 1230. https://dl.dropboxusercontent.com/u/49321746/Info%20dump.rar In here you will find the ID dumps from both the new client and the old one, the logs the new one produced when I loaded the save game, the test save game itself, and printouts of the mod list for each client, if you want to verify I didn't change anything more than I've claimed. What you'll notice is that when the ID range reactorcraft and rotarycraft took up is vacated, all the mods that came after them had their IDs moved down to fill the gap. Adding any new or updated mods causes even more chaos, if you'd like I can try to produce some more logs and id dumps for that as well. I can also pack up all the mods and configs as well if necessary

I understand that Block ID conflicts are bothersome, and a lot of rookies don't even bother reading error logs and come bother you when those conflicts happen, but there is something that you need to take into account: Not all servers keep the same mod loadout indefinitely. Here's the situation. I updated a few mods on my server including Buildcraft. Recent versions of Buildcraft made changes to their API and as such broke a couple other mods on my server. I removed those mods, doing so in the past with hard-coded IDs was a non-issue. No one used these mods and I was more than prepared to use a tool like mIDas to convert any ore they generated back into stone. Problem is, with your new Automagic ID system, forge decided that was a good time to shuffle all my IDs and straight up break the world and everything in it. Is this intended behaviour? There must be a better way to handle this, there is no reason for all the IDs to change just because some space opened up in the list. Do I have any options to save this?