Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

fweo

Members
  • Posts

    11
  • Joined

  • Last visited

fweo's Achievements

Tree Puncher

Tree Puncher (2/8)

3

Reputation

  1. When you do your data run do you see "Initializing Data Gatherer for mods [examplemod]" in the logs, rather than [yourmodid]? If so, your run configurations are still wrong. Check to see if you have "--mod examplemod" in your IDE's run configs menu, and if you can't get it to update with gradle you can always change the --mod argument manually in your IDE.
  2. If you're asking how to get the EntityType when using the DeferredRegister way, you can call VERRUCT.get() and that will get you the EntityType out of the registry object. You can do the same for any other type of registry object. The only thing to be careful about is to make sure that the entities have actually been registered by the time you call VERRUCT.get(), but if you register your renderer at the right time that won't be a problem. In 1.17.1 you register renderers with the EntityRenderersEvent.RegisterRenderers event, I'm not sure about 1.16.5 but it's probably similar. This event will always fire after entities have been registered, so you can safely call the getter. You should use deferred registration because it ensures that your entities (or blocks, or whatever else you register) get registered at the right time. If everyone did this, it would allow forge to introduce a lot of useful features, such as reloading/enabling/disabling mods while the game is running. This is impossible to do with static initialisers. By the way, you can click the <> button while drafting your post and it will let you format your code like this: RenderingRegistry.registerEntityRenderingHandler(VERRUCT.get(), verructRenderer::new); LifeAndLive.LOGGER.debug("LIFE AND LIVE - Entity rendered");
  3. Call the food method on your item's properties, and give it a FoodProperties. Either use a FoodProperties from vanilla's Foods class or make your own the same way they do there, e.g. new Item.Properties().food((new FoodProperties.Builder()).nutrition(5).saturationMod(0.5f).build()) In the future, if you want to work out how to add more properties to an item, go to vanilla's Items class and look for an item that has the desired properties (e.g. bread in this case) and follow how it is done there.
  4. There's a class called SoupItem that does exactly what you want, simply changing Item to SoupItem will give you a bowl back once you've finished eating it. If you want something other than a vanilla bowl you can just create a modified version of that class to give you whatever you want.
  5. It's not that the order of the properties that matters. Let's look at this line for a second: new Item(newItem.Properties().group(gobber2)).setRegistryName(location("gobber2_goo")).food(FoodList.gooFood) If I space it out a bit so we can read it a little more easily (you can keep spacing as it was in the actual code): new Item( // start constructing item properties new Item.Properties().group(gobber2) // finish constructing item properties ).setRegistryName(location("gobber2_goo")).food(FoodList.gooFood) that middle line is creating the Properties object. You were calling the food method on the Item object. You're right that food is a thing in Item, but it's just a variable not a method. As it happens, all the Properties::food method does is tell the Properties object to put your Food into that field, as you can see in the Item constructor you posted. Comparing to your working one: new Item( // start constructing item properties new Item.Properties().food(FoodList.gooFood).group(gobber2) // finish constructing item properties ).setRegistryName(location("gobber2_goo")) Now you're (correctly) calling the food method on the Item.Properties object. The only actual difference from your working one is the placement of a single bracket, which is determining what object you're calling the methods on. Changing the order works fine, you can apply properties to the Item.Properties object in whatever order you like (each method returns the Item.Properties object allowing you to "chain" the method calls like you have here). For example, this would also work: new Item( // start constructing item properties new Item.Properties().group(gobber2).food(FoodList.gooFood) // finish constructing item properties ).setRegistryName(location("gobber2_goo")) If you had more changes to properties, like rarity or max stack size, you could put them in there too in any order. Hopefully understanding this will help clear up future problems. Also, if you click the button that looks like < > at the top of your editor when you're posting, you can post code in the style that I'm using here, which will make your post look a lot cleaner.
  6. gobber2_goo still needs to be an Item, which Food is not (it doesn't extend Item like ItemFood did). Take your original code using ItemFood and change it to Item. This will give you a generic non-food item, like you've probably created elsewhere. You can now call another method on the Item.Properties object you are giving it to give the Item.Properties food properties. If you look into the Items class, you'll see where all the vanilla items are created. This is where you can find the method you need, because vanilla foods use it (this will also give you some usage examples). The method is in Item.Properties (my mappings are a bit old so it's func_221540_a for me, it might have a name for you updated my mappings, it's called food now). This method takes a single argument, which would be the Food you just constructed. It'd end up looking like this: Food gooFood = (new Food.Builder()).value(4).saturation(0.6F).build(); ItemList.gobber2_goo = new Item(new Item.Properties().group(gobber2).setRegistryName(location("gobber2_goo").food(gooFood));
  7. You don't need the "modid = " part, this is why you're getting the second error on that line (you haven't defined the variable modid). You can simply use @Mod("bravenewworldmodid"), or better yet, do something like @Mod(Main.MOD_ID) public class Main { public static final String MOD_ID = "bravenewworldmodid"; // rest of your code } which lets you use that variable whenever you need the mod ID.
  8. What do you mean by it not accepting any of the values? Posting the code might help. You should give it your mod ID as a String, and should match your mod ID that you've put in META-INF/mods.toml. If you haven't filled out this file yet, or there's a mismatch, this could be the problem.
  9. The error is telling you that you are applying the @ObjectHolder annotation to a field that does not correspond to a registry, namely one of type CreativeTabs. If you annotate the class with @ObjectHolder like you have done, it will try to use all of the fields in there as object holders, regardless of their type, so it is trying to use SOUL_FORGERY as an object holder. You can get around this by either having only the things you want as object holders in that class and moving the others, or by annotating each field instead of the whole class (see this link).
  10. ItemFood is gone now, whether or not something is a food is defined by a field in the item's properties (this is nice because something can now easily be a food and also something else, because it doesn't have to be an ItemFood AND an ItemArmour, for example). This is the same object you give it when you set the registry name and group on, so you can just call all the necessary methods on that object. If you have a look at how a food item (bread, for example) is created in the vanilla Items class, a (currently unnamed) method is called on the properties given to the item. This method takes a Food object, and you can check the Foods class to see how you make the Food objects. The methods it uses for this are also still unnamed, but you can probably work out what each one does by looking at what food each Food object corresponds to. If you're new to programming aren't certain about how to check these things, I'm not sure about the exact process in Eclipse but if you right-click on the name of a class somewhere in your code there should be the option to view the source somewhere, this is a good way of learning how things work by checking how vanilla does things. You can also just browse through the vanilla code in your project libraries, which in Eclipse are (I think?) down the side underneath all your classes you've written and stuff.
  11. I've noticed that world generation is different from 1.12.2. Is there a registry for world generation similar to how you used to use GameRegistry.registerWorldGenerator? There isn't a registry for it in the list in the documentation, but that's for 1.13 and it tends to be outdated regardless. I can't see one used in the vanilla code either, but I haven't looked incredibly hard. Looking at how vanilla does it, I can see a lot has changed (everything seems to be a Feature now and there are a bunch of config things like OreFeatureConfig and CountRangeConfig), but I can't work out how to hook my code into it, because the biomes seem to just call a long list of functions that add all the features in their constructors. Are there any resources that give an overview of these changes or examples of how to do world generation now? Edit: After looking for a little longer I've worked out that I can loop through ForgeRegistries.BIOMES and call addFeature on each of the biomes. This doesn't feel like a particularly great way of doing things, is there a nicer way?
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.