Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 02/02/17 in Posts

  1. Xironite Minecraft Server [1.8.x – 1.18.x] Xironite is a server dedicated to interacting with our community through hosting events and listening to player feedback! Our main feature is Towny! Towny gives our players a chance to work together and try to make the largest town while recruiting more players to help them. If competition is more your speed, you can compete against other towns in a variety of contests! You can do anything you want, from creating the largest town with your friends to dominating the economy and skill leaderboards! Xironite also adds a tonne of features to Survival, making it feel fresh once again. From custom enchants and tools to dungeons and bosses that will test your skills, Xironite has plenty to keep you busy! On top of all that, our player ranks can be earned in-game through playtime and resource gathering. No need to pay for cool perks! Xironite is constantly evolving based on player feedback and ideas from our amazing management. Join now before you miss our next event! How to Join? Join now using our IP: mc.xironite.org Features Bosses Dungeons Crates & Lootbags Events Robust Anti-Cheat Friendly & Active Community Custom Enchants Custom Tools & Armour PyroMining & PyroFishing Player Feedback & Suggestions Custom Textures ...and much more! Social Media Discord Instagram TikTok YouTube
    140 points
  2. Xironite Minecraft Towny Server [1.19.4] Xironite is a dedicated server that connects with our community through hosting exciting events and listening to player feedback. Our standout feature is Towny, where players can come together to build and expand their own towns while recruiting others to join them. If you are competitive, you can also challenge other towns in various contests. With Towny, the possibilities are endless - players can create a thriving town with their friends, establish a robust economy, and climb the skill leaderboards. Xironite breathes new life into the Survival mode with its numerous features. We offer custom enchantments, tools and weapon, dungeons to explore, and challenging bosses to put your skills to the test. Furthermore, player ranks can be earned through gameplay and resource gathering, so there is no need to pay for extra perks. We continuously evolve Xironite based on player feedback and ideas from our fantastic management team. Don't miss out on our next event - join us now and become a part of our thriving community! Server Features Bosses Dungeons Crates Battlepass Events Active Community Custom Enchants Custom Tools/Items Custom Armour Custom Pets Custom Mobs PyroMining PyroFishing Player Feedback Suggestions Custom Textures ...and much more! How to Join? Join now using our IP: mc.xironite.org Social Media Discord Instagram TikTok YouTube Trailer/Cinematic Click here to watch the trailer!
    65 points
  3. Introduction Xironite is an interactive Towny server dedicated to keeping a close-knit community through hosting weekly events and listening to player feedback! Our main feature is Towny! Towny gives our players a chance to work together and try to make the largest town by recruiting residents to help them. If competition is more your speed, you can compete against other towns in a variety of contests! You can create the largest town with the best buildings with your friends or dominate the economy and skill leaderboards! Additionally, we have moved forward towards becoming a Network, where we feature a Creative server. Our new Creative server is perfect for building freely with friends, sketching out builds, and planning your town layout in advance! Xironite also adds numerous features to Survival, making it feel fresh once again. We are able to accomplish this with classes & professions, custom textures, custom enchants, custom weapons & tools, custom bosses & mobs, dungeons, custom Iris world, and so much more! Xironite has plenty to keep you busy by catering to all of your entertainment needs in Minecraft. On top of all that, our player rank perks and other donor store related items can be earned in-game through playtime and resource gathering. No need to pay to win! Xironite is constantly evolving based on player feedback and ideas from our amazing management. Join now today and don’t miss out on our next event! How to Join? Join now using our IP: mc.xironite.org Notable Features Custom Bosses & Mobs Tournaments Dungeons Crates & Lootbags Consistent Events Robust Anti-Cheat Quests Player Economy Casino Friendly & Active Community Custom Enchants Custom Tools & Armor Custom Iris World Classes & Professions PyroMining & PyroFishing Player Feedback & Suggestions Custom Textures ...and much more! Social Media Outlets Discord Instagram YouTube TikTok
    54 points
  4. Update Regarding LTS System: Please read The Big Forge Update Earlier this year, 1.13 was announced and the snapshots started coming out, the update was relatively small, but enough to be a hurdle for mod developers. This combined with 1.12 stabilizing, and a few fundamental Java changes that broke modding in general, made the Forge team decide to use this opportunity and work on cleaning the years of technical debt that Forge had accrued. During this time, it was discovered that a lot of things needed updating. In fact, well, everything did. And so, it was done, a full rewrite of practically everything Forge related. This took a long time, longer than originally anticipated. But what’s the outcome of this you might ask? A lot. cpw’s mod launching system (ModLauncher) allows for parallel mod loading and support for more modern Java versions. (Considering the original was written to target Java 6). The Forge installer now runs tasks at install time once, rather than doing it every time you run the game. These alone provide dramatic reduction in launch times. ForgeGradle, the “devkit” for creating mods, has been rewritten and is faster at, well, everything. It also integrates much better with IDEs. What does that mean, you ask? Simple. Mods are nicer to make. (Also 100% less setupDecompWorkspace.) MCPConfig allows for much easier MCP updates, and is public source too, so people can see exactly what's going on between updates. In short: There was a lot of work to do. And now that it's done, future updates will be much, much smoother. 1.14 and 1.15 The 1.14 release came around, just in time for the rewrite to be finished, so it was time to get the ball rolling again. The bulk of the restructure work was done through 1.13's life, so all that remained was actually seeing how it was to update all of it, and it went pretty well. A lot of improved systems exist now that make developing for these modern versions far easier and just better in general. The 1.15 release was relatively simple, even if Mojang decided to restructure everything and make changes to how the rendering works. (Taking some of our systems in the process, don't worry, this is a good thing.) 1.15's rendering changes were mostly a refactor, and we expect 1.16 to be a large update to rendering. This plus 1.14 seeing growth is why we chose 1.14 to be a candidate for LTS. (More on that further down.) Hopefully this kind of restructure from them is a rare thing in the future, but we welcome the change, since it often brings improvement. Although the rendering changes may pose a tough hurdle for some, the update for most should be relatively straight-forward. Forge support and LTS Forge's support for Minecraft versions will try to follow a predictable cycle, assuming Mojang also follows a predictable cycle. We will always actively target the latest Minecraft version, as ever. We will now also deem a previous major Minecraft version as "LTS" (Long Term Support). The LTS version will receive support for modders and players alike, however all new features must target the latest version first, and then may be backported. An LTS version differs slightly from the latest version, in that any new features you may want to add to it, must target the latest version, only once it has been merged in, can it be backported. (The exception to this is if the feature is non-applicable to the latest version.) The Forge Team will also mostly be focusing on the latest. This is so the community has time to stabilize a bit and gives modpack developers some time to create something special. But still have Forge running full steam ahead. Late last year (Happy 2020!) a vote was held privately with many developers of various Minecraft projects to determine which version will be LTS: Should 1.12 remain LTS or should 1.14? A vast majority chose 1.14, and so, from now on we are dropping 1.12 from support, and 1.14 is now LTS. What does this mean? 1.15 is latest. It will get full support. 1.14 is LTS. It will also get support, and new features, but new features must be made for 1.15 first. 1.12 is no longer supported on this forum, no new features, and no more bugfixes. All other versions are not supported. This means if you come to us for help with those, we will ask you to update. This includes crashes/bugs. To keep with Mojang's history of releases, we expect 1.14 to stay LTS for 12-18 months, giving plenty of time for modders and pack developers alike. However, this may change depending on what surprises Mojang has in store for us. Finally… Thank you. Thank you to all the modders/developers, all the players, and especially to all the contributors. The Minecraft modding community would not be what it is without you. You are responsible for the striving ecosystem we have today. We hope this new year brings you all you desire, and we look forward to seeing what you create. And now time for some shameless plugging, if you like Forge, please consider supporting us. http://www.patreon.com/lexmanos - The Forge Team.
    28 points
  5. 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:
    20 points
  6. As anyone who's started porting to 1.14.2 is probably aware by now, container and GUI creation has changed... quite a bit. To summarise what I've gathered so far: Containers (more accurately: container types) are now registry objects and must be registered in a RegistryEvent.Register<ContainerType<?>> event handler. Container objects themselves must provide a constructor of the form MyContainer(int windowId, PlayerInventory inv, PacketBuffer extraData). This will be used to instantiate the client-side container. Your container's constructor must call the super Container constructor with your registered container type and the windowId parameter (this int parameter is not used in any other way - just pass it along to the superclass constructor and forget about it) You can use the extraData parameter to pass... extra data! to your container. This PacketBuffer parameter is built server-side when you call NetworkHooks.openGui(); see below. Typically, your container will have (at least) two constructors; the factory constructor described above which is used for client-side construction, and a constructor taking whatever parameters you need to pass to set up your server-side container object. Container-based GUI's are now associated with a container type with the ScreenManager.registerFactory() method, which takes a registered ContainerType and a ScreenManager.IFactory to construct your GUI object. Call that in your client-side init code. ExtensionPoint.GUIFACTORY is gone, no longer needed, as is the old IGuiHandler system. ScreenManager does all that work now. While there must be a one-to-one mapping from ContainerType to each GUI, also remember that you can happily re-use the same container class for multiple container types if you need to; just pass the container type as a parameter to your constructor and up along to the Container constructor. All container-based GUI's must provide a constructor taking(T, PlayerInventory, ITextComponent), where the generic T is the type of your container object. Container-based GUI objects are now generified (is that a word?) on the container's class, e.g. public class MyGui extends ContainerScreen<MyContainer> IInteractionObject is gone; instead your tile entity should implement INamedContainerProvider: the createMenu() method is where you create and return your server-side container object. (I believe getDisplayName() is only used to initialize the title field of your GUI object). To open a container-based GUI on the tile entity (server-side), call NetworkHooks.OpenGui(player, myTileEntity, pos) or player.openContainer(myTileEntity) That would typically be called from Block#onBlockActivated() If you want to create a container-based GUI for an item, create a class implementing INamedContainerProvider (a static inner class of the item makes sense, or perhaps an anonymous implementation), implementing createMenu() and getDisplayName() to create and return the container object as above. That would typically be called as something like NetworkHooks.OpenGui(player, new MyItemContainerProvider(stack), pos) or player.openContainer(new MyItemContainerProvider(stack)) from Item#onItemRightClick() or Item#onItemUse() player.openContainer() can be used if you have no need to pass any extra data to the client, e.g. your GUI is just displaying container slots, like a chest. But if your client GUI needs access to the client-side tile entity, use NetworkHooks.openGui() and pass at least the tile entity's blockpos so the client container can get the GUI object. Syncing any necessary TE data to the client-side TE needs to be done separately by whatever means you choose. Note that NetworkHooks.openGui() has a couple of variants to allow extra data to be passed to the client-side container object: a simple pos argument if you just need to pass the blockpos of your TE, or a more flexible Consumer<PacketBuffer> if you have more complex data to pass to the client. The simple pos variant just calls the full-blooded Consumer<PacketBuffer> variant in any case. It's this packet buffer that is received by the client-side container constructor.
    12 points
  7. Don't ask awkward questions. Mojang code is PERFECT, and NEVER NEEDS FIXING.
    9 points
  8. Forge for 1.16.1 The first Forge build for 1.16.1 is now live thanks to the hard work of: covers, illy, jd, garrett, giga, and the rest of the forge crew. With their help we were also able to release the updates to MCPConfig for 1.16 and 1.16.1 the same day that vanilla did. The Nether Update has brought a lot of changes to many systems, and as with any update there are likely to be bugs. We are still evaluating and working on some of the systems like dimensions and trees to come up with the best system to allow for modders to integrate with vanilla’s new dimension system. We are also expecting Mojang to release a 1.16.2 fairly shortly and are prepared to work on updating to it as soon as they do. As with every update, there are bugs and other minor things to be expected. Please report them responsibly and have fun with the new version! Changes to the LTS There are a couple changes happening to the Long Term Support system originally introduced here. We are moving the LTS from 1.14.4 to 1.15.2 to reflect the community being more active and also changing how we chose what version the LTS will be to be more maintainable. We are now going to be supporting the latest (n) and second latest (n - 1) versions, with the reservation of potentially having the LTS being n - 2 if something is Mojang ends up really making a mess of a particular version. That being said we still will be providing critical fixes for all possible versions. Do not worry about 1.14 being instantly dropped while we are still working on updating 1.16, as we have a customary grace period for while everything is still in flux before we start strictly enforcing the LTS rules. New Team Members We are happy to announce we've added a few new members to the Forge team officially. These people have been a part of the community for a while and have been helping out a lot. The first two are new members of the 'Toolchain' team. Which is responsible for some of the backend tools, like the decompiler, update scripts, gradle and other internals. The others are joining our ever growing list of Triage team members. Who are responsible for managing the issues and pull requests on our github. They are the front line of bug reports and feature requests, treat them with respect and listen to what they tell you! Toolchain covers1624 JDLogic Triage AshersLab Curle OrionOnline pupnewfster
    9 points
  9. Forge Version: 1.14.4-28.1.0 Minecraft Version: 1.14.4 Downloads: Changelog (Direct) Installer (Direct) MDK (Direct) Intro: Whelp, the time has finally come, we are ready to do our first Recommended Build for 1.14.4! I want to thank everyone who has helped work on this and get it ready to go. This has been a long road, and I admit it has been a lot longer than I wanted it to be. Unfortunately, some things went wrong, some aspects took way longer than they should have. But we move forward. This is one of the biggest updates to Forge that we have ever done. Everything has been re-written from the ground up to hopefully provide us a platform that will last the next 10 years. Here is a basic overview: Versioning: You may have noticed, that our version number has changed a little bit. This was done to cleanup some redundant information and more directly link our versions to our source code. Our versions are now in the format `{MinecraftVersion}-{ForgeVersion}.{RBNumber}.{CommitCount}`. Launcher: In order for Forge to modify the game, we have to use a system that allows us to modify the java code as it is loaded. Initially we created a system called LegacyLauncher, which we shared with Mojang this allowed them to load their old versions into their new multi-profile launcher. However Java9 was released, and broke it. This is a fundamental change in how Java works and required us to re-design our basic loading system. We now have a new loader called ModLauncher that is designed with Java9+ in mind. So hopefully it works for the next decade! Installer: There are a lot of things that Forge does at startup, some of them is to apply our patches to vanilla's code, and transform vanilla's code to SRG names so that mods can work between minor Minecraft versions. This used to be done every time you started the game. We now do this once, at install time. This will save a bit of time while starting the game. Mods: We have changed quite a bit about the mod loading system, basic mod life cycle events are now run in parallel during Minecraft start. This should help decrease the load time. We have also removed a lot of cruft that has existed since the Risugami ModLoader days. Which will allow for cleaner, more flexible code. Overall the mod dev experience should be a lot better. Coremods: As much as I hate it, mods that edit bytecode will always be a thing. LegacyLauncher had a system that allowed any mod to edit anything in anyway they wished. This has caused a lot of issues due to modders implementing them wrong. The new ModLauncher system has a similar thing in place, however we have also released a new `Coremod` project that is intended to be the default system anyone who was making a Coremod. This new system uses Java's JavaScript engine to isolate the coremod from the rest of the game. Which should solve the most common issues in existing coremods. MDK: We have completely re-written all of our build tools. The new system treats Minecraft and other Mod dependencies as normal gradle dependencies. This means you no longer need to use special 'setupWorkspace' tasks before being able to build your mod. It also means that more systems should be able to support the work space as it is more in line with a basic java work space. We are currently targeting Gradle 4.9, however we have reports that it works all the way up to 5.5. Data Generators: Minecraft uses many data files, typically in the form of a json file. These are used for Blocks, Models, Textures, Recipes, Tags, and so much more. There are some people in the community who think that this is bad because it is difficult to create that many data files. No programmer in their right mind would do that by hand. Mojang themselves have used data generators from the beginning. We finally convinced them to expose this to modders, and Forge has enhanced them for use by Modders. We plan on adding even more features to this system, so feedback is highly appreciated. MCPConfig: Minecraft is released in obfuscated names, since our inception we have use MCP to provide us with the information needed to turn the game into something we can work with. This project started off as a set of python scripts and tools. But now with ForgeGradle and other projects the python is no longer necessary. So we have moved to just providing the Mapping data. This is now a public project which allows more community interaction, and feedback. These mappings are published to Forge's maven, and can be used in any project you wish. The only restriction is that you can't re-distribute and create derivative works. This is purely a technical necessity. These mappings are designed to be stable and compatible across Minecraft versions as best as possible. If multiple mappings were released that conflicted with each other it would cause nothing but a headache. We also worked with the community to design some naming standards, you can view more information on that on github. Mojang's Official Mappings: Starting with Snapshot 19w36a, Mojang has started providing their obfuscation logs. Which in theory is a great asset to modding as it will help people understand the code. However, Mojang released these mappings as All Rights Reserved, which means we can't actually use them in any way. So until they clarify things we will continue to work on Forge and use SRG names for our development/publication. The hope is that Mojang gives us some limited rights so that Modders can use these names in their own mod code, as well as publishing on places like Github. But until that happens I advise anyone who looks at these mappings to be very careful to not use them in anything you publish to anywhere. This include in jar files of your mod, or in the source code you publish to your SCM. We will keep you informed when we get updates from Legal. Fluids: Minecraft introduced the concept of 'waterlogged' for things like stairs, fences, and slabs. This introduced a formalized 'Fluid' system in Minecraft. This has caused us to need to re-write our Fluid system. We are trying to work with Mojang to make the vanilla system more flexible for modders. We will continue to develop this system as modders give feedback and make it as best as possible. Changelog: As Forge and all of it's tools have basically been re-written from scratch, the changelog is huge. You can view the raw changelog here. For more information on all the other tools in the Forge ecosystem you can view our Github. Don't worry, more detailed lists will return in future RB, this one is just to large too aggregate properly. Closing Remarks: This has been a long time coming, to those who are concerned about the time it took. I would like to remind you that now that our major re-write is over, we should be back to our same-day update schedule we have achieved for the last several Minecraft versions. These are major changes, so I would suggest people join our Discord and work with each other to update, find bugs, etc. I fully expect, as with any software release that there will be bugs. Please report them so that we can fix. Some of you may also have noticed, that there are only the direct downloads at the top of this page. This is because we have reached our Patreon goal and removed ad links. Nobody likes ads, but running Forge costs money. We also have a merch store. If anyone is interested. [/shameless promotion] Lets get back to work!
    8 points
  10. Don't tell ppl "do your research before posting here" as the README.txt file that comes with the MDK of Forge 1.13.2 25.0.9 and 25.0.10 says to use setupDecomWorkspace its obvious that the README.txt file was not updated but you don't have to be a dick.
    7 points
  11. From a user standpoint, I don't see much reason to use 1.19.2 over 1.19.3. The lack of content changes means there is no reason to not migrate to 1.19.3 other than mods that never got a chance to update (and to me, it seems unlikely someone who jumped on 1.19.2 would not also jump on 1.19.3) On the other hand, 1.18.2 has been around long enough to build up a decent select of mods. I would rather give it more time for those mods to stabilize and expand then have another short-lived LTS version.
    6 points
  12. Forge Version: 31.1.0 Minecraft Version: 1.15.2 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Intro: This is the first recommended build for 1.15.x! This would of been out a few weeks ago, but Mojang decided to release 1.15.2, so we figured it'd be best to hold off until that version stabilized. As you may have read, we dropped 1.12 support a few weeks ago and now concentrate on 1.14.4 and 1.15.2 until 1.16 drops. 1.15.x brought many changes to the rendering engine and incorporated some parts of the new rendering engine known as "Blaze3D", but this release was still a lot faster than 1.14.x, thanks to the mod loading and launching rewrite we started in 1.13 being complete. Also thanks again through all the contributors for this release that helped to fix bugs and bring new features to forge. Changelog: New: Removed and cleaned up old code Remove third-party vecmath library in favor of using the new minecraft functionality Allow logos in the mod screen to be scaled differently Allow models to override be overridden when using OBJ models Make more Data Generator stuff usable by modders Add support for custom nether portal frame blocks Added new Click Input Event Added entity nameplate rendering event Added support for gui_light model option Re-implemented the ITeleporter interface to allow moders to control dimensional teleporting more easily Allow mods to more easily specify a custom texture for chests Add support for sending fluid stacks over the network more easily Add support for fluid overlay rendering for custom fluids Fixes: Fixed incorrect item lighting Fixed broken stairs and fence rendering Fixed keybindings not saving Fixed items being too small when dropped Fixed mod list screen Fixed capability data not being transferred when returning from the end Fixed incorrect warning screen caused by removed vanilla sounds Fixed game crash with modded entities Fixed bucket rendering Fixed crash when parsing custom obj models Fixed items not being colored correctly with custom colors Fixed items rendering too dark Fixed many other rendering related issues Fixed particles not rendering correctly due to wrong GL state Fixed incorrect item lighting Fixed crash when using certain fonts Fixed crash when building quads for rendering Fixed dyes tag not automatically finding new dyes Fixed Big Mushrooms not generating Fixed Raw Mouse Input Event Fixed fullbright lighting Fixed Fish Bucket not being usable by mods Fixed breaking overlay Fixed Widget Foreground Color not allowing pure black Fixed entities turning on a spot Fixed RenderType loosing it's mapping for registry replacements Fixed extended version of getLightValue not being used everywhere Fixed Wakeup Event not being called at the correct spot Fixed mod resources ordering Fixed Player Changed Dimension event providing the wrong dimension Fixed Keybinds modifier not working correctly Fixed Chunk Data Load Event not fireing Fixed small typos in forge config Fixed restoring blur mipmaps Fixed Right Click Block not being called on client and server Fixed crash on new java 8 versions in development environments Fixed a bunch of events not having the new rendering context Fixed Attacks/Punches not registering Fixed functionality for rails to have different maximum speeds Fixed registry desync, causing entities or sounds to be mixed up when connecting to a server Fixed compression system used by the installer to make downloads smaller.
    6 points
  13. This solved the problem for me First register your entity with custom client factory like this .setCustomClientFactory((spawnEntity, world) -> new ExempleEntity(world)) And then use NetworkHooks#getEntitySpawningPacket to get Entity Spawning Packet @Override public IPacket<?> createSpawnPacket() { return NetworkHooks.getEntitySpawningPacket(this); } that's it ?
    6 points
  14. The problem with most alternative mod loaders, is that they are created out of spite with "Fuck Forge" as their motivation. But then they use our tools, our data, and our work to make their system. That's the thing that pisses me off about things like Rift. I have not looked at Fabric so i can't comment on what they are doing, or if they are doing it correctly/legally. However, I would also advise against using any loader that "gives the hooks to the users", by "exposing" mixins and encouraging the average user to use it. Because that flat out won't work. The reason Forge has compatibility with so many mods is because we've cultivated all the internal hooks as clean changes that make it so modders DON'T have to break things in MC code to make their mods work. So you can get a couple nice mods yes, but it'll become difficult when you start trying to create modern mod packs. As for updating to snapshots. I update the mappings internally when I get time cuz I like seeing what has changed. I would LIKE to make those mappings public but it isn't worth doing as they are not the highest quality and we loose a lot of information. I am looking for people who are willing to help create open source versions of some of the internal tools I use {which I did not create and thus is not my place to release} as well as a better three way binary mapping generator.. If anyone actually wants to help out on that, hop on discord either Forge's or sponge's and we can talk... Anyways, using 3rd party smaller loaders just to explore the new vanilla code is fine. But do not expect stable or useful releases from those.
    6 points
  15. You can view the entirety of Forge 1.13 here: https://github.com/MinecraftForge/MinecraftForge/tree/1.13-pre?files=1 I think that Forge 1.13 is 80-90% done based on: - Forge Gradle 3 is finished (this was the part that unexpectedly took the longest) - I believe the MCP mappings are pretty much done for 1.13 - From what I’ve seen on the comits they’ve managed to get Forge 1.13 (without all the patches) to compile and run (I’m traveling right now so I can’t test it and confirm it myself) - I judge that the rewriting of the mod loading system is probably more than half done as they’ve already merged Minecraft and MCP into 1 “mod” with the new loading system (I think the new loading system is amazing and is a massive upgrade from the previous system) - I think that the remaining 10-20% of work is going to be going through all the patches from 1.12.x and seeing if they still need to exist and if so what changes have to be made to them because of changes to the vanilla code. Here’s the list of patches to review https://github.com/MinecraftForge/MinecraftForge/issues/5162
    6 points
  16. First off, you can't even spell my name right, secondly for those who see this, this is the thread he got a warning for, specifically the post where he called us all assholes http://www.minecraftforge.net/forum/topic/65936-forge-server-error/ As you can see, nobody cussed at him. As for us being assholes, because we are blunt and have rules, and refuse to support older versions does NOT make us assholes. The analogy I like to take is you going to Microsoft, and asking for support with Windows 95. They will tell you to either sod off or pay them a ABSURD amount of money. As for the way we speak to you, like we know 'everything', it's because piratically we do. In regards to the software WE'VE WRITTEN and spent the last 5+ years supporting and developing! You coming in, and failing to follow our directions on the SIMPLEST of errors just shows your arrogance and stupidity. {Note, I used stupidity, and not ignorance, because ignorance implies a ability to update your thinking} As for the youtubers who still play 1.7.10, that's fine. People can PLAY whatever they want. Hell you can {tho its highly discouraged} develop for whatever you want. However the line is drawn with your trying to force US to develop/support the old versions. It's a simple concept, if you want our help, stay updated. If not you're on your own. So ya, your last ban was for a week, you obviously didn't learn your lesson, so now enjoy the lifetime.
    6 points
  17. Locked. JRed you are consistently coming around asking for help with your fucking coremod that I'm fairly sure every member of staff has asked you to stop using, yet you insist on hacking the shit out of everything because you think you know better yet you refuse to prove that your way is better by contributing to Forge directly. I will say this again, if you are having trouble with making a coremod maybe you shouldn't be hacking the shit out of other people's code.
    6 points
  18. I got into minecraft modding recently and was surprised by how hard it is to find useful up-to-date information. Because of that, I decided to document my learning journey and write a book about Minecraft modding for beginners. It applies to Minecraft 1.16.1 and the latest version of forge. Keep in mind it is still a work in progress. More chapters will be added in the coming days. Suggestions and questions also are welcomed. Link: https://thebookofmodding.ml/
    5 points
  19. The forge read the docs wiki is a little out of date. It is a lot easier now. I learnt how to do this from reverse engineering minecraft's and forge's code. I use blender to create my model. A fantastic tutorial on how to create pixel art based models in blender can be found here: To export: go to File>Export->Wavefront (.obj) Your settings should reflect this. This will convert the Blender coordinate system into Minecraft's. When you export your model you will get two files, an obj and a mtl. e.g. block_name.obj and block_name.mtl. The obj file describes the shape of the model while mtl file describes how it looks. Keep both files next to each other. Go into your mod resource directory and place these two files where you want them, e.g. assets/modid/models/block/path Within block_name.obj, make sure the mtllib points to the mtl file. Remember, your obj and mtl file should be next to each other. It should read: mtllib block_name.mtl Still within block_name.obj, make sure the correct material library is being loaded (Ill show you where this is declared in a sec.) (Just scroll down until you find the line, don't write your own) usemtl block_name_mat Your block_name.mtl file should look like something like this when you export it. If it doesn't have all of these lines, don't worry, Minecraft doesn't care too much about these numbers. # Blender MTL File: 'bloomery.blend' # Material Count: 1 newmtl block_name_mat Ns 323.999994 Ka 1.000000 1.000000 1.000000 Kd 0.800000 0.800000 0.800000 Ks 0.500000 0.500000 0.500000 Ke 0.000000 0.000000 0.000000 Ni 1.000000 d 1.000000 illum 2 Pretty much everything here can stay as is. "newmtl" is where we declare the material the obj loads with "usemtl". Make sure these match. Next we need to let Minecraft know where to find out texture. Still within block_name.mtl add a map_Kd line below newmtl. If you forget this line, Forge will still load your model, but it will be all white. newmtl block_name_mat map_Kd modid:block/path/block_name Ns 323.999994 Ka 1.000000 1.000000 1.000000 Kd 0.800000 0.800000 0.800000 Ks 0.500000 0.500000 0.500000 Ke 0.000000 0.000000 0.000000 Ni 1.000000 d 1.000000 illum 2 Place your texture within assets/modid/textures/block/path. The map_Kd should point to this location. Next, create a blockstate file for your block as normal. [block_name.json]. This will load a json model file. This has to be next to your obj and mtl files. { "variants": { "": { "model": "modid:block/path/block_name" } } } Block Model [block_name.json] { "loader": "forge:obj", "model": "modid:models/block/path/block_name.obj", "flip-v": true } Enabling flip-v will depend your model file. This just flips the way the texture is applied. If your texture looks upside down, change this to false. Your assets folder structure should look like this now: assets/modid/ blockstates/ block_name.json models/block/path/ block_name.json block_name.obj block_name.mtl textures/block/path/ block_name.png
    5 points
  20. All versions are supported under our new tiered support policy. Full support is currently offered for 1.20.4, 1.20.1, 1.19.4 and 1.19.2. Other versions fall under the legacy or minimal tiers (details on what that means can be found here) Currently Supported Versions (full support tier): Current: 1.20.4 "LTS"/ESR*: 1.20.1, 1.19.4 and 1.19.2 *Extended Support Release User Support FAQ Modder Support FAQ and Common Issues Discord server We do not currently provide support or updates for any other versions except in cases of severe security issues. On LTS's: Forge's support for Minecraft versions will try to follow a predictable cycle, assuming Mojang also follows a predictable cycle. We will always actively target the latest Minecraft version as ever, however we will also support the most recent non-latest version as an "LTS" version. An LTS version differs slightly from the latest version, in that any new features you may want to add to it, must target the latest version, only once it has been merged in, can it be backported. (The exception to this is if the feature is non-applicable to the latest version.) The Forge Team will also mostly be focusing on the latest. This is so the community has time to stabilize a bit and gives modpack developers some time to create something special. But still have Forge running full steam ahead. This thread is here as a landing page for the "Currently Supported" Announcement at the top of every forum page
    5 points
  21. In honor of this thread, Im going to quickly summarise what I have gathered about creating villagers professions in 1.14.4 (forge 28.1.109) as there is not really that much information about that available right now. If anyone sees me doing something wrong or saying bs, just let me know and I will fix it. Specifically the reflection fix I mention below. EDIT: Make sure you check the first couple replies as well. Source for all of this can be found specifically in this commit: https://github.com/CAS-ual-TY/GunCus/commit/817848784868f4e8362d4270be6f8fc19863dc42 Tho I have done a few extra things which are unrelated so dont wonder. PointOfInterestType If you check out the vanilla class, you could come to the conclusion, that these are generally types of points of interest for villagers. You have the blocks in there that give the villagers their professions (eg. the Armorer type has a Blast Furnace passed to the constructor), you have a Bed type for sleeping, Unemployed type, Meeting type, etc. (But most importantly you have all the professions). You make your POITypes in the forge registry event for that (Register<PointOfInterestType>) (dont forget to set the registry name). Constructor is: String name, Set<BlockState> blockStates, int maxFreeTickets, SoundEvent workSound, int something. Name seems to just be the lower case name (eg. "fletcher", "leatherworker" etc.), the blockStates are just all block states of the interest block. There is a helper method for this (unfortunately its private, so youll have to figure something out for yourself) which I will post below. Next you have what it seems to be the amount of villagers that can use this at once. All vanilla professions have this at 1. Next you have the work sound. I just use vanilla sounds here, so youll have to check yourself if your sound event public static final instances are populated already at this point. And finally you have another integer which I have no idea about. All vanilla professions have this at 1 too. VillagerProfession Now we create the villager profession. This is the type of profession a villager can have (eg. Flether, Weapon Smith etc.). We use the forge registry event for this again (Register<VillagerProfession>) (again, dont forget to set registry name). Constructor: String nameIn, PointOfInterestType pointOfInterestIn, ImmutableSet<Item> noIdea, ImmutableSet<Block> noIdeaAgain. The name is the lowercase name again (eg. "fisherman", "mason" etc.). This is needed for the texture and translation (see below). Next you pass the PointOfInterestType for this profession (read above that this is). Since P comes before V, these are already registered and object holders are populated, so you can just pass your static fields here. The 2 sets that come now I havent really looked into because all vanilla professions just pass an empty set here (ImmutableSet.of()). Profession Texture Location assets\MOD_ID\textures\entity\villager\profession\PROFESSION_NAME.png You just have to put the texture in the appropriate location. Rendering is done automatically. If you want to play around with the model a bit (eg. change the hat), check out the vanilla villagers. You can do that by adding extra PROFESSION_NAME.png.mcmeta files to the same location. Just check out vanilla for examples: assets\minecraft\textures\entity\villager\profession Profession Trading GUI Title Translation entity.minecraft.villager.MOD_ID.PROFESSION_NAME This is the key for your .lang file. Translate this to set the title of the trading GUI. At first I was confused, because there is 2 mod ids in there (mine and minecraft). But it makes sense because the villager is part of minecraft, but the professions part of *MOD_ID*. So ye. Adding Trades to Professions Forge has 2 events for that: VillagerTradesEvent, WandererTradesEvent. You can add trades to any profession here. 1st one allows to add trades to every profession and their levels (1-5, novice to master or smth). 2nd one allows to add generic or rare trades to the wanderer. I highly suggest checking out the vanilla trades to have an idea what (or how much) to set here for all the params: https://minecraft.gamepedia.com/Trading#Armorer - To do the first: Call event.getTrades().get(level).add(some_ITrade_instance_or_lamda_action). To do this for the profession you want, check if event.getType() == ModVillagerProfessions.YOUR_PROFESSION (this event gets called once for every profession). - To do the second: Just check out the event class. Pretty simple. Easy getters easy life I have made a helper class for this to allow easy trade creation. I will post it below. Example usage of this helper class (adds a trade to level 1; You can buy 2-4 (picked randomly per villager, but steady) acacia fences for 12 emeralds): event.getTrades().get(1).add(new RandomTradeBuilder(8, 10, 0.05F).setEmeraldPrice(12).setForSale(Items.ACACIA_FENCE, 2, 4).build()); Final Reflection Fix Im just going to quote what I have written on forge discord. See below for fix (in helper section, call for every POIType in your init): ------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------ Helper Stuff (use this as you please) Get all Block States static Set<BlockState> getAllStates(Block block) { return ImmutableSet.copyOf(block.getStateContainer().getValidStates()); } Easy/Random Trades Builder package here import java.util.Random; import java.util.function.Function; import net.minecraft.entity.merchant.villager.VillagerTrades.ITrade; import net.minecraft.item.Item; import net.minecraft.item.ItemStack; import net.minecraft.item.Items; import net.minecraft.item.MerchantOffer; public class RandomTradeBuilder { protected Function<Random, ItemStack> price; protected Function<Random, ItemStack> price2; protected Function<Random, ItemStack> forSale; protected final int maxTrades; protected final int xp; protected final float priceMult; public RandomTradeBuilder(int maxTrades, int xp, float priceMult) { this.price = null; this.price2 = (random) -> ItemStack.EMPTY; this.forSale = null; this.maxTrades = maxTrades; this.xp = xp; this.priceMult = priceMult; } public RandomTradeBuilder setPrice(Function<Random, ItemStack> price) { this.price = price; return this; } public RandomTradeBuilder setPrice(Item item, int min, int max) { return this.setPrice(RandomTradeBuilder.createFunction(item, min, max)); } public RandomTradeBuilder setPrice2(Function<Random, ItemStack> price2) { this.price2 = price2; return this; } public RandomTradeBuilder setPrice2(Item item, int min, int max) { return this.setPrice2(RandomTradeBuilder.createFunction(item, min, max)); } public RandomTradeBuilder setForSale(Function<Random, ItemStack> forSale) { this.forSale = forSale; return this; } public RandomTradeBuilder setForSale(Item item, int min, int max) { return this.setForSale(RandomTradeBuilder.createFunction(item, min, max)); } public RandomTradeBuilder setEmeraldPrice(int emeralds) { return this.setPrice((random) -> new ItemStack(Items.EMERALD, emeralds)); } public RandomTradeBuilder setEmeraldPriceFor(int emeralds, Item item, int amt) { this.setEmeraldPrice(emeralds); return this.setForSale((random) -> new ItemStack(item, amt)); } public RandomTradeBuilder setEmeraldPriceFor(int emeralds, Item item) { return this.setEmeraldPriceFor(emeralds, item, 1); } public RandomTradeBuilder setEmeraldPrice(int min, int max) { return this.setPrice(Items.EMERALD, min, max); } public RandomTradeBuilder setEmeraldPriceFor(int min, int max, Item item, int amt) { this.setEmeraldPrice(min, max); return this.setForSale((random) -> new ItemStack(item, amt)); } public RandomTradeBuilder setEmeraldPriceFor(int min, int max, Item item) { return this.setEmeraldPriceFor(min, max, item, 1); } public boolean canBuild() { return this.price != null && this.forSale != null; } public ITrade build() { return (entity, random) -> !this.canBuild() ? null : new MerchantOffer(this.price.apply(random), this.price2.apply(random), this.forSale.apply(random), this.maxTrades, this.xp, this.priceMult); } public static Function<Random, ItemStack> createFunction(Item item, int min, int max) { return (random) -> new ItemStack(item, random.nextInt(max) + min); } } Reflection Fix private static Method blockStatesInjector; static { try { blockStatesInjector = PointOfInterestType.class.getDeclaredMethod("func_221052_a", PointOfInterestType.class); blockStatesInjector.setAccessible(true); } catch (NoSuchMethodException | SecurityException e) { e.printStackTrace(); } } public static void fixPOITypeBlockStates(PointOfInterestType poiType) { try { blockStatesInjector.invoke(null, poiType); } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException e) { e.printStackTrace(); } }
    5 points
  22. You need to set the render layer using RenderTypeLookup#setRenderLayer within your FMLClientSetupEvent to make blocks transparent. It takes in two parameters: the block and the RenderType. The RenderTypes are as follows: Solid - field_228615_R_ Cutout Mipped - field_228616_S_ Cutout - field_228617_T_ Translucent - field_228618_U_ Translucent (No Crumbling) - field_228619_V_ Leash - field_228620_W_ Water Mask - field_228621_X_ Glint - field_228622_Y_ Entity Glint - field_228623_Z_ Lightning - field_228624_aa_ What you are looking for is either cutout mipped or cutout so use either RenderType#field_228616_S_ or RenderType#field_228617_T_ to accomplish this.
    5 points
  23. I know this topic is a bit old, but I just had the same issue and a Google search points here. If your packet is working correctly, and its just the warning in the log, you've likely made the same mistake as me. Inside the "messageConsumer" you provided when registering your packet, you need to set the packet handled flag to true. "context.get().setPacketHandled(true);" If it isn't set to true, NetworkHooks.onCustomPayload will return false, and ClientPlayNetHandler.handleCustomPayload will post the warning
    5 points
  24. One way is to use a method that always returns null but suppresses IDEA's warnings, like this: method, usage The newer way is to use the DeferredRegister system that was introduced relatively recently. I've started updating to this, but it doesn't look like I've pushed any of my changes to GitHub.
    5 points
  25. I wouldn't say I know enough Java to pr Forge, so I will instead make my suggestion here. I think it would be useful if there was a ShieldBlockEvent of some sort, which is fired when an an attack is blocked by a shield. I would assume you could get the DamageSource of the attack along with the shield item from the event.
    5 points
  26. As there have been few attempts to create this functionality (that I can find) I decided that I'd have to do this myself. And seeing as it boodly doesn't exist anywhere, I thought I'd share. It does not extend GuiTextField, though it probably could, but it was easier to just take everything that was GuiTextField and make a new class and just make changes as needed, particularly as a lot of GuiTextField's fields were private and thus not visible to a subclass (using getters and setters was frustrating, as many setters either didn't exist or had annoying side effects, such as ignoring newlines and up/down arrow keys). https://gist.github.com/Draco18s/2b02762b597e67a9b887aed241f25077 Known issues: Minimum height of 2 lines enforced (are you really going to complain?) Does not support multi-line selections (they are trouble some to handle; rendering, copying, etc) Does not feature a scroll bar (yet) Mouse wheel scrolling clamped to range that keeps the cursor within the visible text box range (technical limitation; could be overcome, but the limitation relates to automatically scrolling the cursor into range when using the arrow keys) Page up/down not supported (yet) Sometimes the selection highlight appears in edge-case situations that cause the cursor to reposition due to another (e.g. moving from one line to another when pasting multi-line content, etc) Up/down arrow cursor movement is "by column" rather than "by rendered position" as I can't be arsed to figure out where the carat should go instead (my usage will be moving to a monospaced font, where those two values are the same).
    5 points
  27. I have no sympathy for you players who use Netease, their entire business model is bad and abuses the hard work that we here at Forge, and other modders do. If they want to start complaining that I don't produce Forge fast enough, then they can start helping out. But no they just sit back, toss DRM onto things, and just rake it in. It'll be done when it's done.
    5 points
  28. Seriously, Use the event not the static registries. Timing of registration is important. So stop doing it in random places. I was tempted to name the event 'RegisterYourStuffHereAndStopBreakingEverythingElseSeriouslyStopRegisteringYourCrapInRandomPlacesItBreaksThingsAndHoldsUsBackFromBeingAbleToDoCoolThingsThatWeveBeenWantingToDoForFourYearsNow' but I decided against that as it was a bit long
    5 points
  29. @DifferentiationIt is good that you understand the rules of the forum, and also nice that you're actively particpating and interested in modding. However, the only people that should enforce the rules are official moderators. It is even okay to suggest someone should spend time learning more Java, but some of your posts are literally telling people to "go away" or "we're not going to support that". No one except official moderators should ever tell someone to go away or try to draw a line over support. Now I often see people who post and I can tell that they're likely going to need a LOT of help, or want to do something they probably shouldn't. In those cases I simply don't respond. Sometimes other people will, sometimes not, but it is up to them if they want to spend the time supporting someone. One other thing to note is you never really know who the person posting is. Perhaps it is a younger kid. Perhaps it is someone with some special needs. So it is best to always err on the side of compassion and tolerance even if they seem a bit misguided. Anyway, please leave the rules to the moderators -- our moderators do a good job. If someone posting annoys you then just don't respond to their thread.
    5 points
  30. Hey Lex, all the words I have stated against you were a result of a long time of bearing a grudge against you. Now, I would like to make things right. When IItemRenderer was originally deprecated, I searched up real quick to see if anyone else was having an issue with the code not being called. I found a thread about it, with you replying to them with something along the lines of it won't be added back since copy-pasters constantly screw it up. At that moment, a grudge formed against you, from my eyes it looked like this: "Because you couldn't tolerate copy-pasters, you made us real programmers suffer too!!!" Since soon after 1.8's release until now I have had this grudge against you. But then this guy comes along asking me to update to 1.11.2. I say no, since IItemRenderer was removed by the forge devs.(As you already know, since he doesn't respect privacy and posts everything that I sent to him back here). After the discussion of this thread, he comes back to me and says all sorts of rude insults, such as lazy and stupid. I proceed to tell him something along the lines of "I make free content for fun, and you treat me this way? Ha! The only profit I have made from this mod was a couple people who love it so much they wanted to donate. I don't even use adf.ly! I haven't made enough from this mod to pay for a week's worth of groceries, I have an actual job for that! This is just for fun!" After sending him that, I started brushing my teeth, and then I started thinking. Your a free content maker too, just like me. You put up with ungrateful, rude people all the time, just as I do. The more I thought about it, the more glad I was that this situation happened. I literally started to smile when I realized I was finally free from my grudge against you, no longer had to carry those negative feelings on me(negative feelings are weighty, I'm sure you can agree.) I also started thinking back to that old thread that I read, and how much it would piss me off if I were you and copy-pasters caused tons of reports to come to you about the GL mess that they made. I completely understand your decision now. Whenever someone has asked me to update my mod, I used "IItemRenderer was removed by the forge devs" as an excuse, due to the grudge I bore against you. The real reason is because my goal is to make a World War 2 mod that stretches across all the theatres of WW2, something that no game has ever done. It is my dream to be able to play such a game, and updating my mod would cause a lot of hindrances to that dream. Of course, the removal of IItemRenderer did add to that a bit, but it was mainly the fact that because 1.7.10 is the currently the most used version by the community due to the wealth of mods for it(like 1.6.4 was for a long time), I would be forced to maintain multiple versions of the mod to satisfy both the majority and the minority, which is time consuming. Time is precious, and with a job having to maintain multiple versions would hinder my dream a ridiculous amount. Once my dream is realized, I will most likely update the mod. It was so much easier to just blame everything on you, than type out my complicated, emotional, real reason. Everyone else just accepted my answer. But then today all that changed through one very determined user.... I came here to make things right. I sincerely apologize for all this drama. Though you never knew it all this time, I also apologize for bearing a grudge against you. It was wrong of me. Will you forgive me for feeling that way? Side Note: Thank you Pop Cat, for indirectly making me realize the similarities I share with Lex, and how my grudge against him was wrong. If it weren't for you, I might have never let go....
    5 points
  31. Super duuuuper necro post, but for anyone who finds themselves here after trying the srgExtra line, it's been changed in newer versions of gradle (2.2-SNAPSHOT I know, but maybe even earlier). Now instead of doing: minecraft { ... srgExtra "PK: ..." } You have to do: reobf { jar { extraLine "PK: ..." } } Relevant XKCD: https://xkcd.com/979/
    5 points
  32. This FAQ has many guides and solutions - reading this before asking for help could save you a lot of time, as it accounts for the vast majority of issues people run into that we're aware of but can't fix on our end. Supported versions and platforms We only support Forge here. We cannot help you with Fabric, Spigot, etc... We support all versions under the tiered support policy. Full support for 1.20.4, 1.20.1, 1.19.4 and 1.19.2 Legacy support for all other versions Minimal support for select versions (e.g. 1.20.3 - use 1.20.4 instead) More details here. Rules Piracy (aka "cracked launchers") and cheats (aka "PvP clients", "x-ray mods", etc...) are strictly forbidden here. When you need help, please always make a new thread. Do not post in old support threads. When making a new thread, you must include a link to your log on https://pastebin.com or https://paste.ee. Instructions on where to find this and how to upload it are in this forum post. Exit/error codes Here's a list of exit codes and what they mean: Error code 0: Someone clicked "Quit game" and the game closed successfully Error code 1 and -1: The game crashed, refer to the log and/or crash report for details Error code -1073741819: A game library crashed. Update your drivers and make sure you're using the right Java version Where can I find the debug.log and crash report? Official Minecraft launcher CurseForge app MultiMC/PolyMC/Prism launcher Where can I find the installer log? Where can I find the launcher log? Most of the time you don't need to share this, so only share it when asked by a support volunteer or when you're unable to find any debug.log or crash report. Official Minecraft launcher CurseForge app What version of Java do I need? | Minecraft version | Forge version | Java version | |-------------------|---------------|--------------| | 1.18 or newer | 38.x or newer | 17 | | 1.17.1 | 37.x | 16 | | 1.16.5 or older | 36.x or older | 8 | How do I install Java? Windows macOS Linux How do I install the Forge client to the official Minecraft Launcher? How do I install the Forge server? Where can I find the forge.jar to start my server? Forge immediately crashes on launch without any mods installed, how do I fix it? Where can I find Forge mods? https://www.curseforge.com/minecraft/search?page=1&gameFlavorsIds=1 Make sure you download the right version of a mod for your Minecraft version. My game is lagging, how can I find the culprit? How do I update my drivers?
    4 points
  33. Forge Version: 1.12.2-14.23.5.2768 Minecraft Version: 1.12.2 Downloads: Changelog (Direct) Windows Installer (AdLink) (Direct) Other Installer (AdLink) (Direct) MDK (AdLink) (Direct) Universal (AdLink) (Direct) Alright boys and girls it's that time again. Even tho the Forge team is working hard on 1.13 development, which is going well, we have almost all the final tools finished and the installer working, we have not left 1.12 stagnate. There have been many bug fixes, features, and exploit fixes in this new version. Minecraft Forge 14.23.5 Changelog: ============================================================================ New: Cleaner error handling for mod exceptions thrown during loading. Stricter validation of recipes to prevent exceptions and issues on clients. Reworked server console and input handling. Cleaner dimension management code. Performance improvements. New Farmland Trample Event. New Fluid Place Block Event for when fluid changes blocks in world. Added support for FluidStack-dependant colouring to Forge bucket Allow configurations of log levels using system properties: forge.logging.console.level, forge.logging.file.level, forge.logging.debugFile.level Better rendering of models that use the Forge fluid model. Extended IItemHandler to better control what items can enter the inventory. Added custom background image support for creative tabs. Added swim speed attribute to living entities. New resource type sentitive resource reloading. This is disabled by default as it can break some mods that assume old behavior, however it can be enabled in the Forge config. Improved performance of FluidRegistry.getBucketFluids. New SleepingTimeCheckEvent to add yet another way to control sleeping. Removed BlamingTransformer, we run naively on Java 8 now so we do not need to track java version. Optimized some class transformers to improve loading times. Allowed the universal bucket item to update to new fluids when mods get swapped in and out. New event to handle game rule changes. Increased world gen entity spawning performance. Bug Fix: Fixed names in JSON annotation data not matching expected format. Fixed crash from search tree processing invalid recipes. Fixed black flickering on animated models by clamping max diffuse lighting multiplier to 1.0. Fixed scala mods crashing with the json annotation cache. Fixed structure template processors causing cascading world generation. Fixed vertex lighter using stale normal data. Fixed AutomaticEventSubscriber error message. Fixed memory issue related to missing/broken models. Fixed flickering leaves when mods break the blurMipmap settings. Fixed model loading issues when mods declare generic models AND specific models for the same item. Fixed vanilla issue with breaking animation. Fixed FML entity network spawning not using EntityBuilder's factory. Fixed NPE when sleeping in some custom beds. Fixed some ClassCastExceptions incorrectly being logged in FML handshake. Fixed ISpecialArmor to allow for "Unblockable" damage to be handled if the armor opts in. Fixed player movement status not syncing when traveling across worlds. Fixed ItemHandlerHelper.giveItemToPlayer creating item entities with incorrect contents. Fixed potential deadlock when chunkload raises non-IO exception Fixed onItemUseFirst being called when entire actions were canceled. Fixed color events not being fired for mesa and swamp biomes. Fixed received data for last vertex format element not being recorded. Fixed SlotItemHandler.isItemValid check. Fixed Redstone and RedstoneDiodes placement on modded blocks that use BlockFaceShape.SOLID for Top. Fixed loading languages with no underscore in the name. Fixed ModList cache never being updated. Fixed overworld spawn point reset when respawning in another dimension. Fixed modded packets not being able to be sent during ServerConnectionFromClientEvent. Fixed server watchdog thread occasionally crashing on first run. Fixed saved toolbars not working with non-vanilla items. Fixed class loader issue with some apache libraries used by mods. Fixed --mods and --modListFile arguments not making it past LaunchWrapper. Fixed vanilla chunk loading issue related to mounted entities. Fixed vanilla entity tracking issues that caused potential duping exploits. Thanks Aikar.
    4 points
  34. @LenManos Your staff / mods / whoever works with you was complaining about my mod code and cussing at me as well, and even other people i know said the forge forms are assholes to everyone and idc if i get baned. because you cant speak to someone like that saying you know everything. & you all so stop saying well we dont support this version any more youtubers still play with 1.7.10 & above so you really need to think twice
    4 points
  35. It took me a single google search to find that Computercraft is now opensource on GitHub and has a 1.12.2 alpha build on CurseForge...
    4 points
  36. As Draco18s is pointing out, you need to fully understand how Minecraft handles blocks. What you just said is closer to what you need to do, but we want to make sure you understand why. Basically, from a "normal" object-oriented sense you would have a Block class and you would create an instance of it every time you had a block placed in the world. Logically this is good, but it has a bad consequence for performance -- the number of instances gets very large very fast. In just one chunk there is 65k possible positions to place a block so a world of just 20 chunks is going to have 1.2 million possible blocks. So if there was a instance for every block placed in the world there would be a serious problem with memory. So instead, Minecraft decided to have a single instance of each block class and instead create a "map" of where they are placed. That works great if the blocks are simple and unchanging as it is a very compressed format. However, of course they then added the idea that some blocks might want to be varied. To do this they allowed a little bit more (just 4 bits) of data for each block position to allow variation -- this was called metadata. Some blocks used this for things like color (dyed wool), and some used it for direction, etc. But the key point is that the information that represented these things was stored in the "map" NOT in the block instance or class. There was no field in the wool class for the color, rather when the wool was rendered it looked up the data stored in the world data and applied the color then. Now, the block class code sometimes needs to behave differently based on the metadata. Originally that was literally a matter of decoding the 4-bit values (that is why various Minecraft wikis and such you'll still see tables showing the values). But eventually this got more advanced implementation using properties and block states. Basically every combination of values of the properties creates possible blockstate. But ultimately these are still stored in a limited 4-bit mapping. So putting it all together it means that you shouldn't confuse scope (like public or private or static or whatever) with this issue. Rather you must contain all your per-position information within a property, not within fields of the class itself. Okay, assuming you understand all this... just look at other blocks which already do similar things, like a furnace or torch or something, and adapt their code to your specific need.
    4 points
  37. williewillus is maintaining a primer on the 1.13 changes here: https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a It'll be significant work for modders but I'd say considerably easier than 1.7 -> 1.8 was.
    4 points
  38. In my case 'preview_OptiFine_1.12.2_HD_U_C8_pre' prior to 12-18-2017 was causing chests not to open. I DL'd the 12-18-2017 version that is compatible with forge 2577 and the chests open as before.
    4 points
  39. serverSideOnly just tells the client to skip loading the mod if it's installed, you need to set the acceptableRemoteVersions property to "*" as well. This tells it to accept any remote version, including none.
    4 points
  40. Jesus. This argument is pointless. What does it matter what they want to do? If you don't want to help someone, just ignore them. End of story. If other people decide not to help them based on reasons such as not knowing Java (and you really should learn basic Java in order to mod) then that's fine too. This argument is just cluttering up the forum with nonsense. I don't have anything else to say, but there's already an answer in this thread on how to track clicks per second, assuming that the MouseInputEvent exists on 1.8.9.
    4 points
  41. Forge Version: 1.12.1-14.22.1.2478 Minecraft Version: 1.12.1 Downloads: Changelog (Direct) Windows Installer (AdLink) (Direct) Other Installer (AdLink) (Direct) MDK (AdLink) (Direct) Universal (AdLink) (Direct) With 1.12.2 on the horizon, I figure its about time for a RB. We've done a few bug fixes, performance improvements, etc. We're still working on flushing out Mojang's JSON data system. But this is being held up by modder's not wanting to say what they need. So my hopes is that people will start testing out the changes and working with us to move the data system forward. I want to take this moment to re-iterate that we are proposing a new standard for the community in reguards to CoreMods. This standard has been agreed upon by most of the major players in the Minecraft community. You can read more in the announcement. These are proposed for technical reasons so that hopefully in the future we can start moving the engine/game forward. Minecraft Forge 14.22.1 Changelog: ============================================================================ New: Added @ObjectHolder scanning to vanilla MobEffects, Biomes, Enchantments, SoundEvents, and PotionTypes constants. Optimized ExtendedBlockState.getClean() speeding up block updates. Added rotation origin variable for animated models Added partialTick to RenderLivingEvent Improved Furnace fuel functionality and performance. Added spawner flag to CheckSpawn event. Added logging snitcher when using System.out/err Quieted down warning for missing translation files. Added support for custom FontRenderer for tooltips in Creative GUI Added support for NBT icons in Advancements Removed unnecessary maxStackSize restrictions on brewing potions. Optimized some patches for performance/cleanliness. Now firing RemapEvent when reverting to Frozen state. New Recipe Registry events after JSON recipes are loaded. Added support for vanilla "nbt strings" in json recipes Added logging for coremods that do not package separate Jars. Made Optional.Interface repeatable Added support for custom Shields and Shield disabling weapons. Added limiting to Server to Client capability packets. Added support for oredict dyes to Fireworks, Armors, and Shulker recipes. Added support for placing buttons and levers on modded blocks. Sneaking will now bypass villager interactions like other entities. Added pages to the advancements GUI to allow for unlimited root advancements. Added CriticalHitEvent to allow more control over whether a attack is a critical or not, and what damage it does. Cleaned up Forge config files. Increased performance of ticking tile entities. Added GuiContainer Foreground render event. Add smarter getter for block slipperiness Bug Fix: Fix BiomeDictionary not collecting it's list correctly. Fixed incorrect default resource location of potion registry Fixed missing messages of missing models Fixed unblockable damage being blocked by armor. Fixed log spam when creating dummy blocks. Fixed override duplication caused by bad comparison. Fixed getting missing models for overridden Item registry entries Fixed JOpt version on the dedicated server not matching client. Fixed packet encoding issues. Fixed Recipe Toast crash when granted more than 5000 recipes Fixed MC-68754, Screen is not resizeable after exiting fullscreen due to LWJGL bug Fixed crashes related to the RecipeBook and unknown Recipes. Fixed EnumHelper for CreatureTypes Fixed game freeze when resizing the window too small on the mods gui Fixed "Binary patch set is missing" error in dev environment Fixed issue where rendered held items wouldn't properly update when the reequip animations isnt shown. Fixed invalid erroring case during loading Advancements form mods that don't have advancements. Fixed tripwire statemap not being complete when mappings change. Fixed crops dropping incorrect items with fortune. Fixed server not handling item usage when client cancels it. Fixed death loop due to zero max health (MC-119183) Fixed FML handshake race condition Fixed overrides not being applied over the network. Fixed swapping of finite fluids with negative densities. Fixed the firing location of InputEvent.MouseInputEvent Fixed Armor bar disappear after changing dimension. MC-88179 Fixed bug where config categories errored if they contained regex special characters. Fixed issue where client comparators WOULD sync with server. {Vanilla bug we had to re-introduce because of vanilla mechanics =.=} Fixed vanilla server icon. Fixed stacked entity item rendering using the wrong transform for the extra items. Fixed Boats rubber banding when dismounted. MC-119811
    4 points
  42. I'm brand new to modding and a noob programmer. I learned the old way to register blocks and items using GameRegistry.register() then I found out there is actually a new, better way to register blocks, items, and even models. The new way is to use RegistryEvents and I'm a sucker for new and better things so I tried to figure out how it works. My goal with this post is to see if anything I did can be done better and whether or not this is correct. Just because it works doesn't mean it's correct. I want to have a solid base before I build on it too much. Here is what I came up with: RegistryEventHandler.java @Mod.EventBusSubscriber public class RegistryEventHandler { @SubscribeEvent public static void registerBlocks(RegistryEvent.Register<Block> event) { event.getRegistry().registerAll(ModBlocks.BLOCKS); Utils.getLogger().info("Registered blocks"); } @SubscribeEvent public static void registerItems(RegistryEvent.Register<Item> event) { event.getRegistry().registerAll(ModItems.ITEMS); for (Block block : ModBlocks.BLOCKS) { event.getRegistry().register(new ItemBlock(block).setRegistryName(block.getRegistryName())); } Utils.getLogger().info("Registered items"); } @SubscribeEvent public static void registerModels(ModelRegistryEvent event) { for (Block block: ModBlocks.BLOCKS) { ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory")); } for (Item item: ModItems.ITEMS) { ModelLoader.setCustomModelResourceLocation(item, 0, new ModelResourceLocation(item.getRegistryName(), "inventory")); } Utils.getLogger().info("Registered models"); } } ModBlocks.java public class ModBlocks { public static final Block[] BLOCKS = { new BlockTinOre("tin_ore", Material.ROCK), new BlockTinBlock("tin_block", Material.ROCK) }; } ModItems.java public class ModItems { public static final Item[] ITEMS = { new ItemTinIngot("tin_ingot") }; } BlockTinOre.java public class BlockTinOre extends BlockBase { public BlockTinOre(String name, Material material) { super(name, material); } } BlockTinBlock.java public class BlockTinBlock extends BlockBase { public BlockTinBlock(String name, Material material) { super(name, material); } } BlockBase.java public class BlockBase extends Block { BlockBase(String name, Material material) { super(material); this.setRegistryName(Reference.MODID, name); this.setUnlocalizedName(this.getRegistryName().toString()); } } ItemTinIngot.java public class ItemTinIngot extends ItemBase { public ItemTinIngot(String name) { super(name); } } ItemBase.java public class ItemBase extends Item { ItemBase(String name) { this.setRegistryName(new ResourceLocation(Reference.MODID, name)); this.setUnlocalizedName(this.getRegistryName().toString()); } }
    4 points
  43. Use Minecraft's Structure Blocks to save a structure to NBT, which you can then use in code to load the structure. Create a new Template instance with the resource location of your structure.nbt file, and call Template#addBlocksToWorld to spawn the structure. You can do this in your WorldGenerator class.
    4 points
  44. Forge Version: 1.12-14.21.1.2387 Minecraft Version: 1.12 Downloads: Changelog (Direct) Windows Installer (AdLink) (Direct) Other Installer (AdLink) (Direct) MDK (AdLink) (Direct) Universal (AdLink) (Direct) Minecraft 1.12 has been released! And we have finally gotten the big breaking changes in and Forge should be in a fairly stable state! 1.12 has brought a lot of changes, most notably the new Json based recipe system. This was a major hurdle to get over as we had to expand this system to support modded recipes. And to support the many different ways modders interact with crafting. We also had to re-write a large section of internal Forge code due to how Mojang implemented the new crafting guide book. Mojang also is now forcing Java 8 in the vanilla client. Which broke quite a few things related to how we decompile Minecraft itself. Which required me to re-write large portions of the decompiler we use. Overall there was a lot of things changed and due to this there are no doubt still issues in these systems. However I am wanting to push out this release so that we can switch the official development to 1.12 versions. This is also a signal to modders who have already adopted 1.12 {There are a lot of you, this is very encouraging!} that we have stabilized our API. Which means no more intentionally breaking everyone's mods <3 So I hope you guys will stick with us, and I apologize for the delay in getting this first build out. The Recipe System: 1.12 introduced a new JSON based recipe system. Like all systems Forge has had to expand this to support the things that modders want to do. To that extent if you are a modder please read this gist. That is my initial comments and design ideas for the JSON based system. My intention is that someone from the community who is better at writing documentation then I am will come along and convert that to proper docs in our documentation repo. *Hint Hint* Registry Rewrite: One of the core feature of Forge has been the Block/Item registry system. This is what has allowed us to internally manage the ids, world saves, all that stuff. This system has expanded from it's original implementation of just Blocks/Items to a lot of things. Biomes, Entities, Potions, Enchantments, and now Recipes. This is the system that has allowed users and mod pack creators to not need to care about ID conflicts anymore. With recipes being added to this system it has required a MAJOR rewrite of how it works. However this re-write is for the better as it fleshes out and fixes some features that were not fully supported in the older version. There are however things people need to know. Users: Due to the re-write being a great time to delete old complicated, sadly we have had to remove support for updating <1.10 worlds. It is recommended that you load the world using 1.11.2 Forge so it can do the legacy upgrade and THEN load it with 1.12. And as always with anything related to updating worlds between Minecraft versions, we recommend that you make backups of your world before hand! Modders: It is now recommended and HIGHLY encouraged that you use the RegistryEvent.Register<T> functions when creating your block, items, potions, recipes, etc... These events have changed to being fired after pre-init. If you use these events you will better suited for the future when we introduce reloading mods dynamically at runtime. Basically.. use these events! Modders: Substitutions and @ObjectHolders have got a major enhancement, things should be a lot simpler to use now! Minecraft Forge 14.21.1 Changelog: ============================================================================ New: MAJOR rewrite of the Registry system Dropped world loading support for <1.10 worlds. Load them in 1.11.2 before updating to 1.12. New JSON recipe loading system enhancements. Added support to vanilla JSONS to specify NBT data in output. MissingMappingEvent is now fired for ALL registries @ObjectHolders and overriding should now be supported on ALL registries. Added AnimalTameEvent for Parrots. Forced Block/Item.getSubItems method to be available on the server side. Bug Fix: Fixed crash related to player names Fix NPE in config menu with custom keybinds. Fixed exception in ShapedOreRecipe.checkMatch for recipes that don't fill entire crafting grid Fixed bug SPacketLoginSuccess when in development environments. Fixed exception related to vanilla clients connecting to a Forge server. Fixed NoteBlockEvent not supporting new vanilla instruments. Fixed Universal bucket handling for Fluids with NBT Just wanted to reiterate this again, BACKUP your worlds! And to properly report any issues you run into. This means including your fml log!
    4 points
  45. I don't speak for the whole community but since I am a leader of Sponge, I'll throw my 2 cents in by first saying that yes, SpongeForge will be adjusted to comply. We find these changes to be a good-faith effort to make some wholesome changes to the ecosystem as an attempt at dealing with the elephant in the room: coremods. SpongeForge falls under a coremod which will not function at all without its core changes but, as Lex has mentioned above, we can simply make the core portion not function at all should the whole thing not be here and throw up a descriptive error to say why. Expect to see some changes land in the next couple of days (when someone gets some time) on Sponge's end to make this change.
    4 points
  46. The mesher is a tricky method called during init. Used by vanilla but now discouraged for mods, it's tricky because certain things need to be called in a certain order (and the client side-only proxy is involved, which separates some of those statements in code space). I believe that Forge created the custom location method because it's much less fragile. Note that it's called during preInit, not init. The threads discouraging mesher use run like a rash across this forum going back almost 2 years. Any modder facing any rendering problems should have come across them when searching for answers to avoid posting repeat questions. That's why Draco sounds frustrated: When someone shows up here using the mesher call, it means that the modder's scholarship stopped at a long obsolete tutorial without reading any threads written in the last 22 months.
    4 points
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.