Leaderboard

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

Try moving the line prevRotationYaw = rotationYaw; below the line setRotation(rotationYaw, rotationPitch); You could also try overriding getYaw() to simply return rotationYaw, since getYaw() is what is used to determine the viewport yaw.

The latest.log shows a vanilla server. The debug.log is from a forge server that did not start during an error with the Improved Wolves mod.

RegistryObject#get.

You are using outdated mappings, update your mappings or use the func_235861_h_() method (which has been mapped to setRequiresTool in more recent mappings) instead of setRequiresTool

Just set the duration to something high (like Integer.MAX_VALUE) to approximate an infinite duration. To solve your other problem, just add an else to the if statement you already have, and use player.removePotionEffect(). You would still have to reapply the effect if it gets removed due to for example milk, as ChampionAsh pointed out.

Capabilities.

You see this? https://github.com/LukasSchikirianski/JungleAddonsMod/blob/master/Jungle Addons - 1.16.1/src/main/java/com/lukas/jungle_addons/JungleAddons.java#L30 You see how it says bus=Bus.MOD? That's the wrong bus for those events.

1.7 is no longer supported on this forum. Please update to a modern version of Minecraft to receive support.

Show all your code, it seems like you have duplicated item/block id or something like that.

That's why I prepended this statement.

ah ok, yep, that clears it up. thanks!

Well, by "hit collision" I mean the shape used for detecting if the player is interacting with the block, (e.g. left or right clicking it etc). Hope that clears it up!

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

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

