Jump to content

xalcon

Members
  • Posts

    8
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

xalcon's Achievements

Tree Puncher

Tree Puncher (2/8)

3

Reputation

  1. This event allows you to change the looting level when an entity is killed. http://minecraft.gamepedia.com/Enchanting#Looting
  2. So, a lot of people still try to get the Jar-in-Jar system in their mod working and it seems there is no documentation available. This wont be a guide (its most likely not the optimal way to do it), but it might help you to get started. Forge allows you to specify the ContainedDep manifest attribute. This attribute is a space separated list of file names (jar files) which will be extracted from your jar and then loaded into the mod-class loader (at the time of writing, those mods are not examined for coremods, so you will need to package your mod into the coremod jar. This works just fine for APIs and other libraries though! See https://github.com/MinecraftForge/MinecraftForge/pull/4081) The following gradle code will build 2 additional jars: An API jar (which could also be a coremod jar or whatever else) and the Mainmod Jar without the API code. The Mainmod jar will include the API jar, allowing for easy distribution. CPW said its just 2 lines in your build.gradle to setup jar-in-jar distribution... So it seems I'm missing a feature in forge gradle. If you have a more clean gradle script for this, please post it! // at the end of your build.gradle // Create API library zip // Warning: This jar will be reobfuscated! Its only used to package it with the universal jar task apiJar(type: Jar) { from(sourceSets.main.output) { // only include the classes from our API packages include "**/api/**" } classifier = 'obfapi' includeEmptyDirs = false } // task to create a jar containing all classes from the main sourceSet output and the api.jar // also sets up the manifest attribute 'ContainedDeps' which fml uses to extract the api jar at runtime task packedJar(type: Jar, dependsOn: 'reobfApiJar') { manifest { attributes 'ContainedDeps': "${archivesBaseName}-${version}-obfapi.jar" } from(sourceSets.main.output) { // exclude the API classes, those will be included as their own jar exclude('**/api/**') } from("${buildDir}/libs") { include("*-${version}-obfapi.jar") } classifier = 'universal' } // tell forge gradle to reobfuscate our jars reobf { apiJar { } packedJar { } }
  3. The crash happens due to the Hats mod. Either look for an updated version or remove it.
  4. For future reference If I understand this correctly, we would be allowed to put the coremod into its own jar and put that jar into the actual mod jar. While this might not be very useful for modders that use a coremod in multiple mods, it might be useful if its only a change for a single mod. Question I have: could you point me and others to the jar extraction mechanic FML provides? I dont intend on using a coremod at all, but just in case.
  5. Hello! I'm trying to render multiple layers of a block with different brightness values to achieve a "glow in the dark" effect without actually emitting any light. I was able to do this by returning a different lightmap coordinate depending on the tint index. While this works fine, it requires a fair amount of reflection, since i need to read the information from VertexLighterFlat#tint (ForgeBlockModelRenderer#lighterFlat) My suggestion would be to somehow make the tint index information available to Block#getPackedLightmapCoords(). Currently, I can think of 3 ways to do this, but there are maybe a few more pass the tint index to Block#getPackedLightmapCoords(). The information is available in VertexLighterFlat#updateLightmap so it can just be passed to IBlockState#getPackedLightmapCoords(). The issue here is, its not the only place where Block#getPackedLightmapCoords() (or IBlockState#getPackedLightmapCoords()) is called and not all of those spots have a tint index available. We could pass -1 in those cases tho. Make the tint index available via a getter method. Either from ForgeBlockModelRenderer directly or from VertexLighterFlat (this one only has a setter method atm). If we go with the latter one, we also need a getter in ForgeBlockModelRenderer to get the VertexLighterFlat instance Add new interface to get the brightness for a specific tint index, similar to IBlockColor Like I said, i currently use reflection to get the tint index, so I know it works - atleast partially, who knows how this might break. If there is a different way to achieve what I'm doing atm, tell me D:
  6. Thanks for your guide. I begin to understand what gradle is being used for (or atleast whats the intention ) People call this setup "Pahimar-Setup", because Pahimar (Youtube Channel) introduced some tutorials on how to setup eclipse to include each mod as a separate project. Now I'm looking for on how to teach IntelliJ to load my sub-modules as separate mods.
  7. Just read the log o_o" Download the 6 listed files, put them into your .minecraft/lib folder (or server/lib, depending on what you are using) and start it again
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.