Leaderboard

Alright, occasionally I get bored and I do one of these posts. I looked at their latest (as of the time of this post) video: https://youtu.be/F79DNgi5d_o. Here is what I found: [0:40] "Call this calls ModSpawnEggItem" - completely irrelevant how you call this class. [1:00] "Click here, to add constructor matching super" - why? How is this relevant to modding? This is basic Java knowledge. Either you explain what you do here (which means you need to explain what constructors are and what inheritance is) or you assume this knowledge, which means you don't need to talk about this at all. [1:08] "I think it could be public, but we'll just make it protected" - He doesn't even know how Java visibility modifiers work himself. Great teacher for modding a game written in Java! (Side note here, this is just personal preference but god damn it TechnoVision, USE ALT-ENTER! Using the mouse is sooooo sloooooow). [1:49] Why using a Lazy? Instead of a Supplier? You get a Supplier out of the DeferredRegister anyways, no need to convert it to a Lazy. [1:55] He keeps calling "?" in a generic type "a generic". This is not the correct name. This is called a wildcard. [3:24] Him calling that super constructor with null as the type will result in a null key in SpawnEggItem#EGGS. That should be cleaned up. His explanation as to why it "doesn't matter" (it does...) is also not an explanation. He just mumbles a view techno-babble-esque words. [6:23] "This field is in SpawnEggItem and it's this map here" *highlights a local variable in a completely different class*. Yeah right. [7:05] Then he proceeds to type in and explain copy pasta code from vanilla as if it was his own creation. What the hell? [8:19] That is a terrible explanation of casting. [12:23] "We want this to be clear, every single time." In a method that is called once. Why? This is not an explanation. [13:11] "This is like a utility class". No. Not it is not. [13:56] Utterly broken. Why is this in a client-only event subscriber? This will make the mod not work on servers. [14:11] "Right when the entities have been registered" - No. That is not what this event does. This event fires when you should register your entities, not when they have already been registered. This event is also the wrong choice for most of what is done in the initSpawnEggs method. [17:05] Should be using data generators. [18:14] Again, should be using data generators. [18:30] "File > Save all" LOL this is not eclipse. On an overall note: This code is 1:1 the same crap that TurtyWurty showed in his video from a couple of days earlier. Oh but don't be fooled, he did not come up with it either. He copied it from Cadiboo, who I vaguely remember still spending the time (with me partly helping him if I remember correctly) to figure this crap out on the Forge discord and this forum. So. Question answered? That is the problem with TechnoVision, TurtyWurty, HarryTalks and all those "Modding tutorial" people on youtube (McJty specifically excluded!). They are unoriginal, unhelpful, promote bad coding practices and even outright broken code.

Capabilities store "arbitrary data." If your magic system isn't "arbitrary data" then something is very wrong indeed.

Take a look at the EntityRenderer#renderName method...to draw an image instead of text you could just use a textured quad

If you only copied over the relevant files from a different project, then those source folders won't exist normally. You will need to create them manually and then rerun your gradle commands to tell everything that "hey, I exist now".

Currently Supported Versions: Latest: 1.16.X LTS: 1.15.X User Support FAQ Modder Support FAQ and Common Issues We do not currently provide support or updates for any other versions except in cases of severe security issues. On LTS's: Forge's support for Minecraft versions will try to follow a predictable cycle, assuming Mojang also follows a predictable cycle. We will always actively target the latest Minecraft version as ever, however we will also support the most recent non-latest version as an "LTS" version. An LTS version differs slightly from the latest version, in that any new features you may want to add to it, must target the latest version, only once it has been merged in, can it be backported. (The exception to this is if the feature is non-applicable to the latest version.) The Forge Team will also mostly be focusing on the latest. This is so the community has time to stabilize a bit and gives modpack developers some time to create something special. But still have Forge running full steam ahead. This thread is here as a landing page for the "Currently Supported" Announcement at the top of every forum page

Forge Version: 34.1.0 Minecraft Version: 1.16.3 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Intro: Hello everyone, it's finally that time. A recommended 1.16 build is here. We had to wait longer then I wanted to because there were a lot of problems with the initial 1.16 release from Mojang, enough that it was obvious that a .1/.2 was needed. So we waited for Mojang to stabilize the 1.16 branch, out came .1, .2, and .3. Each one same with its own surprises, the main one we have to mention is 1.16.2's major re-write to biomes. Allowing them to now be data driven. This is a very powerful thing that moves Minecraft to a more flexible state, but it also meant all our old hooks had to be re-designed. Every Minecraft version moves towards a better engine, but unfortunately that means we have to work with the interim steps. So if there are any issues modders face with Biomes/Worlds now being mostly data driven, speak up an expect a few iterations of the tools Forge provides you for these things. But remember, now that we are in a Recommended Build it means Forge will stay stable API wise for the rest of the 1.16 lifecycle. Mod License: There has always been little skirmishes about what license a particular mod is released under. To try and help address that, we have now made it mandatory that mods specify a "license" value in their mods.toml. That is the text file containing metadata about the mod, such as version, name, author, etc. This is a simple text entry, it can be anything the modder wishes as long as it is present. The MDK ships with it filled in for you with "All Rights Reserved" which is the default copyright stance in almost every jurisdiction. I highly encourage modders to take a moment and think about how they want their mod to be used, modified, and distributed. And then pick a license that properly expresses their wishes. If you want a open source license https://choosealicense.com/ can help you pick. However, it is your mod, so whatever license you want is fine. Please do not take this as a push to one style or another. Simple as a reminder to choose something and let your users know. Support: With this being released, it officially triggers our support policies as described in the LTS post. This means that 1.14 is now EOL. It can still be used and developed for. It just means that we no longer provide active support for it. And we encourage all users/modders to update to a more modern version. Changelog: New: New model loading system with improved performance and functionality. Reorganized mod loading to increase loading speeds and better integrate with vanilla threading. New armor knockback resistance hooks Added custom item integration with Piglin trades. Added support for items to have pumpkin-enderman like behavior. Added build system verification tools. Added event for controlling data/asset reloading. Added hook to add modded Raid members. Added a dedicated event for registering commands. Added Mixin to the installer. Added event for entities leaving the world. Added IModBusEvent marker interface to all events that are fired on the ModEventBus vs the main Forge bus. Added mandatory (1.16.2+) license field in mods.toml Added support for modded elytra-like items. Added hook to allow Biomes to specify edges better. Added hook to allow better block control over tool-block interactions. Added hook for manipulating whether a fluid can create a source block. Added an EntitySizeEvent instead of EntityHeightEvent Added user friendly exceptions when config loading fails Added particle culling, which should increase performance by not rendering particles that are not on screen. Added better datagen validation for tags. Added dataprovider for global loot modifiers Added scaffolding movement hook Added support for custom tag types Added BiomeLoadingEvent, that allows for mods to edit biomes. Fixes: Fixed caching issue with mod manifest files. Improves starting times. Fixed vanilla models not correctly deferring to Forge's system. Fixed early load GUI showing when running data generators Fixed block update issues related to reverting with BlockSnapshot Fixed locate command patch. Fixed block drops not working in some cases. Fixed villager trades having non-applicable enchants Fixed tooltip rendering issues Fixed sneaking while swimming Fixed harvest level and harvest tool Fixed screen tooltip not displaying Fixed creative screen arrows Fixed attribute registration on modded entities Fixed block render types not being applied to block items Fixed swimming speed being too slow Fixed break speed event having null position Fixed tag issue when connect to vanilla server Fixed some classes being unsafe in concurrent loading Fixed capability data being null in player clone event Fixed double chests updating issues Fixed language parsing Fixed datagen crashing due to tags Fixed client chat received event not having the sender UUID Fixed loading screen color and text to match new Mojang Studio's colors. Fixed improper handling of baked lighting in forge light pipeline Fixed getQuads not having model data Fixed tooltip render events not having matrixstacks Fixed multi-layer item rendering Fixed stencil support initialization Fixed swap offhand keybinds not working in GUI Fixed null checks missing in ForgeIngameGUI Fixed incorrect keybind names Fixed LivingEquipmentChangeEvent not being posted Fixed canRepair not being true by default Fixed race condition for DeferredRegister with custom registries Fixed client world capabilities not being collected Fixed TagEmptyCondition using client tags and not server Fixed ExtendedButton using narrator text Fixed LivingJumpEvent for players on horses Fixed duplicate mod files from mod file scan causing objects to load twice. Fixed model & blockstate datagen inconsistencies Fixed datapacks being not loaded correctly in the Datapack menu screen Fixed soundloadevent being posted on the wrong bus Fixed chunkdataevents using different data tags Fixed patch for PlayerSetSpawnEvent Fixed custom burnable blocks. Fixed modded overworld biomes not generating Fixed ClimberPathNavigator spinning when mob width is small Fixed SleepingTimeCheckEvent not being fired in initial sleep test Fixed biome generation error Fixed cats not having the AnimalTameEvent fired Fixed rail rotations Fixed errors being hidden by mods not being shutdown Fixed rendertickevent using wrong partial ticks when game is paused Fixed missing outdated notification in the main menu “mod” button Fixed debug world not generating modded blocks Fixed hoes and new 1.16 blocks not having proper harvest levels Fixed dry farmland being destroyed even with crops into it Fixed handling of the ModelRegistryEvent Fixed InvalidModFileException not saying which mod was invalid Fixed the client rejecting the server, because of missing tags. Fixed config iteration order Fixed logging issues with pack.png loading for mod datapacks Fixed DelegatingResourcePack performance Fixed LazyOptional not being clear which operations were actually lazy. Fixed the HighlightEntity Event not being fired Fixed minor bugs with bamboos, enchantments, and conduits Fixed RenderNameplateEvent not having partial ticks Fixed duplicate tag wrappers causing a crash Fixed custom teleporters crashing Fixed zip paths crashes. Fixed modloading crash reports with QOL tweaks Fixed crashed with tile entities with no collision boxes Fixed forge tooltip util. Fixed model to baked model inconsistencies. Fixed json biomes not setting a registry name correctly. Fixed forge GuiUtils not using MatrixStacks Fixed fluid filling sounds Fixed some inner biome fields not being accessible Fixed world rendering potentially causing a crash Fixed CommandEvent’s result not being used Fixed container items being consumed in brewing stands Fixed forge light pipeline causing block offsets twice Fixed ToggleableKeyBinding’s differences with vanilla Fixed issues with custom tag types and optional tags. Fixed some inner biome fields still being immutable. Fixed grass disappearing when forge config alwaysSetupTerrainOffThread was true

Mmmm it seems you did not folllow the advice of Draco18s, which i'll quote here: Your block extends the vanilla CraftingTableBlock class, but its not the vanilla crafting table itself (Blocks.CRAFTING_TABLE)...the vanilla crafting table container checks for the player proximity only with the Block.CRAFTING_TABLE, so of course your block doesn't satisfy the condition for the container to open. I think you would need to create a custom container which extends WorkbenchContainer and override the canInteractWith method to check for proximity with your own crafting table block. Then you have to tell your CraftingTable block to open your custom container instead of the vanilla one. You can see how vanilla opens the WorkbenchContainer by looking inside the CraftingTableBlock class. I don't know if this is the best way to achieve this though, there may be a better way

.orElse(new ModCapMethods() This won't assign the living entity a new instance of your capability. This means System.out.println(target.getCapability(ModCap.MOD_CAP).orElse(new ModCapMethods()).get()); If the capability does not exist on the entity, it prints the default value (of the new instance). By using orElseThrow you can get notified whenever you are accessing an entity that does not have the capability (which should not happen). At the moment it seems like the entities does not have your capability, is the capability correctly registered, and capability correctly attached?

I would take a look at how the Never Needed or Wanted (NNOW) mod handles new villagers, PoI blocks, and trades. The unique villager textures are based on the names when you register the profession (here), which points to the corresponding file in your textures/entity. The mod creator also made some nifty reference classes, VillagerUtil and RandomTradeBuilder, that reduces some repetitive code when making multiple villager types.

Haha, thanks vemerion

Ah, shame. Glad it brought you a laugh though! Also, back to OP's post, not sure how relevant it is, but any LivingEntity has two methods: isPartying and setPartying. It's what parrots use for jukebox detection. Hope it helps!

The DarkUtilities mod seems to be requiring two other mods, which are missing in your mod list: https://www.curseforge.com/minecraft/mc-mods/dark-utilities

First of all, ifPresent is just not the right choice here, as you can see by the ugly 1-element-array-hack you have to do. You most likely want orElseThrow. The error you see here is not caused by the GUI code at all. It is called by you sending a custom payload packet without registering the channel properly.

Correct, there are various methods that let you do that.

I think it's in the render method in EnderDragonRenderer. (where it does death checking EnderDragonEntity.deathTicks > 0)

A data generator is a way to automate creating json files via providers. Current versions of the mdk have a base build.gradle set up so you do not need to edit anything. Then, I would suggest reading through the docs with their information and build off of there.

Whoops, I did not think about that when I wrote my response :P. If I remember correctly, you can get the equipment that was previously equipped from the event as well. Try checking that the previously equipped item was your custom armor, and the newly equipped armor is not, and only then remove the effect.

And this is exactly something that capability system can solve...for example capabilities can be used to implement player thirst mechanics, mana levels etc...

These methods are registered on the wrong event bus.

That's because you set it to 0. Use getMotion to get the entity’s motion.

Use the ConditionalRecipe system. You can add a condition to make it determine whether to allow based on the config, recommended you use data generators for this as the recipes are easier to create using that, especially conditional ones. However, you will need to reload the recipe datapack if you plan to change the config value on the fly during runtime.

Do not split the registry objects and the DeferredRegister instance into different classes. This breaks how DeferredRegister works. Also, you almost certainly do not own n5.com. Do not use it as your package name.

Yes, from what I can see, the makeShapes() method always starts from the bottom (e.g. y = 0). However you could just override makeShapes() and tweak it to your desire.

I don't mean to sound rude, but I disagree with that. Many times when learning something new, I'd find some example code, or code that achieves a similar effect to what i need, I'd read through it, attempt to understand and learn from it, then maybe tweak it if needed. I'm sure I'm not the only one! I understand that not everybody does that, but if they are serious about learning whatever it is, then they would. That's just my opinion though.

This is what I have found after a bit of testing: * The first parameter decides the collision width of the middle pole * The second parameter decides the collision width of the extended parts * The third and fourth parameter does not affect the collision shape, but only the 'normal' shape (e.g. for hit collision) * The fifth parameter decides the collision height of the block

Only EntityDataManager solves your problem. The share tag is for handling how an ItemStack is sent to the client. onEntityItemUpdate is not relevant here at all, it is a callback so that an Item can react to itself being on the ground in entity form.

Try using Gradle's offline switch, ForgeGradle just queries to make sure things are correct and up to date

thank you so much, I think that will do exactly what I want

This typically means that you connected to a server without the mods installed. I'd advise 1) Using the vanilla launcher not technic. 2) Making sure you're running the server correctly by reading the log files on the server.

This would spawn a new entity for every player that joins. You need a WorldSavedData or a world capability. In there you store whether or not the entity has been spawned yet for that world (=dimension). If you want it once for the whole save file, across dimensions, always check the overworld.

https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html LazyOptional.of(() -> new TestCapability()) or use :: LazyOptional.of(TestCapability::new)

When you toss an item the itemstack is modified, and since you only pass a reference of the player itemstacks to your capability, those itemstacks will also shrink. Copy the stacks with .copy() in your detonate method when you save the itemstacks to create new identical itemstacks instead. However this also means that you can now duplicate items by saving, tossing items, and revert, since you will get your items back, and still have the old items on the ground. P.S. Interesting mod

Before you try anything else, always try without Optifine.

It should be item/generated.

This is a whole load of BS. Nobody (well, not nobody...) calls it ECMAscript. You write stuff in JavaScript. And JavaScript (or "ES6") is very much a programming language.

So your slots cover 0-44, player inventory is 45-71, and hotbar 72-80. Your transfer method override only checks if index is storage, move to storage, else try and merge to storage. So you don't have any logic to move into the player inventory.

Vanilla and forge does not create any. As for an open source mod that does, there are plenty. However, I have not looked into them enough to give my approval of their practices and code. For that reason, I do not want to give you any links in case I promote such bad practices or outdated methods.

This is for the old forge loading screen and no longer in use.

Try to run jarfix.

If you refresh the gradle dependencies, it should import the classes. It not would indicate that the build.gradle file is erroring or something when pulling the information itself is. What is the stacktrace when running the gradle?

Ah, I'm sorry. I'm quite tired and misread for some reason. So yes, you would need a packet setup. As the javadoc says, 'The server is not aware of when the client right clicks empty space with an empty hand, you will need to tell the server yourself.' However, I'm assuming this handles only the case when there is no item in the hand while the armor is on. You would also need to hook into RightClickItem to cover all use cases. However, that one is called on the server. So you can create a separate method to call the packet instance and the other event instance from.

I think you will need to register some essential attributes like health.. etc.

As a personal note whenever it comes to textures of anything, always try to use the smallest size possible to represent your entity (e.g. 64x32 is the smallest for most entities). You can then ship another resource pack with your mod that displays the high quality textures. This negates the issue of lag from older model cpus/gpus when loading your mod. As a side note, avoid using non-powers of two in your texture. It causes some fun math issues when scaling the texture. With a ratio of 1:1.1953125, making smaller textures might as well be difficult when mapped. In this case, the smallest texture I could make is a 153x128 texture.

That is not what an asset is. You need to call IResourceManager#getAllResourceLocations which will give you a list of ResourceLocations. You can then use IResourceManager#getResource to get the resources for those. Just note that if multiple resource packs have the same resource (e.g. if a resource pack overwrites a vanilla texture) you will get that path multiple times (if I am reading the code correctly, do some experiments).

So imagine it like this. Technically, with a packet to synchronize it to the client, the client doesn't know anything about a slot either. What it does is send the container, slot id, and item stack. The container holds the window id (which should be the same on both the client and server version). The slot id holds the current slot it's in (once again synchronized by the client and server each creating their own version). Finally all that's left is the item stack sent. Once it puts all three of these together, it compares the open container window id with the packet version. If equal, it gets the client slot and pushes the stack to it. Your implementation of this would be similar. Any time you detect a change in the slot, you will send a packet to the client with the container window id and the current fluid stack. If you have more than one fluid, you can handle it similarly to a slot by creating a list and grabbing it from that. If you only have one, you can create a public getter and push the value to yours. Once you get this working, I will review the other problems you have. It's best to solve one problem at a time.

Sounds like someone is only copying something from a tutorial video

This sounds like something that should be in the documentation.

Hi, I am trying to create a Mod which can show "Ghost-Items" in the world and cover them with a colored glowing effect. NOTICE: clientside only! Here you can see how the "Ghost-Items" are generated: ghostEntity = new EntityItem(mc.player.getEntityWorld(), 0, 70, 0, new ItemStack(Blocks.COBBLESTONE)); To render the Ghost-Items, I created a custom renderer which can render the Ghost-Item at a specific location in the world: (based on RenderEntityItem.class) public void doRender(EntityItem entity, double xPos, double yPos, double zPos, float entityYaw, float partialTicks) { ItemStack itemstack = entity.getItem(); // Noetig damit Item keine Defaulttextur bekommt bindEntityTexture(entity); GlStateManager.enableRescaleNormal(); GlStateManager.alphaFunc(516, 0.1F); GlStateManager.enableBlend(); RenderHelper.enableStandardItemLighting(); GlStateManager.tryBlendFuncSeparate(GlStateManager.SourceFactor.SRC_ALPHA, GlStateManager.DestFactor.ONE_MINUS_SRC_ALPHA, GlStateManager.SourceFactor.ONE, GlStateManager.DestFactor.ZERO); GlStateManager.pushMatrix(); IBakedModel ibakedmodel = itemRenderer.getItemModelWithOverrides(itemstack, entity.world, (EntityLivingBase) null); boolean forceGlowing = true; if (forceGlowing) { // FORCE ENTITY GLOWING GlStateManager.enableColorMaterial(); GlStateManager.enableOutlineMode(this.getTeamColor(entity)); } Minecraft mc = Minecraft.getMinecraft(); float playerX = (float) (mc.player.lastTickPosX + (mc.player.posX - mc.player.lastTickPosX) * partialTicks); float playerY = (float) (mc.player.lastTickPosY + (mc.player.posY - mc.player.lastTickPosY) * partialTicks); float playerZ = (float) (mc.player.lastTickPosZ + (mc.player.posZ - mc.player.lastTickPosZ) * partialTicks); float dx = (float) (xPos - playerX); float dy = (float) (yPos - playerY); float dz = (float) (zPos - playerZ); GlStateManager.translate(dx, dy, dz); // Groesse aendern! wenn auskommentiert, wird voller Block gerendert ibakedmodel.getItemCameraTransforms().applyTransform(ItemCameraTransforms.TransformType.GROUND); // Item Rendern itemRenderer.renderItem(itemstack, ibakedmodel); if (forceGlowing) { // FORCE ENTITY GLOWING GlStateManager.disableOutlineMode(); GlStateManager.disableColorMaterial(); } GlStateManager.popMatrix(); GlStateManager.disableRescaleNormal(); GlStateManager.disableBlend(); } To add the colored glowing effect, I created a custom team and added the Ghost-Item Scoreboard scoreboard = mc.player.getWorldScoreboard(); if(scoreboard != null){ if(scoreboard.getTeam("Test1") == null){ System.out.println("create Team"); scoreboard.createTeam("Test1"); scoreboard.getTeam("Test1").setColor(TextFormatting.GOLD); ghostEntity = new EntityItem(mc.player.getEntityWorld(), 0, 70, 0, new ItemStack(Blocks.COBBLESTONE)); ghostEntity.setGlowing(true); scoreboard.addPlayerToTeam(ghostEntity.getCachedUniqueIdString(), "Test1"); } } The problem is, that if the glowing effect is enabled, the whole Ghost-Item is rendered white. Picture 1: Ghost-Item at a specific location in the world without glowing effect: CLICK Picture 2: Ghost-Item at a specific location in the world with glowing effect: CLICK How can I fix this? The teamcolor is e.g GOLD. Thank you for your help.