Jump to content


  • Posts

  • Joined

Everything posted by American2050

  1. Oh yes, I saw that mod, but that's what I was trying to prevent, I want to provide the Config screen myself and not depend on other mods.
  2. Thanks will give it a go. PS: Do I need to manually build the screen items by item, or is there something built in that can handle it, like in the past we had GuiConfig?
  3. I haven't been updating mods in a while but I remember back in 1.12.2 and older versions there was a "GuiConfig" that we could extend and together with a "IModGuiFactory" that was enough to register the in-game Config GUI from @Mod passing the guiFactory in question. All that to get the "Config" button working in-game. What is the method to achieve this in newer versions like 1.18.x and 1.19.x - I couldn't find anything in the Documentation (Or maybe I missed it)
  4. So I'm making a mod that is client side only (Which I have working, but haven't fully tested the scenario of joining a server that doesn't have this mod on it) Bur following the documentation I found under "Concepts > Sides" that we should add an specific line. So my code now looks like this. @Mod(ModInfo.MOD_ID) public class RMH { public RMH() { ModLoadingContext.get().registerExtensionPoint(ExtensionPoint.DISPLAYTEST, () -> Pair.of(() -> FMLNetworkConstants.IGNORESERVERONLY, (a, b) -> true)); FMLJavaModLoadingContext.get().getModEventBus().addListener(this::clientSetup); //MinecraftForge.EVENT_BUS.register(this); } private void clientSetup(final FMLClientSetupEvent event) { ModLoadingContext.get().registerConfig(ModConfig.Type.CLIENT, ModConfigs.SPEC, "RemoveMouseoverHighlight-client.toml"); MinecraftForge.EVENT_BUS.register(RemoveHighlight.class); if(ModConfigs.USE_KEY.get()){ MinecraftForge.EVENT_BUS.register(new KeyMonitor()); MyKeyBindings.register(); } } } The line that I added mentioned in the documentation is ModLoadingContext.get().registerExtensionPoint(ExtensionPoint.DISPLAYTEST, () -> Pair.of(() -> FMLNetworkConstants.IGNORESERVERONLY, (a, b) -> true)); I even commented out MinecraftForge.EVENT_BUS.register(this); which I'm not sure I should... The mod still works, but for some reason it doesn't feel right. Do I need to have anything else, or this should do it?
  5. I need to learn all those shortcuts. Will take a look at that, didn't know what it was called, but yes, for sure comes way more handy that trying to figure out where a class exists.
  6. On your IDE you probably have a folder called "External Libraries" on your project tree. In there you can find among a whole lot of other things, one folder that in particular may come handy. For example for 1.17.1 (Should be similar if not the same for 1.16.5) Gradle: net.minecraftforge:forge:1.17.1:37.1.1_mapped_official_1.17.1 (For 1.16.5 the name will change a little bit of course) When you open this tree you will find net > minecraft > level > world > block > DaylightDetectorBlock In there you can take a look at it's code to see what this block is doing in order to detect when it's daylight and when it's not. Haven't been doing MC modding in a time, but I guess this block been that it extends an entity block, it "ticks" and so has this method where the "magic" happens. tickEntity
  7. I am not 100% sure, but I believe Java 17 is only for Minecraft 1.18 For previous versions (or at least for 1.12) try with Java 8 (Also called 1.8.0) Here you have a resume https://minecraft.fandom.com/wiki/Tutorials/Update_Java PS: Apparently for MC 1.17 it's Java 16 that is needed.
  8. I know in 1.12 there was an event called DrawBlockHighlightEvent but I can't find it on 1.18 (Maybe I'm looking in the wrong place) Anyone know what this event is called now, or where to find it? Thanks a lot.
  9. Ok so... After looking around a bit more I found out the solution. I didn't need to create the model for my BlockItem from my ItemModelProvider, but instead from my BlockStateProvider using the method `simpleBlockItem` That registered the model for the item of the block without any issue.
  10. So I have a Class extending ItemModelProvider to generate the .json files for my items models. The one problem I'm having is when I want to generate the item for a block. In this case I'm using the method `withExistingParent` but the problem is that when I point to the "parent" (in this case the model for the block itself) it complains about that file not existing. And while it's true that it doesn't exists, it does exist on the "generated" resources. withExistingParent(ModItems.BLACK_STONE_ITEM.get().getRegistryName().getPath(), new ResourceLocation(ModInfo.MOD_ID, "block/black_stone")); So my question is, how do I point to that folder instead of the "regular" resources folder?
  11. I was following the guide at https://mcforge.readthedocs.io/en/1.16.x/gettingstarted/ and it mentions we should change the instances of "examplemod" on build.gradle to the nameid of the mod we creating. And it also mentions we should change the group too. There are a couple of missing steps here. It doesn't mention we should change the project structure to reflect this changes. And more important, it doesn't mention the mods.toml file at all. Without updating this file with the correct values Minecraft wont start. EDIT: PS: Just noticed the mention to this comes on the next step. I guess then on step 1 it shouldn't be mention how to run the mod yet?
  12. I am guessing registering a config GUI is related with registering Configuration files also, but I can't find documentation about neither of those for 1.16 Any clue where I can find the steps to do so? Or 1.7.10 methods still apply? (Maybe it was 1.10)
  13. I'm new to using IntelliJ when modding for Minecraft, have been using Eclipse for the most part, but now I'm giving IntelliJ a try. I have one "key" problem with IntelliJ. After refactoring my package route from com.example.examplemod to mramericanmike.rmh. Now each time I runClient I'm still getting the old code been read from "Somewhere" How is it possible if the package and main class file no longer exist, they are still been used when runClient is called? I'm still seen in console [Worker-Main-6/INFO] [co.ex.ex.RMH/]: HELLO FROM FMLCommonSetupEvent 57 notice the co.ex.ex.RMH when my new package is different and the logger was changed to output LOGGER.info("HELLO FROM FMLCommonSetupEvent 7"); Notice changed 57 to 7 I tried running genIntellijRuns again, but it did nothing. What am I missing here?
  14. So I was looking at the documentation, but couldn't find anything related on how to get the Config button from the mods window working. I wasn't able to find much information on this topic other that some probably outdated tutorials on Youtube. Any guidance is welcome. I remember already having many issues with this topic time ago back in 1.12 I believe it was. PS: I posted on the wrong subforum and can't move it with the edit function.
  15. I see. Thanks a lot. And one question. How would I "register" for the items the different models (States) it can have. I tried looking at the vanilla Clock but on Items, it's just a generic Item without anything special on it. (I'm guessing Vanilla is changing the texture from some event class). How should I implement multiple models for my item and change between them.
  16. I'm having an issue with the rendering of a simple texture that worked perfectly as expected in 1.12.2 but on 1.16.3 it looks just weird. The .json on models/item is: { "parent": "item/generated", "textures": { "layer0": "machinecards:items/frame" } } The texture is attached. In 1.12.2 the item class extended Item and implemented IHasModel. Not sure if that means anything or not since I don't remember how Forge 1.12.2 worked. But I think IHasModel was a default thing to do for items? Any idea how to "fix" this so it renders again as it used to in 1.12. Thanks in advance.
  17. I never had issues with this before, but I guess the mappings that come with the MDK download are out of date? Didn't know we had to manually change them when downloading the MDK I guess that's new also on 1.16. Or is there a reason the "Recommended" version doesn't update this value? My 1.16.3 download (forge-1.16.3-34.1.0-mdk) had on mappings mappings channel: 'snapshot', version: '20200514-1.16' Where you got the 20200723.1.16.1 from? So I can got get the corresponding for the 1.16.3- 34.1.0 version. Thanks a lot.
  18. Thanks, I got it working. I am confuse as to why vanilla uses for their recipes the "has_the_recipe" if it has the recipe already, how can it be the reward for the advancement? I my case I removed that requirement, not sure when that should be used.
  19. Even when the block shows with no problem. I'm getting an error like this on console. My Blockstate json is: { "forge_marker": 1, "defaults": { "textures": { "bottom": "block/terracotta", "top": "block/terracotta", "side": "block/terracotta" } }, "variants": { "facing=east,half=bottom,shape=straight": { "model": "block/stone_stairs" }, "facing=west,half=bottom,shape=straight": { "model": "block/stone_stairs", "y": 180, "uvlock": true }, "facing=south,half=bottom,shape=straight": { "model": "block/stone_stairs", "y": 90, "uvlock": true }, "facing=north,half=bottom,shape=straight": { "model": "block/stone_stairs", "y": 270, "uvlock": true }, "facing=east,half=bottom,shape=outer_right": { "model": "block/stone_stairs_outer" }, "facing=west,half=bottom,shape=outer_right": { "model": "block/stone_stairs_outer", "y": 180, "uvlock": true }, "facing=south,half=bottom,shape=outer_right": { "model": "block/stone_stairs_outer", "y": 90, "uvlock": true }, "facing=north,half=bottom,shape=outer_right": { "model": "block/stone_stairs_outer", "y": 270, "uvlock": true }, "facing=east,half=bottom,shape=outer_left": { "model": "block/stone_stairs_outer", "y": 270, "uvlock": true }, "facing=west,half=bottom,shape=outer_left": { "model": "block/stone_stairs_outer", "y": 90, "uvlock": true }, "facing=south,half=bottom,shape=outer_left": { "model": "block/stone_stairs_outer" }, "facing=north,half=bottom,shape=outer_left": { "model": "block/stone_stairs_outer", "y": 180, "uvlock": true }, "facing=east,half=bottom,shape=inner_right": { "model": "block/stone_stairs_inner" }, "facing=west,half=bottom,shape=inner_right": { "model": "block/stone_stairs_inner", "y": 180, "uvlock": true }, "facing=south,half=bottom,shape=inner_right": { "model": "block/stone_stairs_inner", "y": 90, "uvlock": true }, "facing=north,half=bottom,shape=inner_right": { "model": "block/stone_stairs_inner", "y": 270, "uvlock": true }, "facing=east,half=bottom,shape=inner_left": { "model": "block/stone_stairs_inner", "y": 270, "uvlock": true }, "facing=west,half=bottom,shape=inner_left": { "model": "block/stone_stairs_inner", "y": 90, "uvlock": true }, "facing=south,half=bottom,shape=inner_left": { "model": "block/stone_stairs_inner" }, "facing=north,half=bottom,shape=inner_left": { "model": "block/stone_stairs_inner", "y": 180, "uvlock": true }, "facing=east,half=top,shape=straight": { "model": "block/stone_stairs", "x": 180, "uvlock": true }, "facing=west,half=top,shape=straight": { "model": "block/stone_stairs", "x": 180, "y": 180, "uvlock": true }, "facing=south,half=top,shape=straight": { "model": "block/stone_stairs", "x": 180, "y": 90, "uvlock": true }, "facing=north,half=top,shape=straight": { "model": "block/stone_stairs", "x": 180, "y": 270, "uvlock": true }, "facing=east,half=top,shape=outer_right": { "model": "block/stone_stairs_outer", "x": 180, "y": 90, "uvlock": true }, "facing=west,half=top,shape=outer_right": { "model": "block/stone_stairs_outer", "x": 180, "y": 270, "uvlock": true }, "facing=south,half=top,shape=outer_right": { "model": "block/stone_stairs_outer", "x": 180, "y": 180, "uvlock": true }, "facing=north,half=top,shape=outer_right": { "model": "block/stone_stairs_outer", "x": 180, "uvlock": true }, "facing=east,half=top,shape=outer_left": { "model": "block/stone_stairs_outer", "x": 180, "uvlock": true }, "facing=west,half=top,shape=outer_left": { "model": "block/stone_stairs_outer", "x": 180, "y": 180, "uvlock": true }, "facing=south,half=top,shape=outer_left": { "model": "block/stone_stairs_outer", "x": 180, "y": 90, "uvlock": true }, "facing=north,half=top,shape=outer_left": { "model": "block/stone_stairs_outer", "x": 180, "y": 270, "uvlock": true }, "facing=east,half=top,shape=inner_right": { "model": "block/stone_stairs_inner", "x": 180, "y": 90, "uvlock": true }, "facing=west,half=top,shape=inner_right": { "model": "block/stone_stairs_inner", "x": 180, "y": 270, "uvlock": true }, "facing=south,half=top,shape=inner_right": { "model": "block/stone_stairs_inner", "x": 180, "y": 180, "uvlock": true }, "facing=north,half=top,shape=inner_right": { "model": "block/stone_stairs_inner", "x": 180, "uvlock": true }, "facing=east,half=top,shape=inner_left": { "model": "block/stone_stairs_inner", "x": 180, "uvlock": true }, "facing=west,half=top,shape=inner_left": { "model": "block/stone_stairs_inner", "x": 180, "y": 180, "uvlock": true }, "facing=south,half=top,shape=inner_left": { "model": "block/stone_stairs_inner", "x": 180, "y": 90, "uvlock": true }, "facing=north,half=top,shape=inner_left": { "model": "block/stone_stairs_inner", "x": 180, "y": 270, "uvlock": true } } } And the json model for the item is: { "parent": "block/stairs", "textures": { "bottom": "block/terracotta", "top": "block/terracotta", "side": "block/terracotta" } } I don't understand what may be causing the errors show in the log. PS: I'm also having issues passing a texture on a multipart blockstate (For a fence) I'm not sure in this case, how should I convert this file to be able to pass a texture, for example #post into the block model json. Blockstate { "multipart": [ { "apply": { "model": "terracottaworld:block/terracotta_post" }}, { "when": { "north": "true" }, "apply": { "model": "block/oak_fence_side", "uvlock": true } }, { "when": { "east": "true" }, "apply": { "model": "block/oak_fence_side", "y": 90, "uvlock": true } }, { "when": { "south": "true" }, "apply": { "model": "block/oak_fence_side", "y": 180, "uvlock": true } }, { "when": { "west": "true" }, "apply": { "model": "block/oak_fence_side", "y": 270, "uvlock": true } } ] } Block model (Let's say I change block/terracotta with #post here. { "parent": "block/fence_post", "textures": { "texture": "block/terracotta" } } Everything renders, so no sure why the warnings/errors?
  20. Thanks a lot. I guess I was missing the "forge_marker": 1, Got it working now
  21. Is this even possible? I have several blocks that all use the same Model and all I need to be changed on each of them is a texture. Is it possible from the Blockstate .json file to pass the texture along?
  22. Sorry if this question was asked before, I sure it was, but couldn't find it with the search on the forum. How would I do it so once an specific Minecraft item is collected, a recipe on my mod gets unlocked and added to the book. Without doing anything, once I craft my block, the book remembers the recipe but how would I do it so when the player collects an specific block, my recipe shows on the book? Thanks in advance.
  23. Is it common that when running from within IntelliJ it just comes as "NONE" I assume it's because we don't have a jar file yet. But on my mods.toml file I have version="${file.jarVersion}" and on build.gradle I have this version = '1.0' group = 'mramericanmike.terracottaworld' // http://maven.apache.org/guides/mini/guide-naming-conventions.html archivesBaseName = 'TerracottaWorld' jar { manifest { attributes([ "Specification-Title": "terracottaworld", "Specification-Vendor": "mramericanmike", "Specification-Version": "1", // We are version 1 of ourselves "Implementation-Title": project.name, "Implementation-Version": "${version}", "Implementation-Vendor" :"mramericanmike", "Implementation-Timestamp": new Date().format("yyyy-MM-dd'T'HH:mm:ssZ") ]) } } I think it should be good to work like that right? I'm not taking the value from a java file, but at least it will update when I change it for the build.
  • Create New...

Important Information

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