Matryoshika

Sometimes, one forgets the simplest things.

So, I'm restarting one of my projects from scratch, and I've encountered an odd issue. No matter what I do, one of my blocks refuse to get added into my CreativeTab. Do note, the ItemBlock is being created. I can spawn it in with the /give command. Block (Happens with and without the getSubBlocks method) Registration Main CreativeTab Anyone got any clues as to why this happens?

ModelLoader has to be called in either preInit, after you register your block (as diesieben said in his post), OR in the ModelRegistryEvent (but only if you are using the RegistryEvent to register your block)

For the texture issue: override Item::getArmorTexture to return a resource-location (string, for some reason) for the wanted texture.

Create a class that implements IWorldGenerator. Override the given generate method, to place the wanted structure. Do note, that this will be fired for every chunk during worldgen, so have some randomization or some form of selection based on the chunk x & z. Register this then during the Init phase, with GameRegistry#registerWorldGenerator(instance, weight) where weight is an integer that represents the "wanted" point of execution (low numbers tend to be generated first, higher numbers last).

You must call OBJLoader.INSTANCE.addDomain(modid) before you register any models. By default, the ModelLoader will only load .json files.

... God damn it -__- yeah. Switched tabs after hopping to Suggestions, then switched back to another tab with Modder Support Don't I feel dumb now Well, that solved that issue.

No. IItemHandler, and IInventory are both interfaces, that both do similar things, but in the end, they are separate things altogether. A class can implement both, but often enough, they are not both used. IF said class makes use of both interfaces, then you can freely cast an instance of that class to either. However, using both is incredibly redundant, as in the end, they do the same thing, with IItemHandler being the better choice, as it handles much of the logic for you.

Hey, I'm working on implementing the Annotation Config, which really makes configurations a lot easier, however, the file creation is incredibly rigid... I'm manually creating a couple of other files, and placing them in a subfolder inside the config folder. Now, I have the annotation config file in config/name, along with the other files in config/id/... For the end user, having things scattered about like that, could be quite annoying, as they would likely expect everything to exist in the subfolder to begin with. This could be solved with a rather simple approach of adding "makeSubDir" boolean to the annotation (default false), and if true, use the modid (already passed to the load method) as sub-folder name. It is a rather simple thing, as the File creation is the only thing that needs to be changed, as the Files path is cached. Would all of this however, be welcome, or would a pull-req just be ignored?

You're making a NEW itemstack, with the item from the itemstack you've already gained... Of course it is not gonna have an enchantment on it, unless you actually add one manually to that new itemstack Just use the itemstack you get from getCurrentArmor instead of making a new one

First and foremost: This is the wrong section of the forums: Modder Support is for those who are actively updating, fixing & creating mods. Secondly: Please provide a crash-report. The crash-reports exists inside the crash-reports folder for your Minecraft instance. Upload the latest one to pastebin.com or similar website, and link the url here. To clarify on the "will not work on this version" Minecraft's code changes between versions. As such, each mod has to be updated to work with each new version, if anything the mod "touches" has been changed. As a safe-guard, Forge will not let mods for version x, load for minecraft with version y, as at best, the game will simply crash, at worst, crash Java itself, which will result in a crash-report that isn't humanly-readable. If you want to use Lucky Blocks for 1.8, then you need to download a version of Lucky Blocks specifically for that version range.

Here are a couple of "time" variables from the Entity class along with a few sub-classes Entity::ticksExisted (public) The age of the Entity EntityLivingBase::hurtTime (public) The amount of time an entity should render as hurt (red tint after being attacked) EntityLivingBase::deathTime (public) The amount of time remaining this entity should act 'dead', i.e. have a corpse in the world EntityAnimal::inLove (private & Getter-less) The amount of time that an animal will be able to mate after being given breeding items For the inLove variable in EntityAnimal, you will need to use Reflection to "unlock" it, and store that reference somewhere (as Reflection is relatively costly to do over and over again) "dropping items time", is an unfamiliar term. A few mods out there, like Botania, adds Shedding, but that functionality does not exist in Vanilla Minecraft, nor base Forge.

This is the wrong location. Modder Support is for those working with Creating, Fixing, Updating Mods etc. However, I believe this is what you want: Mod Control It's a Server-Side mod; As such, only the server needs it. It has 3 lists; Gray-List: Mods the client HAS to HAVE. White-List: Mods the client CAN have. Black-List: Mods the Client CAN NOT have.

This thread is over 2 years old. 1.7.10 is no longer supported. Your example will cause chunk-loading issues during worldgen. What if the random.nextInt(16) is greater than 8? And you add 8 to that? Oh, we got n > 16, so now we're in the next chunk. This thread should be locked by a moderator.

My example doesn't use own textures, instead it creates a tessellation of vanilla and/or modded blocks, using their textures. I have not handled colouring IBakedModels, so I cannot provide any information on that subject, however, for having several layers: In the IBakedModels getQuads method, you get the state; From this state, get the IExtendedBlockState, and from that, it's properties, one which should be a collection of ores that this block "contains". Be it Enums, or mere strings, as long as you know "this block contains x & y". Now, some pseudo-code List<IBakedQuad> quads = new ArrayList<IBakedQuad>(); List<String> ores = extState.getProperty(SuperTechOre.LIST); //add stone/background texture to the quads list if(ores.contains("gold")){ //add gold texture to the quads list } if(ores.contains("silver")){ //add silver texture to the quads list } The easiest approach to simply "adding" the texture, would probably be having JSON models with "faulty" ores, eg one model for each type of ore, without background, and just the actual metal/chunk parts, and get the IBakedModel from that, to add it's quads this model. This shows how to get an IBakedModel from a resourcelocation.

Well, this is a dynamic multi-block; It just needs x <block> within the structure, and doesn't care where they are, if I'm understanding this correctly. If so, local variables before the for-each-loop, can be used to keep count of the blocks inside; one variable for input, one for output, one for the controller, and one for the actual walls/bounds of the tank. Inside the for-each-loop, if it encounters a wanted block, add it to the appropriate counter for that type. After the for-each-loop, check these values. If you got more, or less than 1 controller? Incorrect. If you do not have an input, nor an output? Incorrect. If controller+input+output+walls less than (or greater than, for redundancy) 5³-4³ blocks (hollow 5³ structure), then the multiblock is not yet complete

I'd recommend using IBakedModels only, as you are using this for (seemingly common) worldgen. (The official GregTech 4 port back in 1.7.10 I believe used TESR's for rendering ores, to bypass xray, and dear god, the FPS drops) You will need to create a custom model-cache You will need to register your own ICustomModelLoader You have to save your TE data to an IExtendedBlockState to provide the data for the models getExtendedState createBlockState You will have to create an IModel, that points to an IBakedModel Either get cached List<BakedQuad> from your cache, or create them on the fly, and cache them in your IBakedModel Block implementing TE->IExtendedBlockState example: Compressed Block Model Cache example: EchoModelCache ICustomModelLoader example: EchoModelLoader IBakedModel example: MengerBakedModel You can of course not simply copy-and-paste these; they were tailored for one of my projects, but they should give you a hint on how to do things.

Your blockstate is rendering the exact same model, for each different variant. You need to provide y-axis rotation to each facing. Example V "facing=north": { "model": "echo:guillotine.obj" }, "facing=south": { "model": "echo:guillotine.obj", "y": 180 }, "facing=west": { "model": "echo:guillotine.obj", "y": 270 }, "facing=east": { "model": "echo:guillotine.obj", "y": 90 }

Ah, missed that. Are you sure that the Recipes.crushingTubRecipes is altered when you call it.remove in apply? If the recipe is properly removed from your own recipes, then you may need to forcefully remove the wrapper for this recipe in JEI manually.

I think you're doing the opposite of what you want here. Also, you're doing redundant null-checks. The list will never be null, because you're initializing it as an empty arraylist. A for-each-loop will also only run if the collection contains anything (here, if !list.isEmpty())

How will the multiblock look like? Will the controller, input valve & output valve have specific places where they have to be, or can they be located anywhere in the 5³? I presume the tank is going to be empty, yes? Have your tank, tick every ~20 ticks (1 second) and if the multiblock has not yet been formed, scan for the nearest corner block. A corner is very important in an equilateral cube. A corner is defined as having exactly 3 wanted blocks, 1 on each axis. Once you have found your corner, you can get the opposite corner. You know the structure is 5³. The opposite corner will exist ±4 blocks away along the x, y & z-axis. Once you have your 2 corners, you know your structure, without knowing the structure. Scan once more, inside this 5³ cube, (Using BlockPos#getAllInBox) and skip over any blocks "inside" your tank, only going along the outer layer. If you encounter 1 input valve, and 1 output valve, and all other blocks consist of the tank-blocks, woohoo, we know the tank is complete! As for models: JSON models can not extend outside the "blockspace", though the model itself can be translated along any axis. This means that you will not be able to use a normal JSON for this. You can use a TESR, but over-use, and non-optimized, will kill FPS. You can start with a TESR; but I would recommend that you at least eventually make use of a custom IBakedModel, with the List<BakedQuad> scaled to fit the 5³. Custom IBakedModels take a bit to get comfortable with, but once you do, they are very easy. For fluids, you can look at Tinkers' Construct, but I would also recommend that you view Vazkii's Botania mod. The manapools render themselves through a JSON, but the mana inside is rendered with a TESR, and are optimized.

I use a model-cache for Menger fractal inspired blocks, which require me to store them per iteration, per state, per facing, so I use a multi-dimensional map: Map<Byte,Map<IBlockState,Map<EnumFacing,ArrayList<BakedQuad>>>>. If any of these are null (get(byte), or get(byte).get(state)....) then the BakedQuads have not been calculated yet. You need to figure out how you should store your IBakedModels, or better yet, their List<BakedQuad> depending on what side is being rendered (EnumFacing). If nothing else, assign each multipart to a string, and use that string as a key. As for the conversion between IBlockState -> List<BakedQuad> You will need to use IExtendedBlockState to provide information for the model. IExtendedBlockState can carry more information (and any type!) than a normal IBlockState, but that data will not get serialized to meta-data. Now, store the multiparts in your IExtendedBlockState, and read from the IExtendedBlockState in the getQuads of your IBakedModel Pseudo-code V List<BakedQuad> model = new ArrayList<BakedQuad>(); List<String> wantedMultiparts = YourBlocksExtendedState.getValue(WANTEDMP); if(wantedMultiparts.contains("multipart_a")){ if(Cache.get("multipart_a") != null && Cache.get("multipart_a").get(facing) != null) model.add(Cache.get("multipart_a").get(facing)); else{ <Get the List<BakedQuad> from IModel->IBakedModel->getQuads()...> } ] As for how you are supposed to get the multi-parts from JSON, I don't know, sadly. Here are some examples though, for what I've talked about. Cache Block implementing IExtendedBlockState (You also want to write the IExtendedState to NBT so that the Item can render exactly the same (You need to override getOverrides in IBakedModel to return a similar IBakedModel)) Getting values from IExtendedBlockState

Yes, because the Garbage Collector (the thing that cleans up used memory) becomes lazier because you still have so much RAM left. If you have a high amount RAM allocated, it might not start cleaning up memory until you only have ~3GB out of 10 left... That's a whopping 7GB to clean up, and that is going to pack a punch against your processor. Vazkii explains it pretty good for those who do not know Java, if you are still having troubles understanding.

Well, you aren't actually rendering anything in the TESR. It's not linked to model for the blockstate that the tileentity inhabits. In your block, override getRenderType(IBlockState) to return EnumBlockRenderType.INVISIBLE. This essentially tells Minecraft "hey, you don't have to worry about rendering this block, I'm going to handle it myself". In your TESR, call Minecraft::renderModel and provide a cached IBakedModel that was manually gained from the JSON. I get a BakedModel and cache it here, and render it here.(minus the bindTexture part).

Normal models, using JSON: No. TESR: Yes, by using normal sized model and scaling it larger. Unsure if it works, but you can try creating a custom IBakedModel, retrieve the List<BakedQuads> of a normal sized model, and scale them to a new size. This would circumvent using a TESR, if possible.