ShetiPhian

I don't know if this is a Forge issue or something that needs to be updated mod side. If you have a mod that uses the Forge javascript asm, and one that uses Mixin to change methods in the same class, prior to 33.0.40 the two could coexist but afterwards Mixin crashes. Up to 33.0.34; works 33.0.35; Crashed: ClassCastException (this looks to be unrelated) 33.0.36 and 33.0.37; works 33.0.40; Crashed: MixinInitialisationError 33.0.41 and up; Crashed: ReEntrantTransformerError: Re-entrance error org.spongepowered.asm.mixin.transformer.throwables.ReEntrantTransformerError: Re-entrance error. at org.spongepowered.asm.mixin.transformer.MixinProcessor.applyMixins(MixinProcessor.java:278) at org.spongepowered.asm.mixin.transformer.MixinTransformer.transformClass(MixinTransformer.java:206) at org.spongepowered.asm.mixin.transformer.MixinTransformationHandler.processClass(MixinTransformationHandler.java:109) at org.spongepowered.asm.launch.MixinLaunchPlugin.processClass(MixinLaunchPlugin.java:135) at cpw.mods.modlauncher.serviceapi.ILaunchPluginService.processClassWithFlags(ILaunchPluginService.java:154) at cpw.mods.modlauncher.LaunchPluginHandler.offerClassNodeToPlugins(LaunchPluginHandler.java:85) at cpw.mods.modlauncher.ClassTransformer.transform(ClassTransformer.java:119) Mod using JavaScript: https://www.curseforge.com/minecraft/mc-mods/shetiphiancore/files/3054955 Mod using Mixin: https://www.curseforge.com/minecraft/mc-mods/botania/files/3049237 - Dependencies: -- https://www.curseforge.com/minecraft/mc-mods/patchouli/files/3037298 -- https://www.curseforge.com/minecraft/mc-mods/curios/files/3042479

Damn, Kinda what I figured but was hoping I was wrong. Thank you.

It is possible to define a conditional dependency? I keep getting bug reports about some of my models being broken, but the issues is due to Optifine. Optifine by itself breaks mod added model loaders, OptiForge fixes this. I would like to say if Optifine exists require OptiForge I've thought maybe adding lines to my toml that makes Optifine dependent on OptiForge, but I feel that is not something I should do as neither mod is mine and it might break something later.

I'm only using sign and blocks but all appear to be available: paintings, mob_effects, particles, blocks, signs, banner_patterns, shield_patterns, chest, beds, shulker_boxes In my main files class constructor I have final IEventBus MOD_EVENT_BUS = FMLJavaModLoadingContext.get().getModEventBus(); DistExecutor.runWhenOn(Dist.CLIENT, () -> () -> { MOD_EVENT_BUS.addListener(this::onTextureStitchedEvent); }); and the method its pointing to @OnlyIn(Dist.CLIENT) private void onTextureStitchedEvent(TextureStitchEvent.Pre event) { AtlasTexture atlas = event.getMap(); }

Ran into this issue again, The wrapper works perfectly with json models, but it doesn't work on obj models. Is there a way to retexture an obj model that I'm just not seeing? Ignore; for anyone wondering, I forgot to add the # in front of the texture name in the mtl file.

If i'm recalling correctly, Minecraft passes a dummy when setting up its solid block cache, and then uses that cache when checking if it needs to push an entity out of a block. Glad it worked, its no fun getting stuck on something. A few days ago I spend hours running circles on some 1.15 rendering code (not what I posted here), finding the fix was only one line was both a relief and devastating due to the wasted time.

