Jump to content

Animefan8888

Forge Modder
  • Posts

    6157
  • Joined

  • Last visited

  • Days Won

    59

Everything posted by Animefan8888

  1. Then don't. Pass an ItemStack that has the Item it talks about. Trick the system. That's how a lot of Right Clicking blocks work. They use a FakePlayer. I know for a fact that some Items in their Item#onItemUse and Item#onItemRightClick won't even care. Such as the BuildCraft Wrench won't even care I'm pretty sure the Thermal Expansion one won't after several minutes searching. It's your/his system. You get to choose where and when things can be registered. Also why limit that in the first place? I know why forge does it; if it didn't all types of things would go wrong. People would register things conditionally and they would be different on the server vs the client. But your modules don't technically even need to be on the client, other than to display information such as which module is active. Which I assume it is told "hey this is the active module" every time the module changes/becomes un-synced.
  2. That's not what I mean. I asked where you call the method from. It's not magic you have to call it from somewhere.
  3. Post your latest.log and debug.log file for 1.12.2 it will be under .minecraft/logs
  4. I can't just assume you've called this method somewhere can I?
  5. Why is that? The module isn't actually used until you arrive in game does it? Ok here this out. I have a NonNullList<Item> this list contains all of the Items from the mods I want to implement into one Item; the Multi-Tool. I can now have an int that represents what Item it currently has active. Which can be changed via a hotkey/keybinding. Now the Multi-Tool just needs to access that List with the index of the active setting. Then call Item#onItemUse on the Item in the NonNullList<Item> no need for modules. Now how did I get this NonNullList<Item> for my Multi-Tool? I used an Event that fires after all Mods have added their Items to the registry(I assume that FMLLoadCompleteEvent is fired after all mods are done; though it does say mods shouldn't use it). Then I access the Item registry with ForgeRegistries.ITEM.getValue(...) and pass in the Items registry name to see if it is there. If it isn't there I don't add it to my list. Boom I have a List of Items that my item can now use, and they are from other mods.
  6. Why does that seem incorrect? It binds a texture to be used by the rendering engine. Then you need to tell it what part of the texture to render where. Take a look at how you render your gui backgrounds.
  7. Which it won't because the Item is never added to the registry... Good? Then why is the module needed in the first place? Why not just use the Item itself? Why not get rid of the thing that goes inbetween? If Module#doUseAction just calls Item#onItemUse and Module#doRighClickAction just calls Item#onItemRightClick what is the point?
  8. You can download a couple files here that link field names to their obfuscated names and the same thing with methods and parameters.
  9. I feel like this way of doing it is overboard. Here is how I would do it; under the following assumptions. I assume any and all modules interact with the player in some way. Most likely from some sort of right click action. IE Item#onItemUse or Item#onItemRightClick or some method within the Item class. I assume that it also applies no modifier to the feature of the Item in anyway, aka it works exactly like the Item in all use cases. Therefore wouldn't the Item itself work as a "module". Thus... class PowerFistItem extends Item { onItemUse(ItemUseContext context) { // Maybe no for loop just access the active Module Item? for (Item item : heldStack.getCapability(PowerFistCapability.CAPABILITY).orElseThrow(IllegalStateException::new).getModuleItems()) { result = item.onItemUse(context); // Maybe you'll have to construct your own ItemUseContext based on the ModuleItem... if (result != FAIL) return result;
  10. This isnt true at all.
  11. It looks like you are quoting him from somewhere I'm not sure if I should be talking to him the mod dev or to you about this issue. I've provided a means to get around the problem, and all you have done is say no that wont work. Why wont it work? Where does it fail at? Have you tried this at all? Are you a mod developer?
  12. This wont work outside of the development environment because Minecrafts variables and fields(etc) are obfuscated. You should use ObfuscationReflectionHelper or something similar instead.
  13. Register the item always. He said it himself. Do the functionality only when the item exists. You can obtain the Item as an object then use it's onItemUse/onItemRightClick method to do it's functionality.
  14. My goodness this is old, please don't necro old threads. Instead make your own. And when you do make your own post your code.
  15. You render something moving by changing the x and y value while rendering nothing else there is no special method or class. You have to implement it yourself.
  16. He could always check if the item exists by looking at the registry.
  17. First we should address how you are changing it. I assume you are using reflection, but how are you doing it?
  18. It has to do with the name of your armor material.
  19. Yes but they are both a case of assets not loading/being found by the game.
  20. You can continue to code without having this fixed. However the answer is very simple. Plus why'd you make a new thread for essentially the same topic... Does not equal ss:textures/models/armor/obsidianshard_layer_1.png
  21. You're mods.toml file has incorrect syntax.
  22. I believe this is the best way to do it at the moment, and yes it does stay away from the data driven system, but currently no way around that. Because datapacks as they are override the whole loot table. Which is a little counter productive when you just want to add to it or remove something from it.
  23. No don't do that. That's not what you should do at all use one of the other methods of playing a sound. It should go away when you remove it on the server.
×
×
  • Create New...

Important Information

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