Starless

I was wondering if there's something to make the modders life easier like a RecipeRegistry class that you can use that won't matter for the vanilla workbench. You register a recipe in it, it deals with all the ore dictionary stuff for you, etc. If there isn't can somebody tell me which classes should I look into for registering and later obtaining outputs from recipes? I plan to copy/paste the necessary stuff to make a machine sensible recipe registry: for this machine with this ingredients, you get this output.

You are right, I guess. I don't know the call hierarchy of this method so whoever are its caller must know what they're doing.

so I have 3 blocks of stone in inventory slot 1, I want to put 3 other blocks of stone in inventory slot 1. I can't? I don't even think this method should be used at all. it compares stack sizes, which makes no sense in the context.

class ItemStackHandler { @Override public void setStackInSlot(int slot, ItemStack stack) { validateSlotIndex(slot); if (ItemStack.areItemStacksEqual(this.stacks[slot], stack))//this, wasn't this function supposed to have it's return negated? return; this.stacks[slot] = stack; onContentsChanged(slot); } }

I assume IStackHandler lets me put whatever item I want in whatever slot I want, correct? IStackHandler would then work as the base class for the 3 different inventories I need to make my tile entity work. It can only accept certain types of items in a certain inventory, it cannot accept any items on another inventory, only the tile entity itself can put items there... there's a few more details that I need, but I think it's safe to assume IStackHandler is just "a chest" of sorts right?

Hmm. I have to implement a different IItemHandler for each side then? (each side that matters for automation, that is). I would have to have 3 separate inventories, so that would be 3 IItemHandlers. I could have an abstract base class for them, and override just what I need for make the sides work. Still, this seems like a lot of extra steps compared to just implementing ISidedInventory.... I have a feeling Forge gets more and more complicated as time passes by, which is very unusual. Generally, frameworks get simpler with time, hiding away plumbing stuff in the form of elegant abstractions. Take Java's new lambdas for example. No longer you need an anonymous class, just a lambda expression. With Forge, some things seem to go the other way around. It is as if we had lambdas, but now we have to implement a separate class on a separate file. not even anonymous classes will do anymore. Now we have to really get our hands in there.

IItemHandler has no method that take sides into consideration, so I guess I'm stuck with ISidedInventory.

Ok, then I implement IItemHandler and offer it as a capability?

so, I still have to implement ISidedInventory. Now I just need to implement a Capability for it too.

My Block should implement ISidedInventory, but there's this new thing called Capabilities. Do I need to use both or choose one? Are Capabilities like an object that handle all that's related to that thing for you? (getStackInSlot, getInventorySize, decrStackSize, etc). If not, what are they good for?

Thank you very much! that worked. By the way, I'm using eclipse Mars for modding, because with the new version, Neon, the gradlew setupDecompWorkspace and gradlew eclipse would not result in a nice workspace with everything ready and our example mod there. No. After doing all that, Neon opens an empty workbench, with no project loaded, nothing. Just a welcome page.

There's no Open With option. Just "Open". The file is not there somehow. So there's nowhere else I can find this file?

Oh. No, I see the file, I can navigate to its location ( ReferencedLibraries/forgeSrc[...]/assets/minecraft/blockstates/furnace.json ; I can do the same thing for the model file). It just won't open. It's not an actual "file". It's probably part of a saved stream that never got translated back to json. If I right click it, the option Show In -> System Explorer is disabled. This file that eclipse is showing doesn't seem to exist in my file system. I assume another version of the file may exist elsewhere. see the images bellow:

lol that image made my day.

So this will sound stupid. but where can I find that file? The one that gets exposed in eclipse as part of minecraft's source code won't open. I guess because whatever translates .class back to java doesn't care about .json. Is there a location in my file system where I can find those files? And one last question, is it just me or this whole blockstate and models and json files is a lot (A LOT) harder to deal with than the old metadata?

So I pass null as the second argument of ModelLoader.setCustomStateMapper , or I don't invoke it at all? What you're saying is, since I have texture and cube_all for both normal and inventory I don't need a json file for the block model, just this one for the BlockState suffices. could you please link/write me an example of a json file that does that? Writing a json file on my own for an unknown schema is not possible. If I had an example I would get the gist of the schema and then I'd be able to write other files myself, and my questions will be less broad and more specific (I hope).

So, this is the way to register a block with no properties? @SideOnly(Side.CLIENT) private static void registerRender(Block block) { Item item = Item.REGISTRY.getObject(block.getRegistryName()); ModelLoader.setCustomModelResourceLocation(item, 0, new ModelResourceLocation(item.getRegistryName(), "inventory")); ModelLoader.setCustomStateMapper(block, new DefaultStateMapper()); } and then I have to create this json in my blockstates folder: { "forge_marker": 1, "defaults": { "textures": { "all": "modid:blocks/texture_name" } }, "variants": { "normal": { "model": "cube_all" }, "inventory": { "model": "cube_all" } } } and this one in my models.block: { "parent": "block/cube_all", "textures": { "all": "modid:blocks/texture_name" } } and if my block had a property of type PropertyDirection like this public class MyBlock extends Block { public static final PropertyDirection facing = PropertyDirection.create("facing", EnumFacing.Plane.HORIZONTAL); } and if it had a texture for each side, what would the registration and json look like?

Thank you very much for answering. I see. So what seems hacky is a way of registering the block and it is an ItemBlock. But how to register the block in world model? Please could you give me an example of a block with no BlockStates, and a block with directional block states?

I'm aware this is a really newbie question, but after modding for 1.7.10 for so long the transition is not being kind on me. All this stuff with registry names, json etc is making me crazy, I wish there was a way forge could abstract all that away from modders. I looked at the documentation (which I wish wholeheartedly was more complete), and I found there is nothing on how to register your blocks. With Items, I'm supposed to do this, right? ModelLoader.setCustomModelResourceLocation(item, metadata, model); And all the code I see people just register the block first (in the GameRegistry , I mean) and then just grab an item from it using GameRegistry.findItem(String modid, String registryname) and then do the above for the item. Is this a hacky way of registering a block texture or is this the right way? If the block has BlockStates, like PropertyDirection which is very common, how is it done. I don't trust tutorials very much, I understand modders have vices and bad coding practices that are frowned upon by the Forge developers. I want to code my mod according to how the Forge team expects their framework to be used, and avoid hacky stuff as much as possible. By the way, if there's a book I can buy, written and/or certified by the Forge team, please let me know.

Thank you! Good to know.

Just wondering if Forge devs already have an estimate on how many breaking changes there will be and how big will they be. Or if anyone heard any rumours about this.

But I don't think the mods would have to be written in C++ necessarily. C++ gets compiled into machine code, so as long as a piece of code externalizes an API it can interact with anything, because, in the end, it all boils down to the hardware instructions. I believe we would still have a considerable performance gain if our mods targeted .NET, with minecraft running pure machine code and offering numerous API entry points with which the CLR on top of it could use to run our mods. It would probably be a gargantuan project to implement, but with Microsoft backing Mojang up I think they are up to the task. In the end it all depends on how interested Microsoft is in making this happen. And I think it would be foolish of them to not consult with the developers of the modding tools like Forge, Spigot and MCP. Lots of enterprises fail because big shots from the outside look at a bunch of data to figure out how the inside is like, instead of just asking someone who's been inside all his life. Yes, I was refering to Minecraft client for Windows 10. It's a beta. They're working on it. I believe it won't be long before it gets all the features of the java client and more. Only problem I foresee, as of course is the topic of this thread, is how will they manage modding.

Now that there's a C++ client (which performs orders of magnitude better than the Java client in my experience) Mojang needs to make it moddable. Certainly no easy task, but they could use the years of expertise of Forge and MCP people to speed up the progress considerably. Would the unsung heroes of the Minecraft modding community be willing to get hired by Mojang? My suggestion is that those teams of devs take the iniciative and get together and develop a prototype or a schematic approach for a modding framework and present it to Mojang. Also, how hard do you guys imagine it would be to write a modding framework for C++ minecraft? No class loader, no JIT, no runtime. Is it even possible?

Tabs, DropDown Lists, List Selectors with scroll bars. To name a few.

Something with basic GUI controls already implemented, like a simplified version of Java Swing or Java AWT or Windows Forms or Windows Presentation Foundation... Something like that, but much simpler of course. Is there an open library with such contents?