On my conditionally solid block I'm checking if the context is a dummy, but its been so long I can't remember why. (I know it was due to in issue, but that's it) if (context == ISelectionContext.dummy() || context.getEntity() instanceof PlayerEntity) { return VoxelShapes.empty(); } return VoxelShapes.fullCube(); or if you don't need the if block for other code you can make it one line. return (context == ISelectionContext.dummy() || context.getEntity() instanceof PlayerEntity) ? VoxelShapes.empty() : VoxelShapes.fullCube();

I'm updating a few multipart blocks that use the texture of the blocks they where crafted with, but have gotten stuck on how to retexture the models. While the sub models are combining and rendering correctly (minus textures) I figure listing what I've done may help. Switched from IModelLoader to IModelLoader, and redirected the json files. Had to switch to IModelGeometry from IUnbakedModel, and with the loss of getDependencies the extra models are now loaded via ModelLoader.addSpecialModel during FMLClientSetupEvent. I'm still using a IBakedModel just called from IModelGeometry.bake now. In the getQuads method I'm pulling the a list of submodels and textures from the IModelData (which is set in the tileentity) The needed submodels are looped over getting each IUnbakedModel via ModelLoader.instance().getModelOrMissing (was using ModelLoaderRegistry.getModel before) At this point I retextured the model via IModel.retexture then baked the submodel, but currently am only baking the model. Finally adding all the quads and returning the list The only thing I haven't found the replacement for is retexture. I have the model's resource location, and a Map of keys(string) and textures(resource location in string form) Edit: I have a working solution, don't believe its the best one, but its something for now. Just created a wrapper around BlockModel that overrides resolveTextureName.

Thank you, that was just the jump start my brain needed. While carefully looking over your linked files, and comparing to my test ones, I noticed the dumb mistake in my test work space. a typo in the path Knowing without a doubt it does work, I started looking over my main work space, and remembered an issue I had early in 1.12. (resource changes stopped building) So just like before I deleted the build folder. Now tags added to the forge domain work.

At first I thought maybe I was using too old of a Forge build so updated it to 1.14.4-28.2.3 Then I figured maybe something was off in my environment, so I tested with a clean 'examplemod' How does one register a new global tag? The docs just mention using the forge domain but that doesn't seem to be enough. I can add to existing tags in the minecraft and forge domains, and I can add new tags to the mods domain, but any new tags outside of the mods domain is unusable in recipes, loot tables and code. Tag "test.json" { "replace": false, "values": [ "minecraft:dead_bush", "minecraft:fern" ] } Recipe: { "type": "minecraft:crafting_shapeless", "ingredients": [ { "tag": "examplemod:test" } ], "result": { "item": "minecraft:dirt" } } With the tag located at "data.examplemod.tags.items" the recipe works. Moving it to "data.forge.tags.items" and changing the recipe to "forge:test" results in the error "com.google.gson.JsonSyntaxException: Unknown item tag 'forge:test'", and the recipe does not work. Trying again with the tag at "data.minecraft.tags.items" and updating the recipe causes a similar error "com.google.gson.JsonSyntaxException: Unknown item tag 'minecraft:test'" and again the recipe fails. Even gave "global", "common" and "c" a try but same issue. So it looks like adding the new json file is only part of the requirements. (and is the only requirement when within your own domain) Do I need to create and register a TagProvider? - If so, what happens when more the one mod registers a provider for the same file? (as that would be the case for all mod added provided global tags at multiple mods access) - If not, what am I missing? or is this ore dictionary feature not yet implemented for tags?

While updating my blocks I've found some issues with rotate, so I'm sharing my thoughts and proving a suggested fix. Starting with the parameters. The addition of 'Rotation' is quite helpful as now tools can indicate direction, but the removal of EnumFacing(Direction) hurts the usability as you can no longer rotate based on the face clicked (eg. axis rotation) Therefore I'm suggesting re-adding Direction, and while we're at it there is no harm in adding Entity as well Now for the bigger issue, the return type changing from boolean to BlockState. This should be reverted. Prior to 1.13 the boolean return was simple, true if the block rotated and false if not. Therefore blocks handled their own rotation and tools handled their durability based on the boolean. 1.13 and beyond returns a BlockState, and looking at the vanilla blocks indicates the tool is now responsible for rotating the block to the value returned. This works fine for single blocks that only rotate, but causes issues with blocks that need to update connected blocks. (even the vanilla beds don't rotate correctly) If the block updates it's connected blocks, then the tool doesn't update the originals state, the multi block is broken. You could just use the neighbor changed method to update connected blocks, but that requires additional checks etc, and fails if the tool didn't have the state change flag set to notify. Here is the proposed reworked method: default boolean rotate(BlockState state, IWorld world, BlockPos pos, Rotation rotation, Direction direction, Entity entity) { Block block = state.getBlock(); if (!(block instanceof BedBlock) && !(block instanceof PistonHeadBlock)) { BlockState result = state.rotate(rotation); if (result != world.getBlockState(pos)) { return world.setBlockState(pos, state, 3); } } return false; } If others agree, anyone is free to take the code and create a pull request.

Your examples have a character after the players name, but the regex isn't looking for it. This may work for you (its basically what you had but shortened and captures the character at the end): "\\w+ [ |\\w]+ (by|of|to|for) " + Minecraft.getMinecraft().thePlayer.getName() + "." Or this one if you want to use capture groups to grab the name to keep track of how often a player is killed "(\\w+) [ |\\w]+ (by|of|to|for) " + Minecraft.getMinecraft().thePlayer.getName() + "." I use this url when working with regex: https://regex101.com If that still doesn't work you'll want to verify the messages received are in the format you expect.

I know this topic is a bit old, but I just had the same issue and a Google search points here. If your packet is working correctly, and its just the warning in the log, you've likely made the same mistake as me. Inside the "messageConsumer" you provided when registering your packet, you need to set the packet handled flag to true. "context.get().setPacketHandled(true);" If it isn't set to true, NetworkHooks.onCustomPayload will return false, and ClientPlayNetHandler.handleCustomPayload will post the warning

Is there a new way to outline individual sub blocks? What about setting the subHit variable on a RayTraceResult? I haven't yet had much free time to look 1.14 over, so may have missed it, and figured it was better to ask here then possibly make an unneeded pull request updating this one to 1.14: https://github.com/MinecraftForge/MinecraftForge/pull/5354 Looks like the new hook would be in "IBlockReader.func_217296_a" changing the first return into a variable update, and make the other return the result of the method added in the 1.13 PR

With "The Flattening" in 1.13 many of my TileEntities can be removed. A way to get the NBT data of any in the save file that are not registered would be very helpful for world porting, as the data within would be used to set the BlockState. 1.13 may already have a way to do this, as it has a a way to remap BlockStates, or a Forge developer has already though of this, but I figured mention it now so it doesn't get overlooked

Its been a while since I used Eclipse but Goto: Window > Preferences > General > Editors > File Associations Click: *.json Set 'Json Tools Editor' to default I cant remember if I need to add it, can remember if I needed to install it either

I never specified if the worlds where new or not because there is no point in remapping on a new world. I'll expand on my previous statement of "Thankfully I've only got one that has a non-alpha/public release so this doesn't affect the rest." One of my mods is publicly released and used by many, I don't want to mess up those existing worlds. The rest are either private rebuilds or public alpha, so I don't care about those worlds. The problem is the remap process is broken; even after a successful remap in world blocks are replaced with dummy air. I have two options; edit the registry via reflection (I'm not willing to do that) or leave the mixed case id's. The mod id's case is automatically made lowercase in the registry so changing that required no remaps, and the remap works correctly for items. That just leaves only the block that is going to remain with the 'wrong' mixed case id.

I've gone through all my mods and changed their modid's to lowercase, and cleaned up all block and item registered names and made them lowercase. Thankfully I've only got one that has a non-alpha/public release so this doesn't affect the rest. I've used FMLMissingMappingsEvent to remap the id's, but it doesn't seem to be fully working. There is no missing blocks/items message on world load. The item and itemblock are being replaced, as they still exist in inventory. The block however is deleted from the world. The log doesn't have any errors and even appears to be working. [FML]: Injecting existing block and item data into this server instance [FML]: Found a missing id from the world endertanks:blockEnderTank [FML]: Found a missing id from the world endertanks:blockEnderTank [FML]: Found a missing id from the world endertanks:itemEnderBucket [endertanks]: Block Remap: endertanks:blockEnderTank > endertanks:ender_tank [endertanks]: ItemBlock Remap: endertanks:blockEnderTank > endertanks:ender_tank [endertanks]: Item Remap: endertanks:itemEnderBucket > endertanks:ender_bucket [FML]: Fixed block id mismatch endertanks:ender_tank: -1 (init) -> 198 (map). [FML]: Fixed item id mismatch endertanks:ender_tank: -1 (init) -> 4096 (map). [FML]: Fixed item id mismatch endertanks:ender_bucket: -1 (init) -> 4097 (map). Here is the remap code, its in the main class of my mod (with preInit, init, etc.) and is being executed as seen by log output and partly working remap. @Mod.EventHandler public void fmlMissingMappingsEvent(FMLMissingMappingsEvent event) { for (FMLMissingMappingsEvent.MissingMapping mapping : event.getAll()) { if (Values.blockEnderTank != null && mapping.name.equalsIgnoreCase("EnderTanks:blockEnderTank")) { if (mapping.type == GameRegistry.Type.BLOCK) { Values.logEnderTanks.info("Block Remap: " + mapping.name + " > " + Values.blockEnderTank.getRegistryName()); mapping.remap(Values.blockEnderTank); } else { Values.logEnderTanks.info("ItemBlock Remap: " + mapping.name + " > " + Values.blockEnderTank.getRegistryName()); mapping.remap(Item.getItemFromBlock(Values.blockEnderTank)); } continue; } if (Values.itemEnderBucket != null && mapping.name.equalsIgnoreCase("EnderTanks:itemEnderBucket")) { if (mapping.type == GameRegistry.Type.ITEM) { Values.logEnderTanks.info("Item Remap: " + mapping.name + " > " + Values.itemEnderBucket.getRegistryName()); mapping.remap(Values.itemEnderBucket); } } } } EDIT: I think the problem has been located. PersistentRegistryManager.injectSnapshot After the missed mapping have been handled in 'if (injectFrozenData)' The remapping is ignored and any missing block is set to BlockDummyAir EDIT2: Well either I'm missing something or my options are between two "wrongs"; use mixed case naming, or use reflection to correct the registry. I don't want to be responsible for accidentally messing up the registry on someones world, so I'll stick with the mixed case naming.

I'm not on 1.9 yet (finishing stuff up one 1.8 first) but I use those so I panicked a bit. After a bit of searching: FMLClientHandler.instance().getClient().getBlockColors().registerBlockColorHandler(<IBlockColor>) FMLClientHandler.instance().getClient().getItemColors().registerItemColorHandler(<IItemColor>) williewillus also has a nice list of changes: https://gist.github.com/williewillus/e37edde85dc78d2e138c

I was having the same issue. There isn't a way to set the origin in the armatures file. Adding the rotation flag to the json model to set it doesn't work either. As in the origin is changed but it doesn't render in the correct spot anymore. There is already an issue on github about it and RainWarrior has seen it, so a fix is likely in the works. Hopefully it is also applied to 1.8 https://github.com/MinecraftForge/MinecraftForge/issues/2734

Ah that's what Fixed is for. I thought is was a fall back or something, so I ignored it. Due to thinking itemframes used the Ground(entity) transforms, I never tested them out. And now I need to go back and adjust several models for the frames.

I'm currently playing with this system, more documentation and example would have been nice armatures/block/<name>.json This file must exist at this location and have the same name as the model returned in blockstate static=false variant The ams file can be named anything and placed anywhere as its location is defined in the TileEntity The asm file will reload with an F3+T but the armatures file will not In the armatures file "joints" defines which cuboid in the model json belongs to a group. (cuboids are numbered from top to bottom and starting with 0) I haven't found a way to define the whole model without adding each cuboid separately. Small example of a model with at least 10 cuboids being divided into two groups. All cuboids after the 10th will not be affected by animation but will still render. "joints": { "group1": { "0": [ 1.0 ], "1": [ 1.0 ], "6": [ 1.0 ], "7": [ 1.0 ], "8": [ 1.0 ] }, "group2": { "2": [ 1.0 ], "3": [ 1.0 ], "4": [ 1.0 ], "5": [ 1.0 ], "9": [ 1.0 ] } }

The model system is good, its just different and seems less powerful. If your dealing with cubic models json files are the way to go. For other shapes you have B3D and OBJ as options. IFlexibleBakedModel gives you more power. For example you can merge multiple json models based on tile entity data. If you wanted models that you programmatically define like ISBRH, you can define your own BakedQuads and return them in getFaceQuads and getGeneralQuads A BakedQuad takes; a int array for vertex data (x, y, z, shadeColor, u, v, <unused>), an int for tintindex, and an enumfacing

Thank you for the reminder, when I place the final texture on the block I'd be wondering why it was darker, then trying to recall how I fixed it on the other models Unfortunately that only control's the brightness of the texture, not how the shadows are applied. Turning off the games smooth lighting "fixes" the issue. So something is causing the shader to think the faces are on the opposite side of the block. I'm not sure if its a model issue or a Forge one. I don't want to work on the final texture as model changes may be needed. Edit: Had an idea, the faces that have the incorrect shading are outside of a single block bounds by 1/16 of a block. I'll need to adjust one of the parts to test, but if that's the issue, it will be both nice to have solved and suck because my design will need to be changed. Edit2: Moving the parts back so they are inside of the block, corrected most of the improper shading, just some weirdness with the outside border. (could be a rounding issue causing it to be a hair out of the block still) I gave a few other things a go: -- useNeighborBrightness ; nope, it looks very bad. -- setting the "ambient" flag to false; fixes the shading but causes the edges of other parts to turn black Looks like the shader doesn't work with a opaque model that is bigger then a block. The model needs to be remade. 'Fix' The shader doesn't like blocks bigger then one Minecraft bock. So the model was resized to fit within a Minecraft block. The odd shading still present after the downsize appears to be a float rounding error I had to change matrix.setTranslation(new Vector3f(0.5F, 0.5F, 0.5F)); to matrix.setTranslation(new Vector3f(0.5001F, 0.5001F, 0.5001F));

My few other obj models are not full blocks so I'm just discovering the issue now. Some of the faces on my models are using the opposite sides lighting. I figure its something off in my model or code but am unsure what it is. OBJ: http://pastebin.com/YBWTKmWQ MTL: newmtl mat_vault1 Ka 0.0 0.0 0.0 Kd 0.8 0.8 0.8 map_Ka multistorage:models/mat_vault1 map_Kd multistorage:models/mat_vault1 newmtl mat_vault2 Ka 0.0 0.0 0.0 Kd 0.8 0.8 0.8 map_Ka multistorage:models/mat_vault2 map_Kd multistorage:models/mat_vault2 Related Code: // In Block public IBlockState getExtendedState(IBlockState state, IBlockAccess world, BlockPos pos) { OBJModel.OBJState newState; TileEntity tile = world.getTileEntity(pos); if (tile instanceof TileEntityVaultDoor && state.getBlock() == this) { newState = new OBJModel.OBJState(((TileEntityVaultDoor)tile).getGroup(), true, ((TileEntityVaultDoor)tile).getTransform()); } else { newState = new OBJModel.OBJState(Lists.newArrayList(OBJModel.Group.ALL), true, new TRSRTransformation(TRSRTransformation.getMatrix(EnumFacing.NORTH))); } return ((IExtendedBlockState)state).withProperty(OBJModel.OBJProperty.instance, newState); } // In TileEntity public TRSRTransformation getTransform() { if (this.transform == null) { Matrix4f matrix = new Matrix4f(TRSRTransformation.getMatrix(this.direction)); matrix.setScale(0.5F); matrix.setTranslation(new Vector3f(0.5F, 0.5F, 0.5F)); this.transform = new TRSRTransformation(matrix); } return this.transform; } public List<String> getGroup() { if (this.group.isEmpty()) { EnumDoorPart part = this.vaultDoorType; if (part == EnumDoorPart.CONTROLLER_2X || part == EnumDoorPart.FILLER_2X) { this.group.add("2x2_" + (this.doorSection + 1)); } else if (part == EnumDoorPart.CONTROLLER_3X || part == EnumDoorPart.FILLER_3X) { this.group.add("3x3_" + (this.doorSection + 1)); } else { return Lists.newArrayList(OBJModel.Group.ALL); } } return this.group; } Image of Issue: https://lh3.googleusercontent.com/s-6tuHnyLzzn7HYjaSAWQp-sETX9Yop8EaPTUNEkun5zfXybKeNnkfJlHXr2cV164zfg3fpqH8ovHqHJCnW_1E7zwJ54IGnmF37Uqa4vbQpODcF4ZRaEF38UpsJW36d29SAOqfoynASpUSUUtg2_6GXI7NL6cpYSCg6CoyrrvLK7Oh2cS5TYVt5baVFILkGMUL5WmnxdIFR8J61MlR8veRO3Fnnjrw7VwAnU2LymFKGUSuV-uvlqADYACVz2ZhH_IMBxCdV2a0LqkSJcxXSb6wP_OamxuOUV6Ga-V03aRCyn0Xt164KKILqYDCHn4dFdwSVzbgDOBcXr3df6yIfOFQQ5pY8eAb5z6MtoVaYkHkEGdQ_AprLC2UxOuSkExuTdLfTGJ5R3lvk2dqn1mUgT3n7SHNJbhBQR0HkRrT7WcjPksS375b0J5Ge7NMpw4_0x8oXf6xrNXGM_w_bSrrQrl1XCORm4T4gHrhi0fTwFbtXiIPvPi7xs1DarLf22uRlhMNQwn5VzRh2K8RN8sywtInj-qe4uitkYA_5MGThZL65A-aYkvbOGq1eMQ8PoAtnHTZ7O=w1631-h688-no[/img] Columns: Model Rotation; North, South, East, West Rows: Model's front with room behind unlit Model's front with room behind lit up Inside of unlit room looking at Model's back In the first row the first and last (north and west rotations) are correctly lit, while some the on the other two are wrong. In the last row the middle (south and east rotations) are correctly lit, while some the on the other two are wrong. Some north faces are using south lighting, and some west faces are using east lighting.