Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/10/17 in all areas

  1. The bit diesieben07 forgot to say ways, "Use UUIDs"
    1 point
  2. i had this problem also, i tried to re install java and it worked.
    1 point
  3. What are you trying now? I know that in 1.10 you can use PlayerList to get a specific player. So first you'd get the server from your world with something akin to PlayerList list = world.getMinecraftServer().getPlayerList(); then simply list.getPlayerByUsername("cookie"); as far as I can tell this shouldn't have changed too much, considering we just switched from ServerConfigurationManager to PlayerList. PlayerList can also be used to find a player by UUID, which might be more reliable for people who change their name. Note: I've checked this in 1.10, but since nobody else responded yet I thought I'd try and push you along the right direction. If this doesn't work you could always try to google for the PlayerList class and what happened to it in 1.12
    1 point
  4. That is a valid approach. There are a lot of different approaches. Some people combine some registration code in each item class, I just list it out directly in my event handler. One philosophy I have is that although I like the idea of putting things in lists and iterating, it is also no effort at all to cut and paste in an IDE and you have to create the list anyway so it doesn't save you that much to put it in a list rather than just have a line to register each item. For me, iterating through a list is more efficient when you're doing several lines of processing. If you're doing a single line then you don't save much. Cut and paste can of course introduce errors sometimes, but when all the lines are one after another that is easy to catch. My basic approach is to create all my instances in a ModItems class, and then have a registerItems() method in that class that I call from my proxy (in older versions) and from my registry event handler in more recent versions. I sometimes make my ModItems class also the event subscriber. In programming there are a lot of ways to achieve the same thing and a lot is just personal preference. I rarely do mods with more than a half dozen items so I don't get too fancy with organizing it. If you're doing a major item overhaul mod then of course you need to architect things for greater convenience.
    1 point
  5. I've got various tutorials here: http://jabelarminecraft.blogspot.com/ Some information is still for older versions, but I've updated a fair bit and also a lot of stuff is still relevant or close to 1.12 approach. It might be helpful.
    1 point
  6. Oh, sure. Absolutely. You could even register it as a static class and bypass the static -> instance redirection methods. The first one is static so I can reference it as EasyRegistry.registerItem, that method then calls Hardlib.proxy._registerItem
    1 point
  7. I have them set up that way because of what the EasyRegistry is supposed to do: register stuff in a way that doesn't require I, the modder, to have to do much work in my main class: its flexible, its powerful, it makes distinctions. The interface-and-separate-classes makes more sense for a traditional proxy system because anything that would be in a "common" proxy should be in your main mod class.
    1 point
  8. Blocks work the same, except: You use the RegistryEvent.Register<Block> event. You have to create an ItemBlock instance of your block and register it during the Item registration event if you want the block to appear in the player's inventory at all. Models need to be registered during the ModelRegistryEvent and you call ModelLoader.setCustomModelResourceLocation(...) there. This is client-side-only. Proxies are how to distinguish between the physical client and physical server (the client, running single player, has an integrated logical server). You need two classes, a ClientProxy and a ServerProxy that both can be assigned to the same field in your main class, annotated with @SidedProxy It is recommended that you use an IProxy interface as the common type.
    1 point
  9. You can still use OreDictionary.WILDCARD_VALUE (32767) as the metadata of an ingredient to match any metadata value. You can create custom IRecipe and Ingredient implementations by creating an IRecipeFactory or IIngredientFactory and specifying them in your _factories.json file. You can see some examples here and here.
    1 point
×
×
  • Create New...

Important Information

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