Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 02/02/17 in all areas

  1. 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
  2. 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
  3. 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
    4 points
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. iT makeS youR postS neaR impossiblE tO reaD. herE, i'lL dO thE lasT letteR. iT iS noT betteR, it'S wronG anD noT propeR englisH.
    3 points
  12. A stack of size 0 (but still with some other item) won't == ItemStack.EMPTY but it will still resolve .isEmpty() as true.
    3 points
  13. Although there are ways of generating structures from NBT files Minecraft uses min and max x, y, and z coordinates to decide which blocks go where. The StructureVillagePieces class is an example of this. In order to create a new village component (building) create a class that extends StructureVillagePieces.Village which will be your code for the building itself. An example of this can be found here. You will also need to create a handler the implements IVillageCreationHandler in which you will refer to your new village component class. In your main class preInit you will then need to use VillagerRegistry.instance().registerVillageCreationHandler(); to register your handler and MapGenStructureIO.registerStructureComponent(); to register the component itself. If you want to create an entirely new village instead of single buildings I recommend looking at Galacticraft's code for Moon Villages. Although I haven't look into them much I imagine End Cities and Woodlands are similar to this.
    3 points
  14. 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.
    3 points
  15. You need to have a TileEntity constructor without any arguments (and calling super()), as that's used for instantiating a TileEntity when the world's getting loaded. My advice: don't use custom TileEntity constructors. Instead, use setters as it removes any confusion with constructors.
    3 points
  16. That tutorial is dumb. It's close, but dumb. Extract the MDK to whatever folder you want your project in. Run gradlew setupDecompWorkspace eclipse In eclipse File -> Import -> Existing Project -> Your folder. There is no special 'Forge' folder or anything. Your project is your project.
    3 points
  17. @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.
    3 points
  18. No no no, not-user-friendly is Blender. It took me 2 hours to move a camera and change the animation speed on an already complete scene. I lost track of the number of times I had to quit and start over.
    3 points
  19. IntelliJ isn't the only program that does it, I've run into a few others. But every time it's "undo, undo, undo...ok redo...fuck, why did that just delete a line? Oh, stupid keybinds. FINE, I GUESS I'LL RETYPE IT." I don't mind ctrl-shift-z being redo and not ctrl-y, it's the binding something destructive to ctrl-y that irks me. Yeah, just completely fuck with someone who's never used your software before so they can't fix the mistake because they didn't know what your keybinds were, that's just brilliant.
    3 points
  20. 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.
    3 points
  21. Alright, this is stupid. Jred you're a fucking moron. First you have no idea what a Eula is. Second you have no idea how to actually read and comprehend the Best practices that you're referring to. Yes, there is a group of people out there who are in a circle jerk of misunderstanding and misinformation. People don't like working together, people don't like change. It's just how it is. The basic gist of it is that if you're screwing around with SOMEONE ELSES CODE. Which is LITERALLY the only reason to write a coremod, then you should be open to showing what you're doing. You're say you are doing vanilla and forge bug fixes. THEN SEND US THR BUG REPORTS SO WE CAN FIX THEM! As for the packaging, you can have whatever the he'll you want in a single download. End use wise this changes NOTHING. Download one jar file. Put it in your mods folder. DONE. The point is to structure what's IN that jar file so that Forge or any other loader out there can separate things out and manage things properly so that the crap we have been dealin with for the last 4 years can end. I could go on about the entire premis of the first post being stupid and clearly showing you lack of understanding of vanilla or forges code. But I neither have the time or the crayons to explain it to you. seriously this is nothing but you showing that you have no idea what the he'll you're talking about. This is done. PS: it's been a long time seince I've done a rant like this. Guys I've tried to behave but seriously this fucking guy...
    3 points
  22. i would suggest going to 1.11.2 and then later when many people will be playing 1.12 upgrade again
    3 points
  23. Chiming in as one of the other leaders of Sponge, I've always believed that making heavy modifications to the game (as coremods sometimes do) would benefit from being viewed source, since often times debugging odd interactions between SpongeForge (and SpongeCommon as the larger part) have been often times difficult to say the least to work out where the issue lies. That being said, I strongly support the idea around coremods being viewed source for the sake of inter-coremod compatibility overall, as the goal with SpongeForge has always been about remaining compatible with as many mods as possible out of the box (even if the technological attempts at maintaining that compatibility is not as evident or thought up very fast). As @Zidane has mentioned, SpongeForge will be making the necessary changes in the very near future to abide by these requirements. As per usual, my goal with inter-mod compatibility is always to provide as much descriptive console spam error logs to help Sponge and/or the mod itself get a better fix and make the users happier overall.
    3 points
  24. Here I'll show the final code that definitly works for me: //spawn structure if (!worldIn.isRemote) { WorldServer worldserver = (WorldServer) worldIn; MinecraftServer minecraftserver = worldIn.getMinecraftServer(); TemplateManager templatemanager = worldserver.getStructureTemplateManager(); ResourceLocation loc = new ResourceLocation(Reference.MOD_ID,"t1"); Template template = templatemanager.getTemplate(minecraftserver, loc); Utils.getLogger().info("=======0======="+template); if (template != null) { worldIn.notifyBlockUpdate(pos, iblockstate, iblockstate, 3); PlacementSettings placementsettings = (new PlacementSettings()).setMirror(Mirror.NONE) .setRotation(Rotation.NONE).setIgnoreEntities(false).setChunk((ChunkPos) null) .setReplacedBlock((Block) null).setIgnoreStructureBlock(false); Utils.getLogger().info("=======1======="+loc); template.addBlocksToWorld(worldIn, pos, placementsettings); Utils.getLogger().info("========2======="+pos); } }
    3 points
  25. Do you have a pack.mcmeta file in src/main/resources with pack_format set to 3? If you don't, Forge will load your mod's resources using the LegacyV2Adapter IResourcePack wrapper. This means that your lang files will be loaded with the old mixed-case names (e.g. en_US.lang) rather than the new lower-case names (e.g. en_us.lang). If you do, your lang files should be loaded with lower-case names. Try refreshing your IDE project (i.e. click the "Refresh all Gradle projects" button in IDEA's Gradle window or re-run the eclipse Gradle task) and/or rebuilding it.
    3 points
  26. I have already updated our internal tools to support the last few snapshots, its not that big of a deal. It'll be some work but it shouldn't take to long. Just waiting on 1.12's official drop.
    3 points
  27. If you already understand Java (and it's painfully obvious that you don't), you would know exactly what you need to replace null with. This forum is for help with Minecraft and Forge, what you are asking for help with is Java, which is neither of the above. So before you keep whining about how nobody will help you, realize that you're in the wrong place. As is stated on this forum all the time, this is not a forum for teaching Java because you should already have a reasonable understanding of Java before you start trying to make mods. You'll find that everyone on here is perfectly helpful, you're just not listening to us.
    3 points
  28. You should always use the latest version. There's no reason not to.
    2 points
  29. It is important in modding to learn how to help yourself. So in this case, it seems like you just have question about making particles generally. So have you looked at all the vanilla and open source mods that generate particles? Have you looked for any recent tutorials on particles? Then for the dragon specifically generating the particles, have you looked at the vanilla dragon code to understand how it attacks and how the head position is tracked? Based on that can you use a forge hook like an attack event and your understanding of the dragon code to generate the particles? When experienced modders answer questions on forums, even they often look things up. So best thing is to learn to look it up yourself? To do that, look at all the similar things you can think of and then put it together.
    2 points
  30. Mods needs to tell Forge they can be disabled, however, most of them can’t due to the way they work, anything that is just visual and client-sided should be able to be disabled (eg minimap mod, NEI-like menu) but anything that is required on server and client will not be able to be disabled
    2 points
  31. Okay, except comparing your code to the vanilla Overworld chunk it seems you have some relevant changes. I expect that many of these are changes you've done while debugging but I just want to make sure. Some things that are different from vanilla: - in the generateChunk() method you have removed all the parts where it generates most features like caves, ravines, villages, monuments, mineshafts, etc. - in the populate() method you have removed the woodland mansion generation. - your code has a method called getScatteredFeatureSpawnList() which in my Forge Reference Library seems to now be getMonsters(). I guess they changed that between your version of 1.12.2 and mine. None of the above should be an issue and I assume you probably did the removing of features as part of the debug, right? Okay, looking further at your code, in your WPMedieval class you are associating a biome provider for a single biome that is your custom Generizer.MEDIEVAL. Since that isn't a copy of vanilla I wonder if your problem is actually with your biome stuff. I'm not that experienced in custom biomes, but I'd suggest greatly simplifying that as a debug step. Only register one biome and don't remove any vanilla, or maybe even just do nothing in terms of new biomes, and see if the problem still exists. Now one thing that I always run into trouble with regarding world gen is that the relationship between classes is very convoluted. It is possible you're running into such trouble. For example in your WPMedieval you specify that the DimensionType is OVERWORLD, but if you look at OVERWORLD it is defined to have a WorldProviderSurface. In other words your world provider is pointing to a dimension type that says it has a different world provider. I have no idea if that is an actual problem, but doesn't seem "healthy". Frankly the way that the world gen classes over-reference each other can cause some weird things like that. You might want to try creating a custom DimensionType that properly points to your world provider and clean up any other such things you might find. Similarly you might want to try making a custom WorldType instead of using the vanilla one because again it might have references to a different IChunkGenerator or other stuff that conflicts with your stuff. You also have two custom IWorldGenerator classes registered. Have you tried isolating to see if they are causing trouble? -- like don't register them and see if issue goes away. Also, in your IWorldGenerator classes you end up calling the CustomGenMinable class which extends the WorldGenerator class. So you're kind of mixing the Forge IWorldGenerator class with the vanilla WorldGenerator class. I don't know if that is a problem, but I think the idea is modders should use IWorldGenerator purely. Just some ideas. -
    2 points
  32. "I want to make a block that works like the log works..." Normal person: "Let me go look at the log class, oh hey, BlockLogNew extends BlockLogBase!"
    2 points
  33. Well in this thread you actually used the words: "please stop" "don't ask" "useless questions will not be answered" "not supported on the forum" "this thread should be locked period" "get out of here" You also questioned his motives related to PVP. You also insulted him by calling him "lazy" and "unoriginal". All the above might actually be true, but leave it to diesieben07 to respond. And no one needs to attack so aggressively -- I know it can be frustrating to see people come asking for help when they are indeed lazy or incapable of programming Java. But just ignore them instead of getting in an all caps flame war. I don't want to see you banned from the forum because you seem to legitimately care about modding and have a lot of passion and potential. So just stick to threads that don't frustrate you! Cheers!
    2 points
  34. This link has a great example of using registry events to register stuff.
    2 points
  35. Nvm I see the problem. In your EnumHandler your not setting the name of the Enums to the value of name. Your not setting the size either, just the I'd.
    2 points
  36. Forge Energy requires that you do a lot of stuff yourself, but it is essentially the same as Redstone Flux (IIRC, FE was inspired by RF). TL;DR: switch to Forge Energy.
    2 points
  37. 2 points
  38. An ItemMeshDefinition simply selects a model for an ItemStack, it doesn't combine or generate models itself. This needs to be done by the model. Look at ModelDynBucket or ItemLayerModel to see how they combine multiple textures into a model. I can't really help you with specifics, I can only point you to examples.
    2 points
  39. IModel is the model in its raw form, which can be baked into an IBakedModel. IBakedModel is the model in a form optimised for being uploaded to the GPU. ICustomModelLoader is responsible for loading the IModel.
    2 points
  40. Ah, yes, I see the problem. On line 109 in your Render class you perform an illegal action. You should do this:
    2 points
  41. I saw in the manual something about the new registering stuff, but do not fully understand how that works. I have tried some stuff that didn't worked. I found a way to register stuff and it works, but i'm not sure if that's the way to go. It looks like this: public static Block registerBlock(Block block){ ItemBlock item = new ItemBlock(block); item.setRegistryName(block.getRegistryName()); ForgeRegistries.BLOCKS.register(block); ForgeRegistries.ITEMS.register(item); return block; } I have created this method to register things. I also made 1 for metablocks and for slabs. I also found out that all blocks that have subblocks don't have their subblocks in the creative tab anymore. They have been registered and are in the game. I checked this with the /give user modid:limestone 1 0 (or 1,2) It gave me the required block. In my case limestone (0), polished limestone(1) and bricked limestone(2)
    2 points
  42. Classic XY Problem. You had a problem X and you thought you could maybe solve it by doing Y, but you encountered another problem you couldn't solve, so you asked how to solve Y when what you really needed was to solve X.
    2 points
  43. First of all, Blocks are singletons. You should only ever have 1 instance of each block, and not call new TestBlock() each time you want an instance. Store a single instance in a static field somewhere to reference later. That alone will fix a lot of your issues if not all. Also, Reflection for Block registering? You'd be better of with the RegistryEvents (http://mcforge.readthedocs.io/en/latest/concepts/registries/).
    2 points
  44. Delete the coremods. And update to 1.11.2
    2 points
  45. Step back from the "how do I make an api jar" and look at your mod. What is it that you've created that other people might want to use? Did you add a machine that has some sort of recipe? Did you add a machine that has some sort of recipe? Do you have some capability that could be exposed? Do you have some other mechanism that other mods might either want to know about, modify, supply data to, or get data from? Do you have block properties that aren't vanilla? First, create an API package separate form your mod. In there create interface that declares the action you want to expose. Second, implement that interface on the class that's already handling those actions. Third, store a reference to the instance in an API location (don't forget to instantiate it). Fourth, convert all existing references over to use the API instead. If you do things right, the game won't crash and your machine will still work. Congrats, you made an API. If you don't use your own API, you can't test it. And if you don't test it, you won't realize that something's wrong (it took Reika and I back and forth over 3 revisions of his API before I could add a recipe to the Rotary Craft Extractor). You can do the same thing for block properties, capabilities, and other things as well. However there's other things to keep in mind as well: Once you've declared the interface and released it, it's effectively permanent. You've signed an API contract that says that these methods exist and are guaranteed to exist. If you change the method signatures in the future, it won't be your mod that crashes, but the mod that tried to use your API. And users will complain to them even though it's your fault. Imagine how frustrated a player would be if that other mod author vanished from modding and you changed the API: users would be hammering a brick wall with no response, unable to use two of their favorite mods together. Instead, you should mark the methods in the interface as @deprecated (so that no one else starts using them) and in the implementation, make a best-guess conversion to the new method. If it can't be done at all, then just leave an empty method stub. The two mods won't integrate as they used to, but they'd still run. You can throw warnings and log messages and non-fatal errors all you'd like, but the JVM should never crash.
    2 points
×
×
  • Create New...

Important Information

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