Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 03/12/19 in all areas

  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. 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
  6. Don't ask awkward questions. Mojang code is PERFECT, and NEVER NEEDS FIXING.
    9 points
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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?
    5 points
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. Thanks for the amazing work, it was such a fast release!
    4 points
  23. For anyone who comes across this in the future, running with `--no-daemon` seems to solve it https://github.com/MinecraftForge/ForgeGradle/issues/563
    4 points
  24. No, MCP is the core and it will continue to be the core. I create MCP and thus I can trust in it's stability and availability. If modders want to make a translation tool between the two so that Fabric can load on SRG names. Then go for it. I have spoken many times about how a system should be designed. But the people who have said they wanted to help haven't followed through. Anyways, getting tired of answering this. Forge will never use Fabric. Fabric's core design of "screw it everyone's a coremod!" is NOT feasible for a large compatible modding ecosystem. Forge's major rewrite is done, which means updates should be back to our normal same day target. Sorry for being 'slow' because we decided to cleanup 8 years of technical debt and plan for the next 10 years. Anyways, don't bump old threads.
    4 points
  25. Bit of follow up since I understand a bit more now.... To get extra data passed across to the client (like a TE blockpos, for example), Forge 26.0.16 adds an extra PacketBuffer parameter to the NetworkHooks.openGui() calls, and a corresponding parameter to the container factory constructor. Looks like NetworkHooks.openGui() remains the way to go for modded - I guess player.openContainer() is really for vanilla only? Update: player.openContainer() should be fine to use if you're just creating a GUI purely to display some container slots (and don't need direct access to the clientside tile entity), like a chest GUI for example. Typically, you'll have two or more constructors in your container objects - one "factory" constructor which is called by Minecraft client-side when a GUI is opened (and when the container type is registered during init), and one or more constructors of your choosing which create a container with any data you need to initialize them with. Those extra constructors would be called server-side from your INamedContainerProvider implementation, and client-side from your "factory" constructor, having extracted information from the extraData PacketBuffer.
    4 points
  26. 4 points
  27. This is typical software engineering jargon for "I wouldn't do it that way." In this case, if the code works, it works. If you're going into professional programming, then maybe you should take the time to learn how to efficiently write code, but for someone who's learning how to mod Minecraft, it really doesn't matter. As time goes on, you'll eventually learn what practices to use over others. The important thing is that most of this forum will not help you out well unless you come already with code. The people here, and in many other places, do not like to just "hand out code" and will be more likely to help. So start out by working with what you know. You're not expected to have perfect code when you first start. And trust me, if you come here with one error, they're going to point out all of the other ones, too. That's my advice. Chances are one of the "higher ups" here will trump me, because that's what they do. Welcome to Forge.
    4 points
  28. 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.
    4 points
  29. I can appreciate the conundrum this is creating for Forge and the need to make a decision. However; I believe another aspect that needs serious consideration and focus is the balancing of LTS to serve the needs of the 'large mod' devs and the modded community QOL vs the eternal chase of the newest shiny version number. If "LTS" is going to start changing even faster than it used to and end up on the same Major version as Latest then "LTS" will no longer have any useful meaning and should just be called something else so as to not be mocking everyone. I have known several mod devs over the last decade who finally gave up modding even though they loved it because of the constant version grind. They were working on large mods that had great potential for even more development but it felt to the devs like they were spending most of their time updating their mods for the next version instead of being able to work on the features and improving the infrastructure. Sure, updating simple mods as well as essentially complete mods may not be too bad most of the time, except for when more "game-breaking" changes are made by Mojang which affect their mod. But even then it becomes a ridiculous maintenance chase which is not at all conducive to the development of new and improved mods. One aspect of Minecraft modding that has singularly contributed so very much to the modded experience and development are the `Mod Islands` that we are all familiar with. Examples being; beta 1.7.3, 1.7.10, and 1.12.2. Of which I believe 1.18.2 could be a great choice for the next one for various reasons. Modding was able to continue and build up on these levels permitting a large and varied selection of mods and experiences for players as well as time for developers to work on large mod projects which are amazing. These are Modded Ecosystem versions of Minecraft. I hate asking anything that would make more difficulty for your team, but I sincerely believe that another LTS level, perhaps VLTS (Very Long Term Support) or ELTS (Ecosystem Long Term Support), that could be attached to a selected final Major version which has certain qualities, would contribute an incredible amount to the Minecraft Modded community, both for the mod devs as well as the community members looking for a stable/large & varied mod ecosystem that can offer them more than just the handful of new baubles that a new rolling and buggy mc version will give them. I'd argue that the people Most concerned with always playing the bleeding edge version of mc are not the only ones who the entire modding system and community should be bent to serve at all costs. Doing so at the expense of what I spoke about in the last paragraphs would do the entire community a great disservice and knee-cap the best possible mod development. Please consider VLTS/ELTS, or at the very least keeping LTS as the final version of the prior Major version for some sane degree of mod community and dev stability. This will have benefits far outweighing trying to maintain some past rules technicalities at the expense of the entire purpose of the project and community. Thank you for all you have done over the years and are planning to continue doing. We all owe you a great debt of gratitude. P.S. Adding ELTS could be considered a mod community investment project; creation of a Stable Nursery for new mod and mod ecosystem development. This would be an incredibly attractive place for devs to be able to catch their breath and just focus on pure mod development, and for players to just build and enjoy collections of mods with increasing options for more mods and synergies without the dark pattern of feeling like they have to jump to the newest "version" of mc pulling at them as much, which makes them lose mods again and again which actually reduces the draw of modded vs vanilla. tbh; The modding community shouldn't be run into the ground by the marketing needs of Mojang and Microsoft. They have their legitimate concerns and things they need to do, but those are not the same thing as what best serves the modding community.
    3 points
  30. I feel like making the .0 version LTS is risky because judging by the past .0 versions contain more bugs than other versions. My suggestion would be having the latest version of the previous major version (1.18.2) as LTS and the latest of the current major version (1.19.3) as current and adding the previous minor version (1.19.2) as a sort of MTS that gets unsupported as soon as a new version (major or minor) drops.
    3 points
  31. Hi, this article is more of a experience sharing instead of a tutorial, the code themselves should be self-explanatory, and the way I do things may not be the best practice, or most efficient. Product: I started with the textures, we need the textures/icons that are being rendered to the world, and the ones for the UI. The blue textures are used when the option is hovered. Then, we need to find out where the mouse is at and which one is selected, we can check the distance and angle from the screen center and decide which part it is on: private int getHoveringType(Minecraft minecraft) { double mX = minecraft.mouseHelper.getMouseX(); double mY = minecraft.mouseHelper.getMouseY(); double actualW = minecraft.getMainWindow().getWidth() / 2.0F; double actualH = minecraft.getMainWindow().getHeight() / 2.0F; double mX2 = mX - actualW; double mY2 = mY - actualH; double angle = AVAWeaponUtil.getAngleFromCoord(mX2, -mY2) + 30; if (Math.sqrt(mX2 * mX2 + mY2 * mY2) <= 15 * minecraft.getMainWindow().getGuiScaleFactor()) return -1; if (angle > 360 || angle <= 60) return 0; return ((int) angle / 60); } public static double getAngleFromCoord(double x, double y) { double angle; angle = abs(atan2(x, y) * 180.0D / PI); if (x < 0) angle = 360 - angle; return angle; } In this case the angle is 60 because 360 / 6 options = 60, and if the mouse is within radius of 15 from the screen center then no action is performed (-1) And then the rendering can be done. @Override public void render(Minecraft minecraft, PlayerEntity player, MatrixStack stack, IPlayerAction capability, float screenWidth, float screenHeight) { float x = screenWidth / 2.0F; float y = screenHeight / 2.0F; float size = 60; int type = getHoveringType(minecraft); AVAClientUtil.blit(stack, type == -1 ? UI_BG_LIT : UI_BG, x - size, y - size, x + size, y + size); for (int i = 0; i < 6; i++) { stack.push(); stack.translate(x, y, 0.0F); stack.rotate(Vector3f.ZP.rotationDegrees(i * 60)); stack.translate(-x, -y, 0.0F); AVAClientUtil.blit(stack, type == i ? UI_BG_2_LIT : UI_BG_2, x - size, y - size, x + size, y + size); stack.pop(); } AVAClientUtil.blit(stack, UI_BG_ICON_LAYER, x - size, y - size, x + size, y + size); } public static void blit(MatrixStack stack, @Nullable ResourceLocation texture, float x1, float y1, float x2, float y2) { if (texture != null) Minecraft.getInstance().getTextureManager().bindTexture(texture); Matrix4f matrix = stack.getLast().getMatrix(); Tessellator tessellator = Tessellator.getInstance(); BufferBuilder bufferbuilder = tessellator.getBuffer(); bufferbuilder.begin(7, DefaultVertexFormats.POSITION_TEX); bufferbuilder.pos(matrix, x1, y2, 0.0F).tex(0.0F, 1.0F).endVertex(); bufferbuilder.pos(matrix, x2, y2, 0.0F).tex(1.0F, 1.0F).endVertex(); bufferbuilder.pos(matrix, x2, y1, 0.0F).tex(1.0F, 0.0F).endVertex(); bufferbuilder.pos(matrix, x1, y1, 0.0F).tex(0.0F, 0.0F).endVertex(); tessellator.draw(); } If the type is -1, then the circle at the center use the blue texture. Otherwise if the type equals the index of the option, it uses the blue texture (or just use RenderSystem.color4f). By rotating an identical texture we don't need to have 6 different textures for each option. public static boolean ACTIVE = false; public static Vector3d VEC = null; @Override public void tick(Minecraft minecraft, PlayerEntity player) { if (minecraft.isGameFocused() && minecraft.currentScreen == null && AVAClientConfig.ENABLE_PING_HOTKEY.get()) { if (AVAClientUtil.middleMouseDown()) { if (!ACTIVE) { Vector3d eye = AVAWeaponUtil.getEyePositionFor(player); BlockRayTraceResult result = player.world.rayTraceBlocks(new RayTraceContext(eye, eye.add(player.getLookVec().scale(100.0F)), RayTraceContext.BlockMode.VISUAL, RayTraceContext.FluidMode.NONE, player)); if (result.getType() != RayTraceResult.Type.MISS) { ACTIVE = true; minecraft.mouseHelper.ungrabMouse(); if (minecraft.gameSettings.keyBindPickBlock.getKey().getKeyCode() == GLFW.GLFW_MOUSE_BUTTON_MIDDLE) AVAClientUtil.unpressKeybind(minecraft.gameSettings.keyBindPickBlock); VEC = result.getHitVec(); } } } else { int type = getHoveringType(minecraft); if (ACTIVE && VEC != null && type != -1) AVAPackets.INSTANCE.sendToServer(new PingMessage(VEC, ActivePingEffect.Type.values()[type])); reset(minecraft); } } else reset(minecraft); } If player's focusing, the middle mouse is down, then we check if there's terrain (block) in player's sight within 100 blocks, if not, reset the vec, regrab the mouse and set active to false. MouseHelper#ungrabMouse call allows players to move mouse around the screen. Once we have the VEC set (where the ping will occur), we can render a line between the center of the screen and the ping location. (White line) { ActiveRenderInfo info = minecraft.gameRenderer.getActiveRenderInfo(); Vector3f view = info.getViewVector(); Vector3d vec = info.getProjectedView().add(view.getX(), view.getY(), view.getZ()); drawLine(stack, (float) vec.x, (float) vec.y, (float) vec.z, (float) pingVec.x, (float) pingVec.y, (float) pingVec.z, 255, 255, 255, 1.0F) } public static void drawLine(MatrixStack stack, float x1, float y1, float z1, float x2, float y2, float z2, int r, int g, int b, float a) { AVAClientUtil.drawTransparent(true); IRenderTypeBuffer.Impl impl = IRenderTypeBuffer.getImpl(Tessellator.getInstance().getBuffer()); IVertexBuilder builder = impl.getBuffer(RenderType.LINES); Vector3d view = Minecraft.getInstance().gameRenderer.getActiveRenderInfo().getProjectedView(); stack.push(); stack.translate(-view.x, -view.y, -view.z); Matrix4f matrix = stack.getLast().getMatrix(); builder.pos(matrix, x1, y1, z1).color(r, g, b, (int) (a * 255.0F)).endVertex(); builder.pos(matrix, x2, y2, z2).color(r, g, b, (int) (a * 255.0F)).endVertex(); stack.pop(); impl.finish(); AVAClientUtil.drawTransparent(false); RenderSystem.color4f(1.0F, 1.0F, 1.0F, 1.0F); } If you did not add the look offset to the camera position it will not be visible. Then we send a packet to the server to notify all other players that I've ping the location. Once players receives the location of the pings, it's time to render them. RenderSystem.disableDepthTest(); AVAClientUtil.drawTransparent(true); Vector3d view = Minecraft.getInstance().gameRenderer.getActiveRenderInfo().getProjectedView(); Vector3d vec = activePing.getVec(); double distance = activePing.getVec().distanceTo(view); if (distance > 100.0F) continue; renderObjectAt(minecraft, activePing, world, stack, (float) (distance / 20.0F), 0.0F, activePing.getTexture()); double x = vec.x - view.getX(); double y = vec.y - view.getY(); double z = vec.z - view.getZ(); stack.push(); stack.translate(x, y, z); stack.rotate(minecraft.getRenderManager().getCameraOrientation()); stack.rotate(Vector3f.ZP.rotationDegrees(180.0F)); float size = (float) (distance / 200.0F); stack.scale(size, size, size); IRenderTypeBuffer.Impl impl = IRenderTypeBuffer.getImpl(Tessellator.getInstance().getBuffer()); String text = AVACommonUtil.round(distance, 2) + "m"; minecraft.fontRenderer.func_243247_a(new StringTextComponent(text), -minecraft.fontRenderer.getStringWidth(text) / 2.0F, 10, AVAConstants.AVA_HUD_TEXT_WHITE, false, stack.getLast().getMatrix(), impl, true, 0, 15728880); impl.finish(); stack.pop(); private static void renderObjectAt(Minecraft minecraft, EnvironmentObjectEffect object, World world, MatrixStack stack, float size, float offsetScale, ResourceLocation texture) { Vector3d vec = object.getVec(); stack.push(); Vector3d view = Minecraft.getInstance().gameRenderer.getActiveRenderInfo().getProjectedView(); double x = vec.x - view.getX(); double y = vec.y - view.getY(); double z = vec.z - view.getZ(); if (Math.sqrt(Math.pow(x, 2) + Math.pow(y, 2) + Math.pow(z, 2)) > 100.0F) return; stack.translate(x, y, z); Direction direction = object.getDirection(); if (direction != null) { Vector3i offset = direction.getDirectionVec(); stack.translate(offset.getX() * offsetScale, offset.getY() * offsetScale, offset.getZ() * offsetScale); rotateByDirection(stack, direction); } else { stack.rotate(minecraft.getRenderManager().getCameraOrientation()); stack.rotate(Vector3f.ZP.rotationDegrees(180.0F)); } if (object.doBlend()) { Color colour = new Color(world.getBlockState(object.getPos()).getMaterialColor(world, object.getPos()).colorValue); RenderSystem.color4f(colour.getRed() / 255.0F, colour.getGreen() / 255.0F, colour.getBlue() / 255.0F, object.getTransparency()); } AVAClientUtil.blit(stack, texture, -size, -size, size, size); RenderSystem.color4f(1.0F, 1.0F, 1.0f, 1.0F); stack.pop(); } In the code I change the size of the object according to the distance ( (distance / 20.0F) ), so the object will stay at similar size no matter the distance between them, and so does the text size. The direction is always null, and doBlend is false. They are used in my other renderings.
    3 points
  32. Lovely server that’s perfect for you if you’re interested in a friendly community, pyrofishing/pyromining, custom weapons and more!
    3 points
  33. There may be a primer for 1.15 -> 1.16.1; however, in the current state of 1.16.2 onwards and with the release of 1.16.4 coming soon, I doubt you will be able to find one. Not many people understand the new system of world generation through data driven systems, so a primer will probably not be out for a while. However, since I'm not a fan of leaving any post unanswered, I'll try and take a basic stab at it. - Blocks have been abstracted even more (AbstractBlock). You'll find that the properties have been turned into functions of some kind to allow for even fewer blocks. For example, the blockstate can control how much light is emitted using a ToIntFunction. Also, for a tool to be required to mine a block, the setRequiresTool parameter must be set. - Block properties no longer have an interface IProperty. It has been relegated to just Property now. - Item properties have also been removed and isolated from the Item class. They are handled within ItemModelProperties and can be registered using the appropriately named methods there. - Rendering methods now take a MatrixStack parameter to correctly orientated it on the screen. If you find any unmapped methods, you will most likely need to stick a MatrixStack variable somewhere within there, nothing else. - Server reload listeners are added via AddReloadListenerEvent. Client reload listeners should still be handled either within your mod constructor or FMLConstructModEvent for better thread-safety. - DeferredWorkQueue is now officially deprecated. You should use the enqueueWork method provided in all parallel dispatch events. - Entities store attributes within GlobalEntityTypeAttributes. If your entity does not have a registered attribute within here, then it will most likely error. For reference, this is not thread-safe. - Models now take in a RenderType to define what layer they will render within. By default, they use a no cull cutout layer. - Every mods.toml must have a license entry. Otherwise, your mod will error and crash. - LazyOptionals have a few changes as defined in 33.0.21. LazyOptionals map to LazyOptionals now using lazyMap. map returns a regular Optional. Note that this Optional will throw an error if the map function somehow results in a null entry. filter also returns an Optional now. Finally, a new method called resolve has been added to convert to an Optional directly. - ExistingFileHelper is now required within tag providers. Existing mod resources can be attached using '--existing-mod <modid>' as of 35.1.3. - Finally, I will mention world generation. Currently, all of world gen has been delegated to a data driven system. This is a mixed point for some users. Currently, forge is working on a more dynamic system to allow all of world generation to be handled within JSON files; however, that is not completely possible yet. Therefore, there are a few workarounds to handle this via BiomeLoadingEvent. Here, you can add configured features and structures to already existing biomes along with some other details I'll let you explore for yourself. - Creating biomes can either be done one of two ways. You can either create one using BiomeMaker for the Biome builder itself in some fashion and register it using the RegistryEvent or you can initialize a dummy biome and create it via JSON. To get your biome to spawn in the world, this is still handled within BiomeManager instead taking a RegistryKey (a concatenation of the registry and the object name). To set it as a spawn biome, that is handled when you build the biome itself. - Features have been changed in an interesting way. Instead of having a Feature with a single Placement, features can now have multiple placements. This means a placement can determine the amount, the height, the spread, etc. The way placements are handled are similar to a stack. The first placement you attach will be the last to execute if you need an example. Therefore, when creating a ConfiguredFeature, things like a count placement should be handled as the last chained method. There are a few helper methods within that makes it easier to generate count placements, although they will most likely remain unmapped until the next mappings push. Cyborgmas pointed out something with registering these entries that non-registered ones causes an issue with the codec, so they should be handled and registered probably within your common setup or at the very earliest after placements have been registered. - If possible, you should try to create all your world generation edits within JSON files to better prepare yourself for when the system comes out of the experimental phase. However, that is currently optional until everything updates. Hopefully I covered the gist of the changes from 1.15 -> 1.16.3. There are definitely many more that I've missed such as background music or the brain system within entities. However, those topics are best explained in greater detail with more specific questions. Same goes for the information I missed within world generation JSONs. Good luck on your updates!
    3 points
  34. This is a small guide for people how want to Speed up their development by swapping changed code during run time, which eliminates the need to constantly restart the Minecraft-Client. To reach our goal we need to install Hotswap and DCEVM. To install DCEVM you first need to download the newest release for java 8 form this link: https://github.com/dcevm/dcevm/releases Before you continue installing DCEVM you need to first install the right java version that matches your download. Most likely this will be the version 1.8.0_181. The download list can be found here: https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.html To now install DCEVM run java -jar "path_to_the_installer/DCEVM-8u181-installer.jar" as Administrator in your console. In the UI that pops up you need to select the java version you just installed and click on Install DCEVM as altjvm. You probably need to do this for the jdk and jre. Next download the hotswap-agent and place the jar file in an appropriate folder. https://github.com/HotswapProjects/HotswapAgent/releases Now the Basic setup is finished, our next step is too setup Intellij and gradle two run correctly. First thing you need to do is to install the HotswapAgent plugin for Intellij. Plugins can be install under: Settings -> Plugins -> Marketplace Search for hotswapagent. Now under Tools -> HotswapAgent select Enable HotswapAgent in all configurations Under Keymap search for "Reload Changed Classes" and assign a Keyboard shortcut. Now press double shift and search for "Registry..." and enable compiler.automake.allow.when.app.running Finally to run the Minecraft client create a new gradle configuration with task = "runClient" and VM options = "-Xmx3G -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5010 -XXaltjvm=dcevm -XX:+UnlockExperimentalVMOptions -javaagent:path_to_your\hotswap-agent-1.4.0.jar" Now your good to go. If you have any questions or suggestions feel free to comment below this is my first tutorial so if you have any advise it would be more than welocome. I hope this is helpful for you have a nice Day.
    3 points
  35. and because you use MCreator you got this far and are now bitching because you can't get something to work and you feel we should just do the work for you when you haven't even put in the effort to learn Java. There is a reason we dislike MCreator and you are only reinforcing that opinion. Learn Java.
    3 points
  36. You need two item stack handlers, one that's private that the machine can insert to, and one that you expose via getCapability that can only be extracted from (and which wraps around the former). https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/SifterTileEntity.java#L51-L52
    3 points
  37. Forge Version: 31.2.0 Minecraft Version: 1.15.2 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Intro: Here we go again for 1.15.2, this has a ton of bug fixes, developer improvements, as well as preliminary support for Java 13+ so we'll see how that goes. Changelog: New: Added hook to allow customized overlays when swimming in custom fluids. Added support for suppliers in FoodItem, allow easier modder extension. Added model data to BlockModelRenderer Added system for global loot functions, allowing modders to affect all loot tables using data. Added new early loading screen that shows before Vanilla even exists. Should seamlessly transition to vanilla. Can be disabled via config. Added new Data generation features. Revived the Forge lighting pipeline, to improve rendering performance. Disabled by default. Added hook to control hill biomes. Added PlantType to the extensible enums. Extended GUIUtils to be more useful. Added hook to override tool requirements when breaking blocks. Added hooks to allow buckets to be better used with custom fluids. Added hook to allow bees to use custom hives. Added ability to use stencil buffers for mods. Added constructor to Music Discs for easier modder extension. Fixes: Fixed lighting issue in GUIs for some models. Fixed bug causing equip tooltip to display when unnecessary. Fixed client desync when interact event is canceled on the client. Fixed invalid arguments passed to first person hand renderer. Fixed chunk watch and unwatch events not firing correctly. Fixed vanilla bug related to rendering states. Fixed error when players join servers in a dimension that doesn't exist. Fixed ItemStack TER not being called. Fixed custom teleporters not being used when moving from the end to overworld. Fixed custom teleporters triggering end game credits. Fixed set dimension command not setting position correctly. Fixed Conduit and Beacon activation on vanilla servers. Fixed potential issue with clients sending invalid data to server. Fixed javac compiling issues on some JDKs Fixed tps and gen commands not working. Fixed note blocks not changing state correctly. Fixed ownership leak in ItemStackHandler. Fixed server config loosing dimension type when using custom dimensions. Fixed vanilla bug that caused the byte order of buffers to be incorrect. Fixed buffer batching not copying all data correctly. Fixed tag serializing empty data. Fixed annotation processor skipping duplicate annotations. Fixed annotation processor incorrectly tagging child annotations. Fixed binary issues when using JDK 9+ and targeting J8. Fixed vanilla recursion issue in advancement loading. Fixed potential NPEs in RegistryObject. Fixed mod resource and data packs being sorted incorrectly. Fixed automatic event subscriber picking wrong mod id when in multi-mod sources. Fixed BackgroundScanHandler erroring on some servers. Fixed swim speed and reach distance not having localization info. Fixed milk buckets removing too many potion effects. Fixed chunk data save event being fired with null world in some cases. Fixed resource leak in vanilla loot table handler. Fixed hoppers not fully inserting into custom inventories with non-standard max stack values. Fixed null item stack being sent to player destroy item hook. Fixed some blocks being darker then they would be in vanilla. Fixed pressing escape not matching pressing done on the mod list screen. Fixed removedByPlayer not being called on the client when breaking blocks. Fixed infinite loading screen when mod resources error. Fixed fluid tanks calling changed events when simulating. Fixed tile entities persisting incorrectly when blockstate changes. Fixed CrowGrowEvents not firing for Bamboo Fixed vanilla screens where pressing escape doesn't match pressing done. Fixed mod duplication issue when using a symbolic links as your mods folder. Fixed server config directory remaining locked after server shutdown. Fixed level change event not firing during enchanting. Fixed duplicate call to chunk load events. Fixed typo in registry alias serialization causing infinite loop. Fixed particles not colliding with the ground correctly. Fixed model transformation ordering. Fixed OBJ models ignoring deffuseLighting setting. Fixed blockstate json serializer using incorrect string. Fixed incorrect argument passed in RenderPipeline potentially causing crash. Fixed FireBlock using flammability instead of spread speed when looking for places to spread.
    3 points
  38. Be honest with me... did you edit your error to replace 1.7.10 with 1.14.3 so your thread wouldn't be locked?
    3 points
  39. I would just add onto this with make sure you take breaks and get sleep before you post here too because honestly we all know that really helps you spot the logic mistakes.
    3 points
  40. For anyone looking, the following code will rotate a VoxelShape around an axis: public static VoxelShape rotateShape(Direction from, Direction to, VoxelShape shape) { VoxelShape[] buffer = new VoxelShape[]{ shape, VoxelShapes.empty() }; int times = (to.getHorizontalIndex() - from.getHorizontalIndex() + 4) % 4; for (int i = 0; i < times; i++) { buffer[0].forEachBox((minX, minY, minZ, maxX, maxY, maxZ) -> buffer[1] = VoxelShapes.or(buffer[1], VoxelShapes.create(1-maxZ, minY, minX, 1-minZ, maxY, maxX))); buffer[0] = buffer[1]; buffer[1] = VoxelShapes.empty(); } return buffer[0]; }
    3 points
  41. Hello everyone ! Let me present you my Masks mod for Minecraft Forge ! This mod lets you craft masks that give you the powers of different Minecraft mobs. To craft a mask, you’ll need a life essence. This item has a 1% chance of being dropped every time you kill a mob. You can use a life essence to craft a raw clay mask: Cook it to get a stringless clay mask, add a couple strings to it, and voilà, you get a nice mask to wear! Now, this mask looks nice, but it gets even better when you use it to craft monster masks. Here is a list of the masks you can craft so far, and what they can do: Passive animal masks Neutral animal masks Sea mobs masks Overworld monster masks Nether monster masks That’s all there is for now, but I plan on adding more masks. Please note that the config file lets you: -enable and disable shaders for each mask -change the life essence drop rate -change the xp cost of some of the mask powers DOWNLOAD LINK (Mediafire)
    3 points
  42. Finally. Give me a couple hours and I’ll have pushed my changes to ExampleMod and my tutorials that make all registration use DeferredRegisty.
    3 points
  43. 1.15 has been more challenging then previously expected. Instead of just being adding bees, and fixing bugs as reported by Mojang. They decided to take this release to re-write most of the rendering engine. Unfortunately, they also took the rendering guy from the Forge team. And my weakest point has always been, you guessed it, rendering. So it's being quite difficult to sort through all the changes, and update our massive changes to reflect the new stuff. gigaherz, tterrag, and unneon are trying to get up to speed and sort through all the rendering changes. So far, we've processed 512 out of the 520 patch files Forge does. As well as brought the compile errors down from >1400, to 161. So, progress is being made. Unfortunately, not publicly as before we get it compiling the repo we're working in contains the full MC decompiled codebase. And we do not have legal authority to redistribute that, so we're working on it privately. Hopefully, we'll have a build working and published here shortly, we're hoping that it won't be as broken as it could be. We'll keep you informed when there is something to inform. As for the mapping data, we've already answered this, Mojang's release under the license you quoted does NOTHING to help us and only helps those who do not respect their license {Hacks/pirate clients/malware}. We are STILL holding out hope that Mojang's lawyers will come back with a new license that actually allows us to use this data.
    3 points
  44. I found the solution, you need a music in MONO not in STEREO ... @kaydogz
    3 points
  45. I cannot for the life of me understand how capabilities work. It may just be the way I'm needing to implement them, so I'll be talking about that specifically. I'm currently making a mod that adds a modifier to the player's health to allow for more than just the generic 20 max health. Previously I used a class that contained a player cache and had functions to store and modify the NBT data of said player. Well, I was recently told to use capabilities now, but I have absolutely no idea how to do that. From what I understand, capabilities are supposed to be an easy way to store data alongside Minecraft classes. For example, an easy way to store data for a furnace or something. What I don't understand is how the hell this is supposed to work; what is a capability? Is it a modification to the way things work? Or is it supposed to be an easy interface between NBT data and Minecraft objects? How the hell do you attach a capability to an Entity? Do I need to provide my own Capability Provider, or use one of Forge's? If I need to use one of Forge's, which one do i use? How do I provide my own, in the case I need to do that (the forge documentation is useless and outdated). What does it mean to "expose" a capability? What is a capability type? What does it mean to "attach" a capability? Capabilities do not make sense at all! I will attempt to break this down so you can understand what I don't: "In general terms, each capability provides a feature in the form of an interface, alongside with a default implementation which can be requested, and a storage handler for at least this default implementation. " "each capability provides a feature in the form of an interface," what does this even mean? I've completed my college course on Java and still have no idea what this implies. A Java interface is used to easily describe classes and provides a layer of abstraction, it is not supposed to provide features. You cannot "implement" a feature using an interface. "alongside with a default implementation which can be requested," what? A default implementation versus... what, a custom one? Someone else's? Why not just implement what you need instead of attempting to provide an interface? "a storage handler for at least this default implementation," again, what is this 'default implementation', and what other types of implementations are there? Also, what in the world is this implementation? I, alongside many others, learn best by example, but the examples on the Forge docs don't provide any context whatsoever. The text refers to things that haven't been talked about, and implies that you have already created things that you didn't even know existed. How am I supposed to have made an "instance of the underlying capability type" if I didn't even know I needed to make one? Maybe I'm just having a hard time understanding Forge's documentation, but I have no idea what capabilities are supposed to be, what they provide in functionality, and how they're supposed to be "easier" than just directly interfacing with a player's NBT data. And yes, I have looked in the source, and no, it doesn't help whatsoever because if I don't even know what they do in the first place how am I supposed to understand an implementation? Note: Once I truly understand the purpose of a capability and how to implement one, I would love to make a PR to help improve the wording of the docs.
    3 points
  46. We will be making an announcement about it when we can. The current state is that it means almost nothing for us. As the license doesn't allow for us to actually USE this information. We are waiting to hear back from Mojang's legal team {This is all stuff they could of answered before the public announcement by asking us, but whatever} Keep an eye on Github/Twitter and we'll keep you updated.
    3 points
  47. I want to say thank you to everyone here who helps with modder support. Just having you around is really encouraging, so I always know there's someone to turn to if I get myself stuck. Three times now I've solved a problem I thought I couldn't fix on my own while writing a post to ask for help, and without y'all I'd probably just have given up. So, thank you for helping, even if you didn't know you were
    3 points
  48. @desht THANK YOU! Finaly it works. First of yes the data.... folder is the right one. And I finally found the problem I've had { "type": "cockmod:block", "pools": [ { "name": "cockmod:cockpool", "rolls": 1, "entries": [ { "type": "cockmod:item", "name": "cockmod:cockingot" } ], "conditions": [ { "condition": "minecraft:survives_explosion" } ] } ] } but I need { "type": "minecraft:block", "pools": [ { "name": "cockmod:cockpool", "rolls": 1, "entries": [ { "type": "minecraft:item", "name": "cockmod:cockblock" } ], "conditions": [ { "condition": "minecraft:survives_explosion" } ] } ] } just change the types to minecraft:item and minecraft:block and then it works. I have only one more question. Can I keep the cockpool for all my items or do I have to change it to something else for each one?
    3 points
  49. No, he's the author of some code to unbind the TESR, not the author of Bonsai Trees. But looking at the github issue, the Bonsai Trees author is looking into the performance issues. @DavidM The unbinding code looks fine on the face of it, having looked at TileEntityRendererDispatcher, but I'd recommend testing it with Bonsai Trees and as many other mods as is feasible.
    3 points
×
×
  • Create New...

Important Information

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