You could do the following: Map<Effect, EffectInstance> potionMap = entityLiving.getActivePotionMap(); if (potionMap.containsKey(Effects.EFFECT_NAME)) { // Do something }

"odds are, I was trying to be nice"

Well, have you tried looking around? Go on curseforge and search for mods that adds the things you want (you can filter your research to find mods that are biome related for example). If then they happen to be open source just go and take a look at the code. Quark, for example, is a good open source mod that implements lot of different things...Biomes o' Plenty and Traverse if you are interested in biomes..also you could find those rather simple mods helpful: https://wiki.minecraftabnormals.com/Main_Page

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.

That's exactly what I was looking for! Thank you!

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.

In addition, you could store the supplier in a Lazy. What they essentially do is use the supplier once to grab the item and then keep the first accessed result. This makes the result deterministic and unchangeable (which is pretty much what you're going for).

If you're using IDE RunConfigs, or running the Gradle tasks in two separate terminal instances, I think so

Try to run jarfix.

Look at how the slowness potion works. There is already a system in vanilla (attributes and attribute modifiers) that allows various things (armor, held item, potions, etc.) to collaboratively modify a value about entities (such as their movement speed) without overwriting each other.

Please Stop Writing Like This, English uses lower case usually. You have to store a flag on the player to remember if you have already given them the starter tools. You can use getPersistentData on the player for this, make sure to store your data in a sub-compound identified by your ModID, to avoid conflicts. If you need to store more complex data other than just a boolean, use capabilities instead.

This cannot apply to all living entities. You would probably need to use an event, either PlayerInteractEvent$EntityInteract or PlayerInteractEvent$EntityInteractSpecific, to handle the logic instead.

The basic idea is right, yes. There are some intricacies you need to take into consideration (such as crossing chunk borders and what happens at world load), etc. I have an implementation for ComputerCraft turtles here (though written in Kotlin). The basic idea is that it checks every tick if the position changed and if it did, it will compute which chunks to load (which is just the current chunk or also the next chunk over if it is at the edge of a chunk). Then it will check if the set of chunks to load has changed since the last tick and if so, unforce resp. force the new chunks. Then there is also a WorldSavedData, which keeps track of which chunks are loaded by which turtle and ensures the chunks are loaded again on world load.

Not being rude, that's more a result of poor animation rather than textures. If handled correctly, there should be no way to overlap the body. This is less related to Minecraft and more taking a texture, masking by color range, using some sort of neural algorithm to determine whether the pixels represent a line or not and then editing the values to achieve the effect you want.

You can't just create a new resource manager instance, it won't do anything. You need to use Minecraft's.

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).

Make sure the code is isolated only on the physical client. And yes, it does need a UUID to specify which player its coming from or Util#DUMMY_UUID if it's coming from no player.

What vemerion said will work because deferred registers need to be registered on the Mod bus...while with this code: IEventBus eventBus = MinecraftForge.EVENT_BUS; EntityInit.ENTITY_TYPES.register(eventBus); you are registering your deferred register to the Forge event bus, which is where in-game events are posted. Registry events (for items, blocks, entities etc....) happen during the loading of the game and are posted on the mod bus (which is different from the forge bus), which can be retrieved with: FMLJavaModLoadingContext.get().getModEventBus()

Try changing the BlueMagic() method like so: public BlueMagic() { EntityInit.ENTITY_TYPES.register(FMLJavaModLoadingContext.get().getModEventBus()); }

You can get the current client player using Minecraft#player. You can get their position using getPositionVec and their name from getName. To draw things on the HUD use RenderGameOverlayEvent.

In your mods.toml file you have an issue with your mod requiring itself as a dependency...this won't work

I give up... Please learn Java.

The MelonMod needs to be updated. Check for a new version, or talk to the author.

So the method is called on the server-side only. Then you must pass null as the player for it to play it to all players in range.

Update Regarding LTS System: Please read The Big Forge Update Earlier this year, 1.13 was announced and the snapshots started coming out, the update was relatively small, but enough to be a hurdle for mod developers. This combined with 1.12 stabilizing, and a few fundamental Java changes that broke modding in general, made the Forge team decide to use this opportunity and work on cleaning the years of technical debt that Forge had accrued. During this time, it was discovered that a lot of things needed updating. In fact, well, everything did. And so, it was done, a full rewrite of practically everything Forge related. This took a long time, longer than originally anticipated. But what’s the outcome of this you might ask? A lot. cpw’s mod launching system (ModLauncher) allows for parallel mod loading and support for more modern Java versions. (Considering the original was written to target Java 6). The Forge installer now runs tasks at install time once, rather than doing it every time you run the game. These alone provide dramatic reduction in launch times. ForgeGradle, the “devkit” for creating mods, has been rewritten and is faster at, well, everything. It also integrates much better with IDEs. What does that mean, you ask? Simple. Mods are nicer to make. (Also 100% less setupDecompWorkspace.) MCPConfig allows for much easier MCP updates, and is public source too, so people can see exactly what's going on between updates. In short: There was a lot of work to do. And now that it's done, future updates will be much, much smoother. 1.14 and 1.15 The 1.14 release came around, just in time for the rewrite to be finished, so it was time to get the ball rolling again. The bulk of the restructure work was done through 1.13's life, so all that remained was actually seeing how it was to update all of it, and it went pretty well. A lot of improved systems exist now that make developing for these modern versions far easier and just better in general. The 1.15 release was relatively simple, even if Mojang decided to restructure everything and make changes to how the rendering works. (Taking some of our systems in the process, don't worry, this is a good thing.) 1.15's rendering changes were mostly a refactor, and we expect 1.16 to be a large update to rendering. This plus 1.14 seeing growth is why we chose 1.14 to be a candidate for LTS. (More on that further down.) Hopefully this kind of restructure from them is a rare thing in the future, but we welcome the change, since it often brings improvement. Although the rendering changes may pose a tough hurdle for some, the update for most should be relatively straight-forward. Forge support and LTS 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. We will now also deem a previous major Minecraft version as "LTS" (Long Term Support). The LTS version will receive support for modders and players alike, however all new features must target the latest version first, and then may be backported. 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. Late last year (Happy 2020!) a vote was held privately with many developers of various Minecraft projects to determine which version will be LTS: Should 1.12 remain LTS or should 1.14? A vast majority chose 1.14, and so, from now on we are dropping 1.12 from support, and 1.14 is now LTS. What does this mean? 1.15 is latest. It will get full support. 1.14 is LTS. It will also get support, and new features, but new features must be made for 1.15 first. 1.12 is no longer supported on this forum, no new features, and no more bugfixes. All other versions are not supported. This means if you come to us for help with those, we will ask you to update. This includes crashes/bugs. To keep with Mojang's history of releases, we expect 1.14 to stay LTS for 12-18 months, giving plenty of time for modders and pack developers alike. However, this may change depending on what surprises Mojang has in store for us. Finally… Thank you. Thank you to all the modders/developers, all the players, and especially to all the contributors. The Minecraft modding community would not be what it is without you. You are responsible for the striving ecosystem we have today. We hope this new year brings you all you desire, and we look forward to seeing what you create. And now time for some shameless plugging, if you like Forge, please consider supporting us. http://www.patreon.com/lexmanos - The Forge Team.

