Ommina

blockstate filenames are based on the registry name, so my immediate response is "you don't". The model, in turn, contains the block's texture, and I imagine you are not anxious to have all your blocks look identical.

Try Tasks > build > build instead. You'll note one of the tasks listed as it does its thing is reObfJar (and that this task isn't listed for build > jar). That should leave you in good stead.

How are you creating the jar? At first glance, this feels like the reobfJar task isn't happening.

I've added the check, but it prompts a followup. I was working under the assumption that if the IBlockReader was also an IWorldReader once, it would be each time. Are cases such as "usually it is, but sometimes it might not be" typical?

I would expect spelling "assets" correctly (instead of "asstes") will make a world of difference. Even in 1.14.4.

It is, indeed, an IWorldReader, which gives me everything I need. Things look sharply less silly now. Thanks so much.

(My) getWeakPower() checks the state of the four horizontal blocks surrounding it. I can do that via IBlockReader, but I'd like to avoid loading any chunks to do so, if the block happens to be placed directly on the edge of an unloaded chunk. And that's the only method from World that I need. Everything else I can do with IBlockReader. I just want to call the same functions from randomTick as I do from getWeakPower. It's not so much a matter of missing a method (isBlockLoaded notwithstanding), but wanting to avoid a bunch of duplicated copy/pasted code. If I do without the isBlockLoaded, I can cast randomTick's World to IBlockReader and get on with my life.

Ah. Not the response I was expecting. I have a handful of functions that I'm calling from randomTick(). I would quite like to call the same functions from getWeakPower() without copying and pasting just to change the signature. World also provides isBlockLoaded(), which I would like to take advantage of. Three copy/pasted functions isn't the end of the world (teehee). But I'd sure like to remove the duplication if I can.

Perhaps not a very good trade, but putting that aside. Overriding Block's getWeakPower(), I have an IBlockReader instance (and a blockstate, blockpos, and side). I need a World instance instead. There are plenty of examples of getting a World instance in wilds of the Internet, but I've been unable to find anything current. Searching for methods that return a World did yield IForgeDimension, but it didn't take me very far. So -- where can I get my World? If I missed something obviously, well, frankly I'll be quite pleased.

Nope, I'm deliberately using the vanilla model because I want to remove as much mod code from the equation as I can. So 'examplemod' blockstate points into vanilla's model, which in turn uses vanilla's texture. (I did try using a mod model and a copy of the texture originally, but it made no difference.) The Block.Properties.create( Material.GLASS ) bit is likewise a copy/paste of how vanilla creates its glass block. I don't think there is some Forge-added Material that modders are supposed to use instead (it seems rather odd if there were), but I'll take a peek just the same.

What happens if you cal getTexture() after bind() ? And what appears in the log? Looking at TextureManager, bind() will load the texture if the texture is not already in the manager's internal map. getTexture() will not - it is just a reach into the map and return whatever is (or is not) there. So if getTexture() is still returning null after the bind() ( or loadTexture() ), that'll give you a hint of where things could be going wrong. That said, loadTexture() does log a warning if there in an IOException, and crashes outright if there is some other exception, so I'd expect there to be a note in the log if something were going wrong here. Edit: And those spaces in the ResourceLocation path... there are just there for the convenience of those reading the post, right? If you're getting a ResourceLocationException in the logs, well, that would go a long way to explain why the later bind() is not working.

I'm not a fan of bumping my own posts, but I want to throw this out here again before taking it to the bug tracker. I've taken as much mod code out as I can, while still demonstrating my issue. The whole code: @Mod( "examplemod" ) @ObjectHolder( "examplemod" ) public class ExampleMod { @ObjectHolder( "testglass" ) public static Block TESTGLASSBLOCK; public ExampleMod() { MinecraftForge.EVENT_BUS.register( this ); } @Mod.EventBusSubscriber( bus = Mod.EventBusSubscriber.Bus.MOD ) public static class RegistryEvents { @SubscribeEvent public static void onBlocksRegistry( final RegistryEvent.Register<Block> event ) { Block b = new GlassBlock( Block.Properties.create( Material.GLASS ).hardnessAndResistance( 0.3F ).sound( SoundType.GLASS ).func_226896_b_() ); b.setRegistryName( "testglass" ); event.getRegistry().register( b ); } @SubscribeEvent public static void onItemsRegistry( final RegistryEvent.Register<Item> event ) { event.getRegistry().register( new BlockItem( TESTGLASSBLOCK, new Item.Properties().group( ItemGroup.MISC ).maxStackSize( 64 ) ).setRegistryName( "testglass" ) ); } } } With one blockstate json that points to the vanilla model: { "variants": { "": { "model": "minecraft:block/glass" } } } And one item model json: { "parent": "minecraft:block/glass" } And that's it. https://github.com/Ommina/PaneInTheGlass if anybody is excited by a GitHub repository of the above.

Perhaps it's too early to start asking about 1.15.1 rending changes. But I'm going to anyway. I've created a test mod with exactly one block. Said block is merely an instance of the vanilla GlassBlock, using the vanilla Block.Properties (copied from Blocks): Block b = new GlassBlock( Block.Properties.create( Material.GLASS ).hardnessAndResistance( 0.3F ).sound( SoundType.GLASS ).func_226896_b_() ); b.setRegistryName( "testglass" ); event.getRegistry().register( b ); Test Mod has one BlockItem for its lonely block: event.getRegistry().register( new BlockItem( TESTGLASSBLOCK, new Item.Properties().group( ItemGroup.MISC ).maxStackSize( 64 ) ).setRegistryName( "testglass" ) ); And that's it. Yet they render dramatically different: https://imgur.com/a/UEcagsa Texture is a copy/paste of vanilla's. Item version DOES render fine in inventory. Am I missing something here? Or am I just experiencing the consequences of a lot of rendering changes within a very new Forge release?

Player .isSneaking is now .isCrouching

FTBAcademy, as a pack, contains about 120 mods. Your mod folder seems to contain about five. For whatever reason, the pack installation is not just incomplete, it's barely started. Adding a single mod isn't going to make it fly; whatever was used to install the pack originally, it didn't work.

This is not the complaint thread. I'll leave that one to somebody else. It is, though, a question for those more familiar with the upcoming changes than I -- and all I know is what I read on Twitter. Is my time going to be better served by putting aside any further FastTESR / particle / GUI (?) changes and work on other aspects of the mod instead? Stuff changes. I get that. And if it is a change for the better, that's not a bad thing. But just the same, I don't want to spend a whole lot of time over the weekend working on something that's going to be discarded days later. Tks!

Well, it took me a couple of days, a handful of hours on 'mathisfun', and at least on instance of the problem intruding its way into dreams -- which is a sad commentary on my life. The model elements are in block co-ordinates. The hit vector is in world co-ordinates. I was mixing units and simply took ages to make the connection. So, yes, it is totally enough.

Multiple blocks are indeed being placed, there are 26 other blocks surrounding my centre block. My "does the vector intersect with this square" tests happen in these shell blocks, since they are the blocks actually being activated. Which does reinforce the notion that the VoxelShapes path, however attractive, simply isn't going to fly. So it's back to the math.

I have a Block. So far, so good. The block has a Boolean property: FORMED. When false: the block's model is 1x1 (one full cube). When true: the block's model is 3x3 The property switches from false to try when 26 other blocks are placed in the 3x3 area, in a typical multi-block fashion. This is not my problem. My problem is that I really want to know when the player clicks on a particular element of the 3x3 model. I can't help but feel there is some ray tracing going on here, but none of my attempts of the past too-many-hours have yielded any success. So far I've tried two approaches. First, a "does this vector intersect with a square" solution found over yonder on StackOverflow. It has given me mixed results. As I don't really get the math going on behind it, all I've been able to do is try different inputs and see what happens. Second, I've been fussing with VoxelShapes. While they appeared promising, they only seem to be considered if the centre block is being targeted in some fashion. I've tried to change the blocks getRaytraceShape to return the 3x3 area, but it didn't care. Any suggestions? I've been working with onBlockActivated, so I do have the Player and BlockRayTraceResult with which to play. Thanks for reading.

Yes, 98%. If you use the "Display" option, it will include your item transform(s) in the exported model json, which is not where Minecraft looks for it. You'll have to cut/paste that block of json into the item model file instead.

private static ResourceLocation location(String name) { return new ResourceLocation(MOD_ID, "testing_dust"); } I'm pretty certain this isn't what you intended. Sure, I suppose it's possible that you wanted every ResourceLocation created to be named "testing_dust" while discarding name, but that'd be weird. If you're registering a block via a call to location, that would certainly explain why your testing_dust item is looking for a blockstate.

IntelligentEnergistics-1.7.10-2.2.1.610-universal.jar has a distinct "I was made for 1.7.10 and will be unhappy in a pack for 1.12.2" feel about it. I'm not sure if it is the cause of your error, or will be outright ignored by the mod loader, but it certainly shouldn't be there regardless.

Thank you for the reply. It does wholly make sense that the mod datapack overwrite the vanilla entry. Still feels weird though! @thinkverse I don't know how adding custom loot to chests was done in 1.13, so I can't provide any particular "converting one method to another" insights. In 1.14.4, though, a LootTable object pretty much follows the same 'form' as a loot_tables JSON files, with pretty much the same naming. If you get a feel for how the JSON works, the LootTable object works pretty much the same way. Generally, the LootTableLoadEvent will give you the LootTable object. To the LootTable, you add one or more LootPool objects. To each LootPool, you add one or more LootEntry. Annnd... to each LootEntry, one or more LootFunction. Each individual object will store the same bits of information as its corresponding block in the JSON. For example, the pool object has .rolls(). Each of the various objects do seem to have their own JSON deserializer, so it may even be possible to parse some mod-provided JSON and just add the result to the provided LootTable. I may spend some time going down this avenue at some point, but for now I'm very much in the "make it work so I can go back to being bad at creating textures" phase.

I expected this to take... a few minutes. At most. Yet here I am. Let's say I want to add moditem to the optional bonus chest created at world spawn. I expected to add a spawn_bonus_chest.json to loot_tables, get it merged into the vanilla version, then be on my way with a nice plate of crackers. Except it is aggressively ignored. It does seem to be loaded, or at least parsed, insofar as if I put weird values in the json, I will get notes in the console. But the chest remains bereft of moditem. If I move spawn_bonus_chest.json to the minecraft namespace, it works, but it replaces the vanilla table, instead of adding to it. I note there is a LootTableLoadEvent, but adding the entries via code strikes me as so far from the current data-driven style of controlling loot that I have trouble believing it is the correct way of doing this. Is there some way of merging my loot_table json with vanilla's?

It is, however, getRenderLayer() in 1.14.4. The thread title claims 1.12.2 -- has there been an attempt to copy/paste some 1.14.4 sample code into the 1.12.2 project, with unhappy results?