-
Posts
101 -
Joined
-
Last visited
-
Days Won
1
Posts posted by hiotewdew
-
-
It's also possible the examplemod is somehow included in the classpath. Check "Project and External Dependencies", your "run/mods" folder, and the build path (rclick project and external dependencies -> Build Path -> Configure Build Path... look for examplemod
-
Try running "gradlew clean eclipse genEclipseRuns" and then refresh your gradle project (F5 when selecting project in package viewer)
-
Look at how vanilla biomes do it.
-
Global Loot Modifiers are likely the best method, but to show another method, you can actually use data combined with a bit of code to add loot tables fairly easily. Here's how I do it.
Then you can just define a loot table connected to that RL with the same pool name and it's done.
-
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
-
You'd want a tile entity with a UUID field that saves to NBT. Then, override onBlockPlacedBy in your Block class, get the tile entity, cast it to your TE type after an instanceof check, and set the uuid field to the provided player's UUID.
-
Show the contents of the "bin" folder? It might be that eclipse is duplicating the examplemod from a sourceset somewhere.
-
4 hours ago, Slastic said:
ok it works with
if(worldIn.isRemote) {
}
if there is something wrong with this tell me
No it doesn't. The second you run that on a DEDICATED SERVER it will crash. As I just explained, you need to use DistExecutor or packets.
-
Do not use Gradle 5.0, use 4.9
-
Your code is going to crash if you run it on a multiplayer server because it loads client classes regardless of if it runs or not. You need to use packets or DistExecutor
-
gradlew eclipse, F5 to refresh project
-
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)
-
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
-
Just now, diesieben07 said:
Just as a note, it doesn't actually do this properly.
Does it not? I've used the double supplier trick in a lot of code and it's all worked just fine on dedicated servers.
-
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.
-
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.
-
Dunno if you ever found a *real* fix - but my fix was disabling it in creative (the item has no use in creative, it's a bag that returns even after you die)
-
1 minute ago, diesieben07 said:
Okay. And this bug occurs only when in creative?
Yep.
-
1 minute ago, diesieben07 said:
Yeah, I'm an idiot. Of course not.
Your isEmpty check in hasCapability could be a problem. Why do you have that there?
Doesn't really matter - same bug happens with or without it. Had it originally, removed it, re-added, nothing.
-
2 minutes ago, diesieben07 said:
I cannot find you registering your capability anywhere.
I need to "register" my capability? How? Isn't already registered as an itemhandler capability, like builtin?
-
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:
http://www.minecraftforge.net/forum/topic/27248-player-inventory-synchronization/Quote1. 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:
Item:
Container:
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?
-
19 minutes ago, Draco18s said:
How do I register using NBT values?
-
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?
-
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"); } @Override 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).
[1.15] How do I change the grass/leaf/foliage colour of a biome?
in Modder Support
Posted
The "Biomes" class. In Eclipse, vanilla source is in Referenced Libraries -> forgeSrc-xx-xxx_mapped_snapshot_xxx.jar
Not sure about IntelliJ