wilechaote
-
Posts
7 -
Joined
-
Last visited
Posts posted by wilechaote
-
-
Quickly FTR, my working approach for this is to use the possibility to globally override the gradle properties:
In build.gradle:
Quotebuildscript {
repositories {
jcenter()
maven { url = "${forge_maven_repository}" }
}
dependencies {
classpath "${forge_gradle_classpath}"
}
}In gradle.properties:
Quoteforge_maven_repository=http://files.minecraftforge.net/maven forge_gradle_classpath=net.minecraftforge.gradle:ForgeGradle:2.3-SNAPSHO
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 forrecipe 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.
- 1
[1.14.2] Containers and GUI's
in Modder Support
Posted
Thx for digging into this and forwarding to all!