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


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by hiotewdew

  1. Is your pack.mcmeta present and on the correct pack version?


    These are the actual error lines:

    [14Aug2020 01:36:11.471] [Render thread/WARN] [net.minecraft.resources.ResourcePackInfo/]: Couldn't get pack info for: java.nio.file.NoSuchFileException: D:\Mod Writing\forge-1.15.2-31.2.0-mdk\submechanica\build\resources\main\pack.mcmeta\pack.mcmeta
    [14Aug2020 01:36:11.548] [Render thread/WARN] [net.minecraft.resources.ResourcePackInfo/]: Couldn't get pack info for: java.nio.file.NoSuchFileException: D:\Mod Writing\forge-1.15.2-31.2.0-mdk\submechanica\build\resources\main\pack.mcmeta\pack.mcmeta


  2. 14 hours ago, FledgeXu said:

    Maybe you are right, I should use the TexturedParticle. I want to create a lighting circle and don't think i need the TexturedParticle for this, that's why I don't use the TexturedParticle.

    no no, instead of creating a custom particle type and particle data that you never use, instead just use BasicParticleType. This is as simple as deleting your particle type and data and replacing ObisidianParticleType::new with () -> new BasicParticleType(false)

  3. 1 minute ago, FledgeXu said:

    Could you give some example code?

    Ah unfortunately all my Particle code is textured particles using the Sprite particle renderer.

    One thing I am a bit confused on is why you are registering particle data and have a custom Particle type class when you can simply use the default BasicParticleType

  4. DistExecutor is used for physical side, whether you are using a minecraft client or dedicated server (in this case, this is the relevant information as only physical clients do rendering)


    isRemote references the logical side, where true is the logical client. Logical client just means if it's not running the gameserver instance on that thread, so isRemote could return false on clients on the server thread. Also, isRemote checks do not properly avoid classloading, unlike DistExecutor which avoids them by utilizing the double supplier trick.

  5. Not fully used Particle rendering on 1.15, only 1.14, but perhaps the issue is that your line has zero-depth? I believe you may need a small amount of depth for the line to actually render.

    Although, it looks like you may have that. Try ending the buffer? Also take a look at some vanilla particle renderers to see how those are done.

  6. So I was doing some reading trying to figure out why my item with an itemhandler capability was losing all of its items when it changed slots in creative on the server- and someone on the MMD discord mentioned that the client handles inventory in creative.

    I found this:


    1. If you remove ItemStack from player.inventory on both sides, no matter what - both will loose the stack (and yeah, that's 100%).

    2. If only on client - obviously you'll be out of sync and if you would swap that slot with other item, second one would appear (server will synchro you)


    3. BUT now - what you are doing is setting only on server. Funny thing here is gamemode.

    When in survival you client will go out of sync like in point 2. (and will most likely update with upcoming packet), but if you are in creative there is something like creative inventory - that's where magic happens, you see, when in creative server allows CLIENT to actually SEND ItemStacks - processes are not Server -> Client, but "reciprocal" (whetever this word means - doublt-sided/Bi-directional). You can edit anything you want, therefore if you would remove itemStack on server-side, but not on client, if you try to use removed-on-server item in this nulled slot, item will dissappear (server resynchronizes client when item is used) BUT if you would move this server-nulled item to other slot, then it's treated like one generated by creative inventory - and send from Client to Server. Server normally saves it to your server-side inventory.

    So apparently I'm doing something wrong with my cap provider/deserialization or something that is causing the client to not get the right items in the right spot.

    What I mean by "changing slots" is I will take the bag, move it from slot 1 on my hotbar to slot 2 and all the items will have disappeared. (It's a GUI, and definitely not desync, relogging fixes nothing).

    Otherwise works fine in survival on server and on the client (although I have noticed it a few times in creative on the client - possibly the effective server thread is responsible)


    Capability Provider:






    Not sure if I should be using the NBT argument from initCapabilities somehow. Is there a way to force handling on the server for my container - even in creative?


  7. 11 minutes ago, Draco18s said:

    Yes, and a good example of how my blockstate should look. I can try it when I'm at my computer but my mesher registration might not be right. Does

    new ModelResourceLocation("registryname", "type=1");

    work as a valid location to get a variant with the type attribute with the value 1?

  8. I've gotten some help in the MMD Discord, but I'm still not fully understanding what my JSON files should look like after using the mesher to register item variants. This is my registration code:

    // Model registration
              for(BlockGenericSkull skull : genericskulls.keySet()) {
                    HeadItemMeshDefinition meshDefinition = new HeadItemMeshDefinition(skull);
                    ItemBlockSkull item = (ItemBlockSkull) skull.getItemBlock();
                    ModelBakery.registerItemVariants(item, meshDefinition.defaultModelResourceLocation);
                    for (int i = 0; i < skull.texCount; i++)
                        ItemStack stack = new ItemStack(item);
                        stack.setTagCompound(new NBTTagCompound());
                        stack.getTagCompound().setInteger("TYPENUM", i);
                        ModelBakery.registerItemVariants(item, meshDefinition.getModelLocation(stack));
                    ModelLoader.setCustomMeshDefinition(item, meshDefinition);
    And this is my ItemMeshDefinition:
    package its_meow.betteranimalsplus.client;
    import its_meow.betteranimalsplus.common.block.BlockGenericSkull;
    import its_meow.betteranimalsplus.common.item.ItemBlockSkull;
    import net.minecraft.client.renderer.ItemMeshDefinition;
    import net.minecraft.client.renderer.block.model.ModelResourceLocation;
    import net.minecraft.item.ItemStack;
    public class HeadItemMeshDefinition implements ItemMeshDefinition
        public final ModelResourceLocation defaultModelResourceLocation;
        public HeadItemMeshDefinition(BlockGenericSkull head)
            this.defaultModelResourceLocation = new ModelResourceLocation(head.getRegistryName(), "inventory");
        public ModelResourceLocation getModelLocation(ItemStack stack)
            if(stack != null && stack.getItem() instanceof ItemBlockSkull && stack.hasTagCompound())
                return new ModelResourceLocation(this.defaultModelResourceLocation.getResourcePath(), "type=" + stack.getTagCompound().getInteger("TYPENUM"));
            return this.defaultModelResourceLocation;


    How should my JSON models look? I only want to change my texture, not transforms/models using the NBT data. Do I need an "item blockstate"? How should it look?

    I don't really have a base of the JSONs to work off of, otherwise I would link them too.
    Also not looking for recommendations on how to do it another way, currently sticking to NBT as it works best for my project and won't be removed in 1.13 (metadata).

  • Create New...

Important Information

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