Leaderboard

Also I recommend charging your battery

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

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.

Sorry it wasn't diesieben07, it was ChampionAsh5357. This, you do this:

Your message is coming from your mod, from no where, you don't need a website to find a player's UUID, you either get the UUID from an entity itself or don't need a real UUID at all, in which case you need a dummy UUID, which diesieben07 already told you how to get.

Yes, method signatures have changed. Because Mojang changed them. Or they got a new MCP name because the old one was inaccurate or didn't meet naming practices. UUID, a universally unique identifier. Every player (every entity) has one. Chat messages typically originate from somewhere and that's what the UUID is for: to tell the client who sent the message. If you don't have a sender (hint, you--the developer--don't) then you need to use a dummy ID.

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.

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

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

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()); }

Its not.

No problem, glad I could help!

The following is a tutorial for Intellij by an accomplished mod developer. The tutorial is 2 years old, but the workflow should still be relevant

Your code prints both "Hey" and "Hey 2" because after you print "Hey", count is increased and also the second statement is true. For what you want to do you can try with something like this: private String[] array = {"Hey", "Hey 2"}; private int count = 0; @Override public ActionResult<ItemStack> onItemRightClick(World worldIn, PlayerEntity playerIn, Hand handIn) { if (!worldIn.isRemote()) { playerIn.sendMessage(new StringTextComponent(array[count])); count++; return new ActionResult<>(ActionResultType.SUCCESS, playerIn.getHeldItem(handIn)); } return new ActionResult<>(ActionResultType.SUCCESS, playerIn.getHeldItem(handIn)); } If you want to make it loop between the Strings you can use an if statement to reset count.

You need to register the DISPLAYTEST extension point (ModLoadingContext#registerExtensionPoint). If that returns FMLNetworkConstants.IGNORESERVERONLY as the version, it is ignored by the client.

Well, i already told you but i try to explain better. The image you were trying to render on the screen has dimension 256x256, but with this line: minecraft.ingameGUI.blit(posX, posY, 0, 0, 32, 32); you cut only a 32x32 portion from the original image, starting from the upper left corner (x: 0, y: 0), and as a result you only render on the screen that little portion of the image.

Well, actually there is nothing wrong with your code, in the sense that it does exactly what you told it to do...and so it just draws a 32x32 portion of the icons texture at screen position 16-16. But it seems you actually need to render only text right? So you need to use the FontRenderer, and possibly it's drawString method

You can edit the title. Just note that if you have the client control something like this you need to be careful to avoid exploits. In your case I would only send "player scrolled X amount", not e.g. "move stack A from A to B".

Shouldn't it be CountRangeConfig? But i see from your previous post that you are using 1.16.3...world generation stuff changed a lot after 1.16.1 and forge is still fleshing out a new system to handle it. If you need world generation related stuff in your mod i suggest you stick to 1.16.1 at the moment

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.

Post the debug.log.

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

LARGE_CRYSTAL.get() to get the block from the registry object.

You could perhaps do a raytrace, with World::rayTraceBlocks().

I give up... Please learn Java.

Jesus fucking christ.

"Please do your research before posting here." is rude. The OP's question in itself is an act of research. "Please do your research before posting here" is not a fact. It's an imperative. The OP comes here asking for help and he is being told to "do your research." Get over yourselves. If you don't want to be helpful then what are you doing here besides berating people? Or is this forum only for the "elite"?

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.

Old versions of forge are available at sourceforge: https://sourceforge.net/projects/minecraftforge/files/ I think 1.0.0-1.0.6 are for beta 1.7.3

Don't tell ppl "do your research before posting here" as the README.txt file that comes with the MDK of Forge 1.13.2 25.0.9 and 25.0.10 says to use setupDecomWorkspace its obvious that the README.txt file was not updated but you don't have to be a dick.

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.

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:

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

I don't know if this is a Forge issue or something that needs to be updated mod side. If you have a mod that uses the Forge javascript asm, and one that uses Mixin to change methods in the same class, prior to 33.0.40 the two could coexist but afterwards Mixin crashes. Up to 33.0.34; works 33.0.35; Crashed: ClassCastException (this looks to be unrelated) 33.0.36 and 33.0.37; works 33.0.40; Crashed: MixinInitialisationError 33.0.41 and up; Crashed: ReEntrantTransformerError: Re-entrance error org.spongepowered.asm.mixin.transformer.throwables.ReEntrantTransformerError: Re-entrance error. at org.spongepowered.asm.mixin.transformer.MixinProcessor.applyMixins(MixinProcessor.java:278) at org.spongepowered.asm.mixin.transformer.MixinTransformer.transformClass(MixinTransformer.java:206) at org.spongepowered.asm.mixin.transformer.MixinTransformationHandler.processClass(MixinTransformationHandler.java:109) at org.spongepowered.asm.launch.MixinLaunchPlugin.processClass(MixinLaunchPlugin.java:135) at cpw.mods.modlauncher.serviceapi.ILaunchPluginService.processClassWithFlags(ILaunchPluginService.java:154) at cpw.mods.modlauncher.LaunchPluginHandler.offerClassNodeToPlugins(LaunchPluginHandler.java:85) at cpw.mods.modlauncher.ClassTransformer.transform(ClassTransformer.java:119) Mod using JavaScript: https://www.curseforge.com/minecraft/mc-mods/shetiphiancore/files/3054955 Mod using Mixin: https://www.curseforge.com/minecraft/mc-mods/botania/files/3049237 - Dependencies: -- https://www.curseforge.com/minecraft/mc-mods/patchouli/files/3037298 -- https://www.curseforge.com/minecraft/mc-mods/curios/files/3042479