No. Stop. writeToNbt and readFromNbt are for saving to disk. Server-side. If you want to sync stuff to the client (assuming you want to use the vanilla mechanic, which uses NBT), you need to override a couple of methods (warning, this is a giant mess): getUpdateTag - Returns the data that should be sent to the client on initial chunk load (i.e. when it gets into render distance, etc.). Call super here and put whatever data you need to have available on the client in the NBTTagCompound returned from super. Then return it. handleUpdateTag - Called on the client with whatever tag was returned from getUpdateTag. By default this calls readFromNbt, which is a terrible default, but oh well. getUpdatePacket - Called to produce a subsequent update packet. You should return a SPacketUpdateTileEntity here if you need the data on the client to be updated from time to time. In theory you can return a partial update here, but usually it is best to just call getUpdateTag and pass that NBTTagCompound to the packet. The int parameter of the packet constructor can be set to whatever unsigned byte you like best. onDataPacket - Called on the client when the packet produced by getUpdatePacket is received. Usually you just need to call handleUpdateTag with the NBT data from the packet (SPacketUpdateTileEntity::getNbtCompound). getUpdateTag will always be called and it's data sent when the chunk is initially transferred to the client. You cannot stop this. If you need to update the client-side data later (i.e. you need the packet produced by getUpdatePacket to be sent), call World::notifyBlockUpdate on the server. You should care about when you call markDirty. You should not care when writeToNbt and readFromNbt are called. Remember, these are for saving the world to disk. Minecraft will do that when it sees fit. You need to call markDirty after doing the changes (so Minecraft knows to save to disk) and then call notifyBlockUpdate to notify the client of these changes (assuming you are using the syncing mechanism described above). Both happens server-side. That was in the context of "NBT is only used for saving to disk". ItemStacks have the terrible habit of using NBT for runtime storage, which is ugly, cumbersome and inefficient.

Create a custom Inventory that does then.

You should look into DynamicTexture (and MapItemRenderer) which is rendering the Map data into a texture (the data is not even a real image, it's generated on the fly).

NINJA EDIT I figured it all out. The solution is to create a custom slot (non vanilla slot) and specify it in the class to only allow said items example the slot inside container class

Common Problems and Solutions: java.lang.UnsupportedClassVersionError: ******** : Unsupported major.minor version 51.0 or 52.0 - Use Java 8. Not 7 or even 6. java.lang.ClassCastException: java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to java.base/java.net.URLClassLoader - Use Java 8. java.lang.OutOfMemoryError: PermGen space: Update to Java 8 or increase your PermGen Space with the following command line argument: -XX:MaxPermSize=256m. java.lang.NullPointerException with com.pclewis.mcpatcher.mod.something: For the love of god, don't use MCPatcher. Use OptiFine instead. If you can't run the installer and are on Windows, try Jarfix first. Download it, and run it. If you're using the .exe ones, DISABLE YOUR 3RDPARTY ANTIVIRUS and try running the installer again. It is highly recommended you run any modded versions in separate folders using the GameDirectory setting in the vanilla launcher. This will store all your save files, configs, mods, etc. in whatever folder you specify (instead of just .minecraft) so they do not interfere with your vanilla installation (or other modded versions you may have installed) and vice versa. To set it, click "Edit Profile" in your launcher and in the settings screen that pops up, modify the "Game Directory" setting (Screenshot). If you are using an Intel GPU and Minecraft freezes during loading, disable the loading screen by setting "enabled" to "false" in .minecraft/config/splash.properties. This version of FML is built for Minecraft a.b.c, we have detected Minecraft x.y.z in your minecraft jar file: Do as it says and get the FML/Forge versions for x.y.z. "You need to run the version X manually once." This means that you have to run VANILLA minecraft (no mods) for the version listed before you can install Forge. These libraries failed to download. Try again. org.scala-lang:scala-library:2.10.2, org.scala-lang:scala-compiler:2.10.2 Download this: https://bitbucket.org/luacs1998/forgelibrarydownloads/downloads/fmllibs16.zip and extract it to your .minecraft folder, then try running Minecraft, or redownload the installer. Otherwise, we will need console logs, and your JVM and OS versions. java.lang.NoClassDefFoundException: net/minecraft/client/something : One of your mods is client only and you're on a dedicated server. Check which ones, and remove them. io.netty.channel.ChannelException: failed to open a new selector: Update to version 10.13.0.1180 or above. Previous versions: Add -Djava.net.preferIPv4Stack=true to your VM args. java.lang.ConcurrentModificationException or java.util.ConcurrentModificationException before Minecraft loads: Update forge. java.lang.IndexOutOfBoundsException at java.nio.Buffer.checkIndex at java.nio.DirectIntBufferU.get at net.minecraft.client.renderer.RenderGlobal... - Lower your view distance. java.net.SocketException or blank dirt screen when connecting to a server: Ensure the client and server configs match. If your text is distorted like seen below (or you have been instructed to do so), disable the loading screen by setting "enabled" to "false" in .minecraft/config/splash.properties. If your main menu background is compressed to a corner, and the rest of the menu is black/white: Update your Forge to at least 10.13.1.1226 or add -Dforge.forceNoStencil=true to the VM arguments in the launcher. If MagicLauncher tells you there are errors in forge: