sciwhiz12

Aha! Remove the file 'modid-1.0.jar' from the 'run/mods' folder. If you placed it there, remember that you are running the dev client; any code in src/main should automagically be found. Also, please change the defaults in your build.gradle.

Forge for 1.16.1 is in BETA. This means crashes and bugs are expected to occur while the Forge dev team is still fixing what got broken during the update. While 1.16.1 is now in active development and support, it will be a few days/weeks until a stable/recommended release for Forge 1.16.x. If you are wanting to test and find bugs, by all means please do so and report them to the issues tracker. But, if you're just wanting to play modded 1.16, please wait until Forge is out of beta once again, and until a recommended Forge version is released.

Forge for 1.16.1 is in BETA. This means crashes and bugs are expected to occur while the Forge dev team is still fixing what got broken during the update. While 1.16.1 is now in active development and support, it will be a few days/weeks until a stable/recommended release for Forge 1.16.x. If you are wanting to test and find bugs, by all means please do so and report them to the issues tracker. But, if you're just wanting to play modded 1.16, please wait until Forge is out of beta once again, and until a recommended Forge version is released.

@EventHandler does not exist in the current supported versions of Minecraft Forge. Either you are misleading us with your Minecraft version, or you have not read a basic tutorial, the Forge documentation, or even the provided example mod in the Forge MDK. Please read some tutorials, or watch this video tutorial (and series) by McJty.

Also, from looking at other posts, do not link your unrelated thread on other threads. Please.

It is difficult to troubleshoot your issues without the specific world and modpack involved. What I can give you is advice to follow these troubleshooting steps: Backup your modpack & world, preferrably to a separate folder. Remove one of your mods (move it outside the mods folder) Any order will suffice, but I recommend first removing any mods not adding blocks/items. Load a copy of your world, and verify if the issue still exists. If it does, the mod you removed is probably not the cause. Repeat from step 2. (do not place back the mod until the end) If the issue does not exist, then the mod you removed probaby is the cause. To verify again, replace all your mods except the most recent mod (the one you just removed). If the issue does not exist, then that mod is most likely the cause of the issue. Report it to the mod authors (please post here to inform) If the issue exists once more, start again from step 2, with that mod already removed. As a experiment, send the exact contents of your modpack folder to your friend, to see if they still have the same issue with your world.

Forge for 1.16.1 is in BETA. This means crashes and bugs are expected to occur while the Forge dev team is still fixing what got broken during the update. While 1.16.1 is now in active development and support, it will be a few days/weeks until a stable/recommended release for Forge 1.16.x. If you are wanting to test and find bugs, by all means please do so and report them to the issues tracker. But, if you're just wanting to play modded 1.16, please wait until Forge is out of beta once again, and until a recommended Forge version is released.

Forge for 1.16.1 is in BETA. This means crashes and bugs are expected to occur while the Forge dev team is still fixing what got broken during the update. While 1.16.1 is now in active development and support, it will be a few days/weeks until a stable/recommended release for Forge 1.16.x. If you are wanting to test and find bugs, by all means please do so and report them to the issues tracker. But, if you're just wanting to play modded 1.16, please wait until Forge is out of beta once again, and until a recommended Forge version is released.

I can't see anything out of place with your mods.toml, which leads me to believe that your run dirs, somewhere, has another mods.toml. Please download a fresh copy of the Forge MDK, configure it until it runs to the client and the example mod is loaded. Then, delete everything from the example mod's src and resources, copy over your src & resources. Then try running. If that doesn't work, please post the folder containing your build.gradle and mod code. I am mystified as how this is occuring (unless you are running the wrong run configuration)

stack.getTag().getList("lightsPosLight", Constants.NBT.TAG_LIST).forEach(inbt -> te.addLightPos(((LongNBT)inbt).getLong())); private static final String NBT_LIGHTS_KEY = "lightsPosList"; It seems you mistyped your list tag's key.

Hmm, that should have fixed it, unless another mods.toml still exists with that line. Could you upload your code as a Git repo?

Remove the following: updateJSONURL="minecraftforge.net/versions.json" displayURL="minecraftforge.net" I recommend removing any property which you will not use. (logoFile, *URL) BTW, might I suggest lengthen your modid from 'devd'? Try 'devsdream', or whatever you please.

Looking at the crash logs more carefully, it really doesn't seem that @ChromaKey81's code is at fault here.

What do you mean by the textures not working? The blocks, or the items? Please post an updated debug.log, and update the files on your GitHub with what you have modified.

If the gun model will not need to move dynamically and the gun model is defined using model JSONs, use item display transforms through the "display" option (see MC wiki article on Item Models). I recommend using a program like Blockbench to edit the model's display transforms.

Change the modid in the texture variable in the model json. { "parent": "block/cube_all", "textures": { "all": "pxloptestmod:blocks/copper_block" } } Replace the 'pxloptestmod' with your modid, 'coppermod'. Do this for each model json. Also, change 'blocks' into 'block' (and 'items' into 'item', if it exists). "coppermod:block/copper_block" points to "assets/coppermod/textures/block/copper_block.png"

Items by themselves don't hold NBT data, but ItemStacks do. { Item: "minecraft:stone", Count:1b, tag: { "CustomData": 3s, "display": { "Name": "rock" } } } The ItemStack's NBT tag is stored in the tag tag, which is accessible through #getTag. CustomData and display are child tags, which can either be retrieved through #getTag().getX methods (getBoolean, getCompound, getShort, etc.) or, for Compound tags, the #getChildTag(String) (getChildTag("display"), but not for "CustomData") #getTag and #getChildTag may return null, if no such tag exists. Check #hasTag() for the existence of the tag, and null checks for child tags. Writing data to the tag? Better use #getOrCreateTag() and #getOrCreateChildTag(String); they create the tags, if they don't exist yet. Directly setting the tags of an ItemStack? Use #setTag(CompoundTag) for the tag tag, and #setTagInfo(String, INBT) for any type of child tags.

Quick guide on NBT: (note: using 1.15, but all is the same for 1.14) NBT (Named Binary Tag) is the format used by Minecraft mostly for keeping internal data, such as player data, world data, etc. NBT has different tags, which define what type of data they store. All tags implement INBT. Compound tags holds a combination of other tags, which can all be the same or different type. Represented by CompoundNBT. Number tags holds different types of number, corresponding to Java number primitives. All number tags extend NumberNBT. byte = ByteNBT, short = ShortNBT, int = IntNBT, float = FloatNBT, long = LongNBT, double = DoubleNBT String tags hold a string, corresponding to String. Represented by StringNBT. Array or collection tags holds either 0+ tags of the same type, depending on what the tag allows. All array tags extend CollectionNBT. List tags may hold any amount of one type of tags. Represented by ListNBT. Number-specific array tags: byte[] = ByteArrayNBT, int[] = IntArrayNBT, long[] = LongArrayNBT. End tags are special. They have no representation in-game; they represent an end of an array or compound tag when stored. Represented by EndNBT. Classes are in net.minecraft.nbt. CompressedStreamTools for reading and writing NBT to files. NBTUtil for reading/writing GameProfile, UUID, BlockPos, BlockState. JsonToNBT for converting JSON to NBT. See the Minecraft wiki page on NBT for the technical details.

If you're connecting to a server, modded or vanilla, and you have mods which are not client-side only, you either remove those mods, or ask the server if they'll install the mod (and Forge, if needed).

Oh, and don't call Minecraft#getItemColors(). Register a listener for ColorHandlerEvent.Item (make sure to register only on the client side).

// ItemModelGenerator.class, MC version 1.15.2, mappings 20200514-1.15.1 public static final List<String> LAYERS = Lists.newArrayList("layer0", "layer1", "layer2", "layer3", "layer4"); It seems coded for 5 item layers. But, as Lists.newArrayList "creates a mutable ArrayList instance", you might be able to add more layers manually.

I phrased it wrongly; it was rendering as if the nameplate was a separate entity from the player, teleporting every tick, so movement means the nameplate had to catch up to the player. Anyway, that problem somehow fixed itself, but a new problem has manifested. As the player model moves farther away from the center of the screen, held items (and, if the player is flying, the text on the nameplate) move also in the same direction. Also, the items are rendered in front of the player model, which is plainly wrong. Also, the nameplate and items were rendered in the inventory screen, but as I'm going to disable inventory access for players using cameras, this won't really be a problem I think. If anyone can please help me troubleshoot this, I will greatly appreciate it. The code is at my GitHub, branch 'camera'.

It works! And such a simpler solution than modifying class bytecode. A problem that I see doing this though is the nameplate is delayed in rendering, so it doesn't exactly follow the player model. (like when using command blocks to teleport armor stand to the player, there's a small gap when the player moves until the armor stand gets back in position to the player)

So, I'm currently in the process of making a mod that adds defensive blocks and items. Code is at GitHub, branch 'camera'. Specifically, I'm creating a camera block. I'm trying and learning on how to change the current camera perspective. I've already done it using Minecraft#setRenderViewEntity, however the original player entity is not rendered. I've narrowed it down to this line of code in WorldRenderer, which is called for all entities in the world: // WorldRenderer.class, version 1.15.2, 20200514-1.15.1 mappings, line 947 if ((this.renderManager.shouldRender(entity, clippinghelperimpl, d0, d1, d2) || entity.isRidingOrBeingRiddenBy(this.mc.player)) && (entity != activeRenderInfoIn.getRenderViewEntity() || activeRenderInfoIn.isThirdPerson() || activeRenderInfoIn.getRenderViewEntity() instanceof LivingEntity && ((LivingEntity)activeRenderInfoIn.getRenderViewEntity()).isSleeping()) && (!(entity instanceof ClientPlayerEntity) || activeRenderInfoIn.getRenderViewEntity() == entity)) { That's a long conditional, so I've broken it down into three parts that must all be true for the entity to render: The entity's renderer's #shouldRender returning true, OR entity is/has passenger of the player The entity is not the current renderViewEntity, OR the render is in 3rd person, OR the renderViewEntity is an instance of LivingEntity, AND the renderViewEntity is sleeping The entity is not an instance of ClientPlayerEntity, OR the entity is the renderViewEntity The first two conditions are fine, however the third condition is giving me trouble because the player entity is not the renderViewEntity anymore, so the condition fails. What I'm asking is, is there a better way to get around that third condition, without having to resort to using a coremod and rewriting the method? I am afraid to use coremods, after looking through posts by Forge modders which clearly state to never, ever use coremods if I can help it.

A rule of working with applications and networking: never trust the client. Always perform validation and logic/actions on the server-side, since you never know if a client and the data/packets they send are legitimate or malicious. Also, when getting the data, check ItemStack#hasTag, because ItemStack#getTag will return null if no tag exists for the client. When putting data, use ItemStack#getOrCreateTag.