Aeronica

I understand Mojang changed ResourceLocation to force lowercase. That has been a minor irritation. The AttachCapabilitiesEvent#addCapability uses a ResourceLocation too. As a result this new behavior has broke loading a 1.10.x. and earlier world data IF you used a mixed or uppercase resource name. Fortunately you only lose data since the saved capability is simply recreated with defaults again using the lowercased identifier. I was curious if there is a way I can dynamically fix world data. event.addCapability(new ResourceLocation(MXTuneMain.MODID, "IPlayerMusicOptions"), new ICapabilitySerializable<NBTTagCompound>() The result for pre 1.11 is what I would expect. The result for 1.11 was not surprising once I looked at my code and saw the ResourceLocation parameter. I've seen examples to fix your registry renames using the FMLMissingMappingsEvent. But that's for Items and Blocks. At this point I need to do more research. Does anyone have any ideas or suggestions?

I would start by looking at the minecart code to see how a player sits in a minecart. One thing I can say, is that you must invoke sitting on the server side when the entity is placed in the world. You can also search Google with the terms Sittable Entity GitHub and see what you find in the results there.

Take a look at the information Mcjty compiled on his wiki for using his "CompatLayer." Here's the wiki link. He shows an example of how to use an event to remap your resource paths

Take a look at using "PlayerContainerEvent.Close". You can determine what inventory your item is in and the maybe you can force the item to pop out of the chest into the world, or maybe back into player inventory.

As far as SoundEvent registration goes Choonster has a nice way to do it: ModSoundEvents.java Fan power up? Hmm so you are doing some sort of machine sounds. Is this a sort of ASR: attack-sustain-release sound mechanic?

As of 1.9+ you need to register your SoundEvents in the Forge game registry // common code public static SoundEvent SOUND_EVENT_BASIC_SOUND; public static void register() { ResourceLocation soundID = new ResourceLocation(SoundsByExample.MODID, "sbe01_sound_event_basic_sound_name"); SOUND_EVENT_BASIC_SOUND = GameRegistry.register(new SoundEvent(soundID).setRegistryName(soundID)); } As of 1.10.1+ I you no longer need the specify a sound category in the sounds.json file { "sbe01_sound_event_basic_sound_name": { "subtitle": "subtitle.item.soundsbyexample:sbe01_sound_event_basic_sound", "sounds": [ { "name": "soundsbyexample:sbe01_sound_event_basic_sound", "stream": false } ] } } References: http://mcforge.readthedocs.io/en/latest/effects/sounds/ https://github.com/Aeronica/SoundsByExample/tree/master/src/main/java/soundsbyexample/sbe01_basic_sound

I'm looking for some help to get this added as a proper PR to forge. I have a working class for adding the sound category that will work in a mod. I've tested this with with 1.9.4 and 1.10+. I have not yet tried to setup a Forge dev environment but the videos that cpw made make it look simple enough. I still pretty much a java rookies, but learning more as I go. Your comments are welcome. The class below allows the addition of a new sound category. It uses nothing more that the existing Forge utility classes for reflections and enums. You new sound category will have all the attributes of the vanilla sound categories. That is: A volume control for the category displays in the vanilla "Music & Sound Options..." dialog The volume level is saved and loaded from the client options.txt file. The Vanilla SoundHandler will correctly use the custom sound category Here's the class on GitHub. There are some notes about using it in the comments MODSoundCategory I've also included the code below. I have not started work to see what's required to make the vanilla "Music & Sound Options..." dialog behave correctly. Ideally it would work like the "Controls..." dialog. That is the volume controls could be scrolled. So far I've not seen anyone other mod add a custom SoundCategory / volume control. But it might be useful for other mods. And as a part of Forge mod authors could use it without fear of causing issues with vanilla or other mods. For the mxTune mod I'm working on I wanted a separate sound category for the instruments. I can get by without this PR, but I wanted to share this with the community. MODSoundCategory.class From this point on I'll just use bare bones minimal/incomplete code... Creating custom sound categories: Here's one way to use the custom sound category If you add or change or remove your custom sound categories in your mod, vanilla will gracefully ignore and overwrite the settings. No worries about a crash for a missing custom sound category. If you goof up and add a conflicting sound category you will crash MC. Oops!, but of course as a developer you should know better right! Section of the client side options.txt where game settings are saved. Here's a demo of it in use: [embed=425,349]<iframe width="560" height="315" src="https://www.youtube.com/embed/A5lhR-pP4Mg" frameborder="0" allowfullscreen></iframe>[/embed] Here's how the current 1.10.2 vanilla "Music & Sounds Options.." looks after adding several more unique sound categories. Yup, the dialog needs some loving.

