Leaderboard

Minecraft 1.12: The newest version of Minecraft has been released. Forge has been updated to support this new version. However due to the way Mojang implemented the Recipe changes there are a lot of under the hood changes that we need to do. Most notably re-writing on of the largest/most intricate systems of Forge, The Registry system. This will take some time, so do not expect a recommended release quickly. However if you are a modder you can start using the current versions to build against. Some API's may change in the early days of Forge so be sure to be ready for that. I'm sorry, I usually try my best to maintain binary compatibility, but it's just what will need to happen. For users, you can use the current builds. But just be warned that things are actively being developed and we ask to please responsibly report issues on the forum. Once I finish the rewrite and get a stable recommended build of Forge out I will make a more detailed post listing all the major changes like I always do. New Policy on Coremods: Sadly core modding is still a thing. As always we request that you guys attempt to work with us to get changes into Forge instead of core modding it yourself. However, if you MUST we have decided to put forth to the community a few 'Best Practices' for core modding. The intention is that large communities such as FTB, Technic, and Curse work with us to promote these best practices. 1) Coremod must be the coremod only, and no extra library/features/apis/etc. There are far too many coremods in the community that package tons of classes that have nothing to do with the modifications they make to the game together so that people will be forced to use their coremod just because they want a utility. This is bad. So Coremods themselves should be limited to JUST the IFMLLoadingPlugin, and IClassTransformers, and as few utility methods needed to make those hooks run. 2) Coremod binaries must be signed. This is a very basic thing that just verifies the person/organization we think made the coremods actually did. It also verifies that the file that was downloaded has not been modified in any way. As it sits there will NOT be any central authority on the keys used to sign things. So Self-signing will be allowed as long as you provide the community your signature. Starting in 1.13, with the loading system rewrite, users will be prompted to accept signatures of coremods. It is our intention to work with people like FTB, Curse, and others to make these signatures easy to use and manage. For example a user would say they trust FTB, and wouldn't be prompted for every coremod that exists in a FTB modpack. For the technical side you can read more about Jar Signing here: https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html 3) Coremods should be visible source. This will be a controversial standard, but my thoughts on it is that if you're screwing with someone else's code (which is the only reason to ever write a coremod), then you should be willing to show what you are doing. It is stressed that this is VISIBLE SOURCE only. It is not a requirement that you allow others to use your code, or modify and distribute it. It's simply that we can see it. The signatures and visible source are NOT designed to be security measures. As there is nothing preventing malicious code from being signed and a user accepting it. This is just the risk you run with Minecraft modding as you're running compiled code from random people on the internet. This is however designed to make the community more open and try and stem the number of coremods out there that have no reason to be coremods. Major Policy change: I am happy to officially announce a new member of the Forge team. Everyone welcome Mezz. His official responsibilities are to be the Pull Request, and Issues manager. Basically, he's the guy you yell at if your PR/Issue is rotting on github. He's the guy who is tasked with reminding me that they exists. He will be the one responsible for filtering all the PRs/Issues before they get to me. So I don't have to deal with telling you guys to follow the standards like making a test mod, posting logs, etc.. In addition, he is also the one who decides if old versions will have PRs accepted. Yes this means there will be a limited development system for older versions. How far back that means is ENTIRELY up to Mezz. However the rules are that ANY pr adding features for a old version MUST be applied and accepted for the current version FIRST. Save for features that would have no place in the new version. Example being adding a new achievements hook when the new version removed achievements. It will still be our official stance on this forum to only provide support for the Current version, and the previous version. However, if the community wishes to have a few dedicated people step forward and become our Legacy support team them I am willing to work with them and see what we can set up. The main reason we do not provide support for old versions is simply we do not have the manpower. So start helping out! Response From Sponge:

Those numbers (519, 515) aren't magic. The decompiled minecraft code uses them because the numbers came from an enum. I'm away from dev, so I can't point you at the right place, but they stand for GL_ALWAYS and GL_LEQUAL respectively. I suggest you update your code to use the enum reference so that your code is more readable and doesn't contain these arbitrary magic numbers.

Store the counter in your TE and reference it in your TESR

@DifferentiationIt's working wiht you in multiplayer with client-side mod only ?

Check out Shadowfacts' tutorials for the basics of creating blocks and items. Also check out Choonster's TestMod3 for lots of examples.

Comments for feedback: 1. Since you are handling block replacements, you need to use ServerChatEvent instead of ClientChatEvent. 2. You can just make a new command and register it. execute(MinecraftServer server, ICommandSender sender, String[] args) throws CommandException method is executed in server-side. 3. Don't use Minecraft.getMinecraft() in server-side once you get the server to run the code, this might crash you or cause errors if on a server. 4. Don't use WorldClient, simply use playerIn.world once you have EntityPlayerMP through CommandBase in execute(...) method. Follow these tips and you'll be set! ... @Override public String getCommandName() { return "evanesco"; } @Override public void execute(MinecraftServer serverIn, ICommandSender senderIn, String[] args) throws CommandException { EntityPlayer playerIn = CommandBase.getCommandSenderAsPlayer(senderIn); RayTraceResult trace = PointingAt(); if (trace == null || trace.typeOfHit == RayTraceResult.Type.MISS) { SendStatus("§6Whiff!§r"); } else { BlockPos pos = trace.getBlockPos(); World worldIn = playerIn.world; worldIn.setBlockToAir(pos); worldIn.playSound(/* if you want sound to play for all players */ null /* else if only for this player, playerIn */, pos, SoundEvents.ENTITY_ENDERMEN_TELEPORT, SoundCategory.PLAYERS, 1.0F, 1.0F); SendStatus("§5Shoop!§r"); CommandBase.notifyCommandListener("commands.evanesco.success", new Object[0]); } } ... I stripped the code for you, if you wish to use it, you may. I hope I helped. Happy modding!

