IceMetalPunk

I have a block (a "Gazing Glass") that uses a tile entity to provide redstone power while players are looking at it. The functionality works about 99%. However, I want the power to be "strong", meaning if the Gazing Glass is on top of a solid block with a redstone torch, for instance, the torch should go out when a player looks at the Gazing Glass. This isn't work; it only seems to be providing a weak signal to adjacent redstone dust/blocks, not passing the signal through the adjacent solid blocks. I have overridden the getStrongPower() method, so I don't understand why it's still only providing weak power? Here's the branch of the repo where this feature currently is: https://github.com/IceMetalPunk/Infernal-Tech/tree/gazing-glass If anyone can help me get this working, I'd appreciate it

Well, they add some type of soul glass, usually, but mine is going to have special properties that others don't, so ore dicting it won't work well. For more info: my version of smelted soul sand will be Spirit Glass, which can be placed as a block and also crafted into armor. Wearing the armor allows you to walk through the block as though it wasn't there. So it's like XU's Ethereal Glass, except whether it's solid or not is based on whether the player/mob is wearing the armor, meaning you can equip the armor to other mobs and let them pass through the glass, too. I might just do this. Putting the onus on the modpack maker instead of trying to fix conflicts with a potentially unknown number of mods is probably much better. Thanks

This isn't a specific issue I'm having; rather, I'm looking for some general advice about how to avoid conflicts with other mods. I'd like to add some smelting recipes for vanilla blocks that normally don't have them. Specifically, one of these is a smelting recipe for soul sand. Now, I know several other popular mods already add their own recipes for soul sand smelting. So what's the best way to deal with that conflict? I want my mod's smelting result to be obtainable by smelting soul sand, but I don't want to step on another mod's toes and remove their recipe.

That's very good to know! Thank you!

Oh! Well, at least it wasn't a silly mistake on my part this time; I never knew the order of properties mattered when defining block states. Is there a way to determine the order it's expecting? (Or is it simply alphabetical?)

I have three blocks, all of which are basically identical except for their name and a bit of tile entity logic. The blocks function perfectly. I started adding the assets for them... and I'm getting a bug. The item models, which simply have the block models as parents, work just fine. (Currently, as textures aren't made for them yet, "just fine" means "showing furnace textures through the custom model and blockstate files".) But the blocks themselves aren't rendering, instead showing the purple-and-black "not found" default textures. I'm getting errors in the error log when trying to load the models, as shown below: Seeing as it says it "suppressed additional 19 model loading errors for domain infernaltech", I assume that means it's unable to load *any* of the 24 variants across the 3 blocks (and it's not a big assumption, as testing in-game shows none of the models render properly in any orientation or active state). But I can't figure out why. Here's the current repo: https://github.com/IceMetalPunk/Infernal-Tech The last time I had an issue like this, it turned out to be a typo in one of my model files. But there are fewer files this time, and I've double-checked them all, and I can see no typos. The model files are copied directly from Minecraft's own models, with the "minecraft:" domain added to prefix the textures/parents. The blockstate files are not, but I've checked them over several times and see no issue. I'd bet 10-to-1 that this is just another silly typo, one typo screwing it all up... but I can't find it. Maybe I just need another pair of eyes (or two)?

Well... of course it'd be something silly like that, otherwise I might appear to be an actually competent coder Thank you! Everything is working fine now.

Block models are automatically registered, but item models are not. You need to call ModelLoader.setCustomModelResourceLocation for your item if you want the model to load properly.

My first thought was, "What? No, the registry doesn't subscribe to the event. That would be silly to have in both places..." Then I checked and obviously, you're right, it's there twice. You can bet I facepalmed. My only explanation for that is copypasta problems when reusing some code from an older mod of mine, though I can't explain at all how I continued not to see it during all my frustration with this warning... As for the coding style tip, yeah, I was just thinking about that earlier. I was looking at my ServerProxy class and thinking, "Have I *ever* used this? Wouldn't it make more sense to have only two proxy classes, not three?" It's just one of those bad habits I learned via tutorials very early on in my modding education (I think BedrockMiner's tutorials, specifically) and never broke. Seeing as how this mod is quite early in development, I'll definitely be refactoring that and trying to break the habit *A bit later* Okay, so I've refactored the code to organize things better and to remove the duplicate event subscriptions (and also to handle tile entity registration in a more loosely coupled way). It did, indeed, remove the warnings, so that's progress! However... the item blocks are still not showing up in the creative tab. They definitely exist, because I can /give myself the items, they're just not in the creative menu. If you follow the registration down, you'll see the BlockRegistry passes the InfernalTech.tab down into the smeltery block's constructor, which passes it up to its BasicBlock's super constructor, which uses it in this.itemBlock.setCreativeTab(tab). So why would it not show up in the creative menu tab?

