LexManos

Talk to the Optifin people. We do not make it, and are not responsible for it.

Just make your json files.

Forge DOES have a system where mod's are added as resource/data packs after Vanilla so they override their entries. Again provide valid repro case and we can figure out the issue, as all our tests work just fine.

DO NOT send people to the github issues or suggestions forum for basic shit like this. As far as I know data packs load just fine. If they do not you need to provide exact use cases because 99% of the time, you fucked up. Be it the json syntax. Be it file placement. Whatever it is, MOST of the time it's end user error. So, if you THINK you have a bug, track it down, provide a reproduction case. And we can help you. In this case it looks like you're throwing the recipes all over the place and not actually overriding the vanilla one. Which of coarse wont work because there is NO sorting when it comes to recipes, the first one to hit will be the one used. So if both recipes exist in conflicting states, then it'll use the first one.

Data packs work just fine as far as I know. If they dont report a bug properly.

https://crowdin.com/project/minecraft-forge

It wasnt taken away, learn to use resource packs correctly.

They dont even need to self-disable. They just need to tell us what side they are for and we'll skip them as nessasary.

1.13+ installers are just jar files. So they will use whatever you have associated with the .jar extension. You can try running https://johann.loefflmann.net/en/software/jarfix/index.html If your path isnt setup right.

Seriously... the same place you get all other official forge downloads.

Then they can change the recipes. The issue is dependant recipes is advancements and other things. You're just moving the config from one file to another. I can see your usecasse, but it has downsides of just missing recipes.

Why does Windows not support OSX? We are not responsible for Optifine. Optifine is closed source. As far as we know, we have given them all the tools they need to function. Bug them, not us.

why have this a config condition? If they are changing the config then they can change the loot table

There are many instances where you don't give a shit about the actual content of the cap. You just want to know if it IS a thing. For example pipes, you don't care when you render the pipes what exact items are inside a block. Just that that block has a inventory, and you should render that side being connected. You don't want to spend the massive amount of time every frame getting the large object as a return value and checking null. When you could just call a SIMPLE implementation that tells you directly the information you want to know. Hell even more reason to have the items be lazy initialized is because the client doesn't need to know, and have in memory, the inventory of a block. Because it would always be useless/empty unless you specifically add a sync packet that sends over all the inventory contents. Is that simple enough for you to understand?

It's a stupid simple concept. It was literally designed to replace these instanceof/cast in a non-hard dep way. has == instanceof get == cast. If has == true Then get using the same cap&side MUST not return null I hate people doing `if has(){ cap = get(); if (cap != null)` because thats not how it was designed. I'm not taking everything as a personal slight, I just stated that Dies was spreading the exact opposite of what to do. So I informed you of what the design was. {As I have informed people many, many, MANY times since the system was designed} This entire system is moot however, as 1.13+ now uses LazyOptionals because people couldn't understand the concept of instanceof/cast. People are NOW being stupid and returning new instances of the LazyOptional every get call.. and that's just even more stupid... It's a simple system, with TONS of examples in Forge/Vanilla. how can people screw it up so much?

Does my get only return a cap if its on a specifc side? No it returns caps for all sides. What did you expect the code to look like? if (cap == MYCAP){ if (side == UP) return true else return true } You know what that condenses down to? Are you starting to see what I mean by lightweight code? https://en.wikipedia.org/wiki/Lazy_initialization If nobody wants your cap, why bother creating it? Who knows, caps can be anything. Cap initialization can take whatever values you want. What about say.. a cap that keeps track of all entities within a BB around the TE. Instead of having every BB list tracked for every chunk every tick. You could delay capturing that snapshot of entities until the getCap is called. And it could add it's chunk event handlers lazily. I dont know, thats not really a good example but my point is. Building the caps COULD be expensive both CPU wise and memory wise. You can use lazy initialization in your get to save those costs.

The IDEA is to have complex logic in get, and lightweight logic in has. As in: has(cap, side) { if (cap == MYCAP) return true; } get(cap, side) { if (cap == MYCAP) { if (side == UP) { if (myUpHandler == null) { myUpHandler = superComplexMethodThatCalculatesMyUpHandler(); } return myUpHandler; } else { if (myOtherHandler == null) { myOtherHandler = otherSuperComplexCodeThatTakesTime(); } return myOtherHandler; } } } We now have that complex logic in the Supplier for the LazyOptional in 1.13+. But people are STILL not doing it right...

Don't call hasCapability only to then immediately call getCapability. getCapability will return null if the capability is not present (which you already check for...). That's actually the exact opposite of how things were designed. Get is costly, has should be fast And thus better to run. But whatever nobody ever implemented it right.

the installer jar is a executable jar. Run it with java.

No, The exe is just a wrapper around the jar installer. Just use the jar installer.

Whenever I say "It's not possible to do right now" I mean that the vanilla code base is written in a way that makes doing that thing require re-writing large swafts of it causing breaking changes with any other loading system out there. So instead of Forge doing it ourselves. We work with Mojang and try to get them to make the vanilla engine better. Which they eventually did, and we enhance to make super resiliant and more featureful. There is a line with keeping vanilla compatibility that we have to stick to. So we can't just make major changes to the engine itself. However Mojang has been working on both addinjg new content to the game. And cleaning up the engine itself to work better. It's a slow process but it's going.

1.13.2 mods do not work on 1.14.4. Notibly, world edit is crashing.

Currently in 1.14.4, it only fires on the server due to Mojang's major refactor of the code where we hooked in. We have no re-implemented client side events yet. When we do isRemote will be true for client side.

Ok dude, you posted on the github and failed to follow the directions there about posting logs and actual useful information. Then I directed you here, and you STILL failed to post any useful information as described in the EAQs. You really shouldn't be making a mod if you can't follow basic directions. We are not magical we can not read your mind and have no idea what is going on without the information that you have. So post logs. Post code Post your configs Post everything even remotely related to the problem. As it sits, best guess you fucked up your build.gradle and are actually still using 12.

A patch got missed in the 1.14.4 update, https://github.com/MinecraftForge/MinecraftForge/commit/7411b444d3810c94d53c8edf6ec560c4e30cb4ef Update to 28.0.14+