You'll need to create a copy of IngredientNBT and override Ingredient#apply to perform a partial NBT match instead of a full NBT match. You'll then need to create an implementation of IIngredientFactory that creates an instance of the Ingredient class from the provided JSON object; you can use CraftingHelper.getItemStack to parse an ItemStack from JSON. Register this factory by adding the fully-qualified name to your _factories.json file; you can see an example here. The name you specify for the factory in _factories.json is the name you'll use in the type property of the ingredients in your recipe files. Edit: You might want to use an NBTPredicate for the NBT matching rather than storing a full ItemStack. This isn't really what the OP is looking for, since the conditions are only evaluated once when the recipe is loaded.

Well, I meant it is conceptually more difficult as well as inconsistent with the other registries. You want to register an entity, but you need to wrap that in an entity entry. That would be okay except you can't simply construct that but rather you need to build it through a builder class then chain the methods -- and don't forget to actually call the build() method which is different than create()! Basically, you can see the OP in this thread ran into all the problems conceptually -- initially thought they could register entities directly, finally figured out that they needed a builder for entries but then forgot to do the build(). I guess I'd like it better if it was consistent across all the registries. I think the problem is that Forge is moving to more high-end programmer style -- lots of factories, functional interfaces, builders, and such. These are all really good programming style things and of course the "proper" way to do things. However, I believe it greatly reduces the accessibility to the general modder who is just dabbling. Also, the point with an API is that it is supposed to be a "contract" that is only modified under extreme situations. The amount of work it takes now to port a mod is literally weeks per mod. Forge ideally would be an API that stands the test of time (with all the changes happening invisibly under the hood). This is why there are so many people stuck modding back on 1.7.10 -- they simply can't keep up either conceptually or effort-wise. Basically, I think Forge is doing great stuff but is getting way ahead of the actual modding community both in terms of skill level required as well as simply keeping up porting mods. Heck this morning I upgraded my 1.12.1 mod to 1.12.2 and had to spend some serious time to clear out the errors. That is a problem when a modder like me who tries to keep up and has intermediate Java level has to scratch their head just to keep their previously working mod working. It is really fracturing the modding community -- if you don't believe me go to Minecraft Forums modification development forum and you'll see that only about 1 in 10 questions is about anything after 1.8! I guess I'm hoping that all these big changes get solid soon and then stay stable for a few years. Otherwise it is really disheartening to see all your learning and work get obsolete so quickly.

This is exactly the type of thread I envisioned when I was complaining on the pull request about the complexity of the new registration system... we went from needing a single, easy-to-understand line of code to register an entity to complex set of entries, builders and such. I'm still at a bit of a loss to understand the advantage of the new system. diesieben07 do you understand the advantage / reason that this sort of complexity is needed? I suppose it has something to do with the fact that entities need to be instantiated where other things that are registered (items, blocks, recipes) are singletons?

Just tried it, it crashes. The log: [14:33:39] [main/WARN] [FML/]: Registry EntityEntry: Override did not have an associated owner object. Name: dgm:cheese_boss Value: net.minecraftforge.fml.common.registry.EntityEntry@79ed43f8 My code: public class Entities { public static final EntityEntry CHEESE_BOSS = new EntityEntry(CheeseBossEntity.class, Reference.MOD_ID + ":cheese_boss"); public static final EntityEntry[] ENTITIES = new EntityEntry[] { CHEESE_BOSS }; static { CHEESE_BOSS.setRegistryName(Reference.MOD_ID, "cheese_boss"); CHEESE_BOSS.setEgg(new EntityEggInfo(new ResourceLocation(Reference.MOD_ID, "cheese_boss"), 0xFFFFFF, 0xAAAAAA)); } } @Mod.EventBusSubscriber public class CommonHandler { @SubscribeEvent public static void registerBlocks(RegistryEvent.Register<Block> e) { DeGeweldigeMod.LOGGER.info("Registering Blocks."); e.getRegistry().registerAll(Blocks.BLOCKS); } @SubscribeEvent public static void registerItems(RegistryEvent.Register<Item> e) { DeGeweldigeMod.LOGGER.info("Registering Items."); e.getRegistry().registerAll(Items.ITEMS); for (Block block : Blocks.BLOCKS) { e.getRegistry().register(new ItemBlock(block).setRegistryName(block.getRegistryName()).setUnlocalizedName(block.getUnlocalizedName())); } } @SubscribeEvent public static void registerEntities(RegistryEvent.Register<EntityEntry> e) { DeGeweldigeMod.LOGGER.info("Registering Entities."); e.getRegistry().registerAll(Entities.ENTITIES); } } Tell me if you need more code/stuff.

I used the method canCommandSenderUseCommand. Return true if you want the command to be used always (even with command blocks). If you only want the Player to have access, check if the ICommandSender parameter is an instance of EntityPlayer.