I've started a new mod, and right off the bat I'm having serious issues. I keep getting this warning for *every block I register*, and the item blocks aren't showing up in the creative tab (I'm assuming, for now, that these are both caused by the same issue): (The BLOCK_NAME_HERE changes to the registry name of each block.) I'm sure I've just forgotten some tiny, simple thing, like an idiot, which is usually the case, but I've been looking for days now and can't find the issue. The weird thing is that I've never had this problem with any of my other mods, and I tend to use very similar skeleton code for them all for block registration, etc. (so much so that I've been considering breaking it out into a library). So the fact that this is happening now, but never has before, means I clearly did something differently than usual without realizing it, and I don't know what. I've even thrown in some console output in the block registration method, and I'm only getting a single registration output for each, so I don't know how it's acting like there are two of each... You can find the (very minimal) source code I'm working with at the (very tiny) repo here: https://github.com/IceMetalPunk/Infernal-Tech I hope someone can show me what I'm being stupid about so I can get back to making progress... Thanks.

Ay! So it's just the blockstate rotation that must be in 90-degree increments? Dang it, I wish I'd known that before I posted this topic... Thank you! That will be the first thing I try

Yikes... Rendering code has always been my weakest area, and this sounds... complicated. I'll take a stab at it when I get a chance and I'll see what I can come up with; I'll probably end up posting more questions in this topic as I run into issues >_< . Thank you for pointing me in the right direction!

I'd like to have a block model rotate at 16 different rotations, like signs; but I don't want to have a TESR because I don't want this block to have a tile entity (for various reasons). It seems the block state and model files can only specify rotations in increments of 90 degrees, meaning only 4 possible rotations, not 16. What's the best way to go about making this work? (Note: I already have the block state set like signs with a 16-integer ROTATION property, and that all works fine; it's just the model I need help with.) I thought briefly about creating 16 textures, each one rotated by 22.5 degrees, and overriding the model's texture using Forge's blockstate format; but I'm no artist, so it's well beyond my abilities to rotate an image 22.5 degrees without introducing massive blur. That's why I'd like to do the rotations programmatically, somehow, if at all possible. I just can't seem to find a way to do that? What's the best way to get this done?

You say you want to change the model based on the block state, and that's not working; yet you haven't shown us your model or blockstate files?

I'm trying to make mobs follow a line of my mod's "sugar dust" blocks, clearing them away as they reach them. (The sugar dust blocks are, for all intents and purposes, identical to redstone dust in their collisions, passability, models, etc.) I have this AI class, which I'm inserting into EntityCreature task lists in the EntityJoinWorld event: https://github.com/IceMetalPunk/Placeables/blob/sugar-placeable/src/main/java/com/icemetalpunk/placeables/ai/EntityAIFindSugar.java It's basically just a BFS to find the nearest sugar block in range, then it uses the built-in navigator to pathfind to it. It works about half the time; the other half, the mob pathfinds to the block *next to* the actual sugar block instead of the sugar block itself. That causes it to get stuck, since it never clears the sugar and thus keeps finding it and pathfinding back to the current block. So my question is: if I'm passing in the sugar block's coordinates, offset by (0.5, 0, 0.5), as the destination for the navigator, and the sugar block is passable with no collision mask... then how come half the time the mobs won't actually land on it?

I'm not doing that... that was a quote of jabelar's code that I was referencing for clarification... The code I'm using is this: ModelResourceLocation model = new ModelResourceLocation(this.getRegistryName(), "inventory"); ModelLoader.registerItemVariants(this.itemBlock, model); ModelLoader.setCustomModelResourceLocation(this.itemBlock, 0, model);

To be fair, Mojang themselves are doing a lot of that. #BlameDinnerbone I wouldn't mind it, if there were some sort of dedicated IDE that can parse and catch these things inside the Minecraft-specific JSON files. But of course, there's almost no chance of Minecraft modding becoming popular enough for anyone to spend time making such a thing.

Sure, but in this case, the item form of this block is just vanilla glowstone, so it doesn't need its own itemBlock. Anyway, I've solved the problem... and as you might expect, it was caused by a simple typo on my part. In one model file, I had the parent's namespace as "placebales" instead of "placeables". That got lost in the multitude of errors that appeared as a result, but after some debugging and some well-placed breakpoints, I finally fixed it. Thanks to both of you for your help!

It looks like you're just registering the item block as well? Your registerBlockModel method is this: ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(parBlock), parMetaData, new ModelResourceLocation(MainMod.MODID + ":" + parBlock.getUnlocalizedName().substring(5), "inventory")); So if the block doesn't have an item form, obviously that won't work or be applicable, right? (As a test, I gave the block an item form and registered its model accordingly, and lo and behold, the same error still occurs.) That's what I thought... which means the error is somewhere else.... >_< *EDIT* I'm slowly working my way through the stacktrace and code to hunt this down... so far I've made it to the VariantLoader's instantiation of a new MultipartModel in its loadModel() method... still looking further...

... *facepalm* . Okay, well, in copying my model registry code to show you, I did notice something... I'm not actually registering the models directly. I was under the impression that the only thing required to register models, other than having the proper registry names set, was only needed for items. In this case, there is no item form of the block (the "item form" is just vanilla glowstone dust). So if there's more needed to register a block model, what exactly is it? All the tutorials I've found are for older versions, and they all only register item models directly anyway...

That depends on how you're "reserving" the items. One thing you could do is create a custom Slot class which extends Slot (for instance, you could call it ReservedSlot) which does nothing different except overrides isItemValid() to check whatever you need to check for reservations. Maybe even implements a separate isItemValid() method which takes other information, such as the slot index.

In other words, this isn't a common error, and the error message itself is entirely unhelpful and slightly inaccurate? Well, that's wonderful and super useful... >_<

I've made a new block loosely based on the properties of redstone wire, except it doesn't transmit power, it just emits light. (The idea is that it's placeable glowstone dust.) The block works fine... but the model doesn't. I effectively just copies the blockstate and block model files from redstone dust, and then changed the parents, etc. to my namespaced files instead of Minecraft's (still using Minecraft's textures, though). The model doesn't load, and instead I'm getting this error in the console for every block state: [23:56:00] [main/ERROR] [FML]: Exception loading model for variant placeables:block_glowstone_dust#east=up,north=up,south=none,west=side for blockstate "placeables:block_glowstone_dust[east=up,north=up,south=none,west=side]" net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model placeables:block_glowstone_dust#east=up,north=up,south=none,west=side with loader VariantLoader.INSTANCE, skipping ... Caused by: java.lang.IllegalStateException: vanilla model 'net.minecraft.client.renderer.block.model.ModelBlock@3ed50b5f' can't have non-vanilla parent at net.minecraftforge.client.model.ModelLoader$VanillaModelWrapper.getTextures(ModelLoader.java:395) ~[ModelLoader$VanillaModelWrapper.class:?] ... What I don't understand is that it's *not* a vanilla model, and there are no references to vanilla models in its blockstate or model files. Besides, the error even says it's using a VariantLoader and not a VanillaLoader, so how does this error make any sense? I'm clearly misunderstanding something about either terminology or the model loading process here. You can look at my assets folder (and of course the code) at the repo/branch here: https://github.com/IceMetalPunk/Placeables/tree/glowstone-placeable/src/main/resources/assets/placeables I've never had an issue like this before... then again, I never copied/pasted vanilla models and state files before, either, so I assume that's where the problem lies somewhere...

I'm not really sure why you'd want this, but the method you're looking for is simple: WorldServer#getMinecraftServer() to get the MinecraftServer instance associated with the world, then MinecraftServer#stopServer() to... you know, stop it.

I have a block whose model is partially transparent. I'm using the randomDisplayTick method to display some particles inside it, specifically the Totem of Undying particles. Everything looks great when the block is on top of another block, but if there's no block below it, the particles will fall down through my block and keep raining down until they hit something. Which looks terrible. How can I force the particles I'm spawning to despawn/die if they go outside my block's range? I hope I don't need to make an entirely new particle just for that (and if I do, can someone point me to a tutorial for that? The only ones I can find are for 1.7.10 or earlier, and I know the particle system has changed since then). I don't think it's too relevant, but here's the code I'm using to spawn the particles: @Override @SideOnly(Side.CLIENT) public void randomDisplayTick(IBlockState stateIn, World worldIn, BlockPos pos, Random rand) { for (int i = 0; i < 3; ++i) { int j = rand.nextInt(2) * 2 - 1; int k = rand.nextInt(2) * 2 - 1; double x = (double) pos.getX() + 0.5D + 0.25D * (double) j; double y = (double) ((float) pos.getY() + rand.nextFloat() * 0.625); double z = (double) pos.getZ() + 0.5D + 0.25D * (double) k; worldIn.spawnParticle(EnumParticleTypes.TOTEM, x, y, z, 0, 0, 0); } } (It's basically copypasta from the Ender Chest code for this, with some values changed.) *EDIT* Actually, an even better solution would be if I could make the particles act as though they've hit a block when they reach the bottom of the inside of my block. That would look superb; I get the feeling that would be much harder to do, though?