wilechaote

Thx for digging into this and forwarding to all!

Quickly FTR, my working approach for this is to use the possibility to globally override the gradle properties: In build.gradle: In gradle.properties: These are then changed to a "file://" location in a local GIT repository containing the downloaded files. However, this might not yet be enough, as further resources appear to be loaded. More introspection needed here ;). [is there a way to move this thread to the ForgeGradle sub forum? I accidentally posted this here]?

Hey all, following up the thread referred to below, does somebody know an elegant way to apply a local build dependency caching for the gradle build? Reading the gradle documentation, repositories { url = "file://my_cache_shadow_repo/" } could do, but I would need some kind automatic selection, because my mods are open source and I would like that everyone can build after cloning without setting up a special environment. That exceeds my experience

Hi, I quickly took a glance at your code, my first shot (brief look) is that " this.isOn" is not reset to false in your updatetick method when you set the blockstate to unpowered again.

Hi, the thing is that Forge is one "mod" for MC that makes it easier to write other mods. The version dependency comes mainly from Minecraft, not from Forge (if it would be possible, Forge would be always compatible with older versions).

Hi, for Forge itself the gradle target should be " gradlew setupForge ", see here: https://mcforge.readthedocs.io/en/latest/forgedev/., "setupDecompWorkspace" is for mod development. However, Forge 1.13 is heavily worked on at the moment (I can't find that target in any build scripts yet, we have to be patient here I suppose).

Hi everyone Browsing log files with some heavier mod compositions/packs it occurred to me that the server and client log spam with exceptions due to missing ingredients could be reduced. So I prepared a pull request (my first one for Forge) on the Hub, with two minor changes (details below). Now, before issuing the pull request and producing unneeded work for Lex and Co, I'd like to ask the experienced modders and Forge smiths if what I am about to file here actually makes sense ( yes, I'm new ) . Pros would be less log spams, cons potentially masking real errors in recipe files. I also don't know if it is intentional that these exceptions are dumped completely, and not just the message. I am fine with any post-it, drop-it, or change-it answer. Details: 1. Exception dumps for unknown item errors are replaced with one-line warnings, indicating that the registration of a recipe for a:b was skipped due to missing ingredient x:z. 2. Added recipe condition type "forge:optional_ingredients" (always returns true, but causes additional handling for recipe exceptions), which allows to omit any warning or error message if the recipe is missing an item. This could make it easier for mod developers to register an optional recipe (without lengthy, probably nested checks if other mods are installed, all items are there, etc). The PR branch and the testing mod with results and jars is on the github, if someone likes to review this in detail: - https://github.com/stfwi/MinecraftForge/tree/2018-12-pr-1.12.x--optional-recipes - https://github.com/stfwi/forge-pr-testing-mod/tree/2018-12-pr-1.12.x--optional-recipes I would be happy to get feedback. Cheers.