Check out this tutorial by Darkhax on connected textures: http://tutorials.darkhax.net/connected-block-textures.html

Depending on where you want to render the item on the player you may want to look at LayerRenderer. You can find examples of it in the vanilla code. You can register is during client pre-init like this: LayerThePlayer layer = new LayerThePlayer(); ((RenderPlayer)Minecraft.getMinecraft().getRenderManager().getSkinMap().get("default")).addLayer(layer); ((RenderPlayer)Minecraft.getMinecraft().getRenderManager().getSkinMap().get("slim")).addLayer(layer);

Try using this instead "version = "1.9.4-12.17.0.1932" From Gradlew do --refresh-dependencies, then setupDecompWorkSpace If that does not work DL the MDK for that version file and run the the setupDecompWorkSpace in there. Also read the change notes and make sure the mappings snapshot has not changed between the version used in 1.9 and 1.9.4. Typically If there is big jump in build numbers between my last update, I DL the latest MDK, and compare my current build.gradle with the one provided by forge. I look for three main things, the gradle.forge version, the mappings used, and the forge version. Sometimes the version format changes for some reason that I think cpw recently fixed: that is "1.9.4-12.17.0.1932" vs "1.9.4-12.17.0.1932-1.9.4"

Pushing and popping the GL state comes to mind. I do that because I have three models that I need to apply different translation and rotations to. The music rack, bench and the inventory item to be displayed. I'm using TESR for now, but I'd like to convert over to the new animation system. My goal is to have the music rack flip up and down and the bench move in and out. The piano itself is based on the vanilla bed code. So one block, two models. The the rack and bench are just normal json defined models rendered in the TESR.

I had some issues getting it to work initially too. But I realized that the item was rendering, but it was rendering outside of my view. I messed up the translations. I looked at the code for the Project E and that was similar, but not updated to 1.9. After some head scratching and testing I got it to work. The end result for me is a piano with and Item that can be placed on the music rack.

This may help with some ideas but, explains more about the object model, but it does show one way to add an item. Render Block TESR / OBJ-1.9

You can use this instead. Seems to be some stuff that's been deprecated, but this works. @Override public void neighborChanged(IBlockState state, World worldIn, BlockPos pos, Block blockIn) { ... }

You can look at this for on idea on how to do it: link

I was googling to day for some information today regarding ICustomModelLoader and ran across this mod source. The author does some of the things you are asking about. https://github.com/mrtska/slopeandcorner/tree/1.9 A blog page about the tech used: https://mrtska.net/2016/03/use-icustommodelloader-in-minecraft1-9/ It does not answer all your questions I'm sure, but I found it interesting.

We need more error output to help you. Have you tried using my build.gradle to see how it works in a test project? Where are your sphinx4 libraries located?

in your build.gradle you need to apply the plugins before you can use them. . . . apply plugin: 'forge' apply plugin: 'java' // or 'groovy'. Must be explicitly applied apply plugin: 'com.github.johnrengelman.shadow' . . .

The relocation is the real magic of the shadow plugin. It changes the path of the classes so they won't conflict another mod that might use the same library or a different version of the same library. But to answer your question, no you don't have to relocate the library if you don't want to. I've seen other mod authors include libraries without any relocation, but I consider it a bad practice. shadowJar { archiveName = tasks.jar.archiveName configurations = [project.configurations.shadow] relocate 'org.antlr.v4.runtime', 'net.aeronica.shadowedlibs.org.antlr.v4.runtime' } Here's what the mcjammer mod jar looks like inside

I don't believe the forge gradle use in the 1.7.10 branch supports this part of the file. reobf { shadowJar{ mappingType="SEARGE" } } tasks.reobfShadowJar.mustRunAfter shadowJar I originally starting working with shadowed libs in 1.8.x and when I back ported some code I had to remove that section. Here's the build.gradle I'm using that works for me. buildscript { repositories { jcenter() mavenCentral() maven { name = "forge" url = "http://files.minecraftforge.net/maven" } maven { name = "sonatype" url = "https://oss.sonatype.org/content/repositories/snapshots/" } } dependencies { classpath 'net.minecraftforge.gradle:ForgeGradle:1.2-SNAPSHOT' classpath 'com.github.jengelman.gradle.plugins:shadow:1.2.2' } } apply plugin: 'forge' apply plugin: 'java' // or 'groovy'. Must be explicitly applied apply plugin: 'com.github.johnrengelman.shadow' //Set the mod version, is appended to the end of the jar name version = "1.7.10-2016.03.20" group = "net.aeronica.mods.mcjammer" // http://maven.apache.org/guides/mini/guide-naming-conventions.html // Set the jar name as the project root folder name archivesBaseName = "mcjammer" configurations { shadow compile.extendsFrom shadow } minecraft { version = "1.7.10-10.13.4.1614-1.7.10" // version = "1.7.10-10.13.1.1225" runDir = "run" } dependencies { // Shadow these jars then later we'll use the Shadow plugin to relocate them into our final jar shadow "org.antlr:antlr4-runtime:4.5.2-1" // use ANTLR version 4 } shadowJar { archiveName = tasks.jar.archiveName configurations = [project.configurations.shadow] relocate 'org.antlr.v4.runtime', 'net.aeronica.shadowedlibs.org.antlr.v4.runtime' } jar { configurations.shadow.each { dep -> from(project.zipTree(dep)){ exclude 'META-INF', 'META-INF/**' } } } jar.dependsOn shadowJar jar.enabled = false processResources { // replace stuff in mcmod.info, nothing else from(sourceSets.main.resources.srcDirs) { include 'mcmod.info' // replace version and mcversion expand 'version':project.version, 'mcversion':project.minecraft.version } // copy everything else, thats not the mcmod.info from(sourceSets.main.resources.srcDirs) { exclude 'mcmod.info' } } Sorry about my previous post, shadowfacts is correct I really did not answer your question properly. Finding concise answers regarding the format and values to use was difficult for me too. There is a lot of information about Maven, Gradle and whole gaggle ways to build code. The cold hard facts and reams of documentation tend to make my eyes glaze over. Working examples that do useful things are best, but not always easy to find. Fortunately there are many very knowledgeable and helpful people on these forums to help guide the rest of us into the light. I'm amazed at the dedication of the Forge forum moderators and developers who continue to press forward despite the fact that the world of Minecraft and modding is an ever changing landscape.

I'd start by visiting the Maven site and searching for the library http://search.maven.org/#search%7Cga%7C1%7C Then you can insert the various pieces GROUP, NAME, VERSION as shown on the site. If it's not on maven then you will need to figure out where it's hosted and add the site to the repositories. Alternately you can use the flatDir option and place the jars in a folder someplace and still shadow them in. partial build.gradle repositories { flatDir { dirs 'xjars' } } dependencies { // Shadow these jars then later we'll use the Shadow plugin to relocate them into our final jar shadow name: "liquinth-a42" // a local jar in the project directory 'xjars' see repositories..flatDir stuff above. } shadowJar { archiveName = tasks.jar.archiveName relocate 'jvst.examples.liquinth', 'net.aeronica.shadowedlibs.liquinth' } reobfJar { setJar(tasks.shadowJar.archivePath) } reobfJar.dependsOn shadowJar jar { configurations.shadow.each { dep -> from(project.zipTree(dep)){ exclude 'META-INF', 'META-INF/**' } } } jar.dependsOn shadowJar jar.enabled = false processResources { . . . } sourceSets { main.java.srcDirs += 'xjars' }

This may give you a hint: net.aeronica.mods.mcjammer.common.inventory.SlotInstrument.SlotInstrument(IInventory inventory, int slotIndex, int xPos, int yPos)

This is a good tutorial that will point you in the right direction: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571597-forge-1-6-4-1-8-custom-inventories-in-items-and

CoolAlias did a tutorial on using API's http://www.minecraftforum.net/topic/2496232-tutorial-modding-with-apis/

You might get some hints and insights from here. http://www.minecraftforum.net/topic/1949352-custom-inventories-in-items-and-players/