Leaderboard

While you can do that, there is a much simpler way to just get the block position "below": BlockPos#down(). There are many more helper methods like this on the BlockPos class which make your code more understandable.

1.15 has been more challenging then previously expected. Instead of just being adding bees, and fixing bugs as reported by Mojang. They decided to take this release to re-write most of the rendering engine. Unfortunately, they also took the rendering guy from the Forge team. And my weakest point has always been, you guessed it, rendering. So it's being quite difficult to sort through all the changes, and update our massive changes to reflect the new stuff. gigaherz, tterrag, and unneon are trying to get up to speed and sort through all the rendering changes. So far, we've processed 512 out of the 520 patch files Forge does. As well as brought the compile errors down from >1400, to 161. So, progress is being made. Unfortunately, not publicly as before we get it compiling the repo we're working in contains the full MC decompiled codebase. And we do not have legal authority to redistribute that, so we're working on it privately. Hopefully, we'll have a build working and published here shortly, we're hoping that it won't be as broken as it could be. We'll keep you informed when there is something to inform. As for the mapping data, we've already answered this, Mojang's release under the license you quoted does NOTHING to help us and only helps those who do not respect their license {Hacks/pirate clients/malware}. We are STILL holding out hope that Mojang's lawyers will come back with a new license that actually allows us to use this data.

Also, what on earth is this habit I see so many times on this forum... "I saw an error in the console / I got an error / it didn't compile so I changed something completely unrelated and now I get a different error, please help me fix that one!" At the same time then not mentioning they ever got that first error. THIS IS A BAD IDEA.

Industrial Foregoing seems to require Titanium. Please tell the mod authors to fix their sh** and provide proper metadata so that Forge can display usable error messages and also tell them to fix their installation instructions.

I had been using Eclipse for too long before I switched to IntelliJ this year, and I absolutely love IntelliJ. It has a neater environment, offers more tools, and generally speaking, is more professional. However I do miss something from Eclipse. While on debug mode, you could just edit the classes, save them, and the changes would pop right into the game. A very nice tool to have, especially when working with models and such because you can see what's going on right away without needing to restart the game every time you make a change. IntelliJ kind of has the same thing too and they call it HotSwap, but it feels a little sluggish compared to Eclipse. I have to do the process manually by hitting the "Reload Changed Classes" and it actually takes longer to update the game. Also, sometimes it doesn't even change anything in-game and that's where it gets a little annoying, especially for me right now that I am working on a model. I had to refresh the game everytime I made an adjustment because HotSwap couldn't update it while on debug mode and I wasted an hour trying to get everything to look right. Is there a way to make the IntelliJ debugger work like the Eclipse debugger? It would really help out to save some time.

Something seems wrong, why is there I think NBTTagCompound has changed to CompoundNBT and the import for that is: import net.minecraft.nbt.CompoundNBT;

Remove this and put this in the constructor super "new UnicornModel<>(0)". The model file has to extend HorseModel Or you will not get the animations. In the renderer Create: And return "unicorn" in getEntityTexture. ");

When you create a dimension, you have to pass a DimensionType to DimensionManager.registerDimension() Why not...hold onto it? If you have access to the world, you can also query that world for its dimension information, which includes the DimensionType.

I would recommend creating a custom ItemEntity for your custom item, and return an instance of your ItemEntity in Item#createEntity (as well as override Item#hasCustomEntity to return true). With this approach you can simply check for water in your EntityItem’s update method.

You can subscribe to ItemTossEvent and keep track of relevant items, then check to see if your conditions are met within one of the TickEvents. Keep in mind that there's no guarantee that the items remain in the world once thrown, so your list of items should update to remove those that should no longer exist. Yes. Within the inventory, items are ItemStack objects, while on the ground they're EntityItem objects. You can get the ItemStack represented by an EntityItem through EntityItem#getItem().

No. Your client code is sending information to make the server do things. Your server code is telling the server to do those same things (again).

Also i fixed the problem, It was nothing to do with setItemStackToSlot it was because i needed to add in renderbarbarian { this.addLayer(new LayerBipedArmor(this)); this.addLayer(new LayerHeldItem(this)); } so turns out it wasn't anything to do with itemstack just like when i made the most and said if there's any render method but yeah, thanks for the help anyways. Also your ModelClass for your mob needs to extend ModelBiped if you want it to work!.

The mods tell you that they need at least Forge version 2779 or 2772 respectively. You have 2768 (which is lower than both of them). 1.12.2 is the Minecraft version.

You can learn about how to sync tile entity data in this post. Note that inventories that you want to show in a GuiContainer do not need to be synchronized separately, the Container infrastructure handles that.

Correct, however DistExecutor is even more of a hack than @SidedProxy and often fails.

Items are not proxies. Proxies are proxies, Items are Items. The Item is supposed to call a method in the proxy, it is not the proxy itself.

I did not say at any point that your model should extend model entity. This requires three classes. Your entity class should extend HorseEntity giving you access to all of the GUI, saddling and taming. Your render class should be adjusted to not be using the superfluous classy created, as I previously mentioned. Your model class needs to extend HorseModel – this is how you will inherit the animations and bulk of the model. Note that AbstractHorseEntity does not have all of the code for horses, only the shared code between the various horse entities.

ModelUnicorn should extend ModelHorse. Everything else you want will come from your UnicornEntity class extending EntityHorse.

And all of those examples are terrible. Because all three of those things are main mod class tasks. Check out this and this instead. Or even better, this. Yes. That's how proxies work.

Your registerBlocks method is never called, because it is static and it's containing class (TomasusToolkitmain) is not registered to the event bus. Therefor BlockList.lapiz_gem_block is null when TomasusToolkitmain.RegistryEvents.registerItems is called.

The UnicornEntityModel class is unnecessary. Replace UnicornEntityModel in the first line of the render class with ModelUnicorn<UnicornEntity>. Switch LivingRenderer for MobRenderer. In your model class replace AbstractHorseEntity with LivingEntity.

Agreed, Tabula and other utilities make it so much easier to position and tweak things on the fly. Trial and erroring semi-abstract numbers is a massive waste of time. However, there's a useful feature many are unaware of that most IDEs can use to alleviate similar issues: hotswapping. I don't know how to do it on Eclipse, but on IDEA you can simply launch the game in debug mode, change some code, then just hit the build button to hotswap the changed code into the running game. It can't do everything (e.g. adding/removing methods requires a full restart), but changing rendering code inside a method is an ideal use case for this feature. But with that said, I sadly don't think hotswapping will work for adding/changing model boxes since those are usually defined in the model's constructor. Workarounds are possible (does anyone know if F3 + T also reloads entity models?), but Tabula/Blockbench is still the way to go to get fast results.

Here's one: placing the box and texture blind directly into code and only being able to see what it looks like by loading up the game each time is a pain in the ass.

You need to show your code. CANNOT help if you dont. Show your UnicornEntityModel class first.

Just read the names of the parameters. The first three are the center position of the box, then size of the box, then the scale. Read some of the vanilla code to see some real usages.

Oh god please, whatever you do, don't do this.

There is literally zero reasons for you to be using Tabula or BlockBench to add a horn to a horse. You already have Horsemodel. You already have a texture file for a horse that you can add texture to make the horn. I have a feeling that you are just lost. You should then add a box like I said before to your model class. this.corn.addBox(.....); Then right here is the coordinates of the texture on the png. this.corn = new RendererModel(this, number, number); The 2 numbers tell exactly where the texture is located on png.

download tabula (1.12). import horse model. save as project. download tabula plugin for BlockBench. import horsemodel edit as you please export as java class

On your end, join "localhost" on your friend's end put in your Hamachi IP address

The actual error is above, in yellow. Did you read my response?!

No. If you want to run the installer from the command line (for which there is no reason, you can just double-click it), you would need to specify the full name to the installer, including the .jar extension.

Item.Properties#group.

Do not create items in a static initializer.

You cannot call Minecraft methods from a separate thread. You need to wait a tick using ClientTickEvent.

Then you must first let the GUI open (GuiOpenEvent fires before its open!) and then call:

The only way to make data persist is to write to to some form of file. Whether you do it explicitly, or implicitly. You cannot persist data by wishing really hard.

Okay, I misunderstood your question then. What is this "particular element"? onBlockActivated in your block gets the BlockRayTraceResult, this can tell you the face of the block being hit (getFace) and also the hit vector (getHitVec). Is this not enough?

You should add box for your entities "corn". Render it in then just copyModelAngles of the head. See vahnilla code for how it copys headwear to head.

This event does not fire on 1.14 https://github.com/MinecraftForge/MinecraftForge/pull/6267

Java 11 can't be supported without dropping support for Java 8 due to a library Forge uses, and Java 8 support can't be dropped because it's the version Mojang targets and ships Minecraft with.

It will cause the server to crash, as such class does not exist on the server side.

Checking if the world is remote before doing client side things does not stop the server from crashing because the JVM does not know what that check cannot return true. In fact, it will crash before ever getting to this line. It crashes when the class is first loaded because it has to check to make sure it knows where all of the classes it loads the JVM knows where to find them. And it goes "Minecraft, Minecraft, OH GOD HELP ME JESUS, I CAN'T FIND THIS CLASS!" and dies.

So, it was brought to my attention that the way that I am teleporting the player using commands seems to cause some rather bad happenings on the server. When I first tried it, after they found the issue, I tried to teleport from the overworld to the end. When I did it had me suspended in what looked like the end, but nothing was loaded, no blocks could be seen, I couldn't move, nothing. Eventually my client disconnected, and then when I tried to log back in the server crashed saying that the server took a 60 seconds for a single tick. The way that I am attempting to teleport the player is just like how they do it in minecrafts code (pulled from the end portal block code) entityIn.changeDimension(worldIn.dimension.getType() == DimensionType.THE_END ? DimensionType.OVERWORLD : DimensionType.THE_END); What I am doing is this: public static void teleport(ServerPlayerEntity player, Location loc) { PlayerData data = Main.database.get(player.getUniqueID()); data.prevLoc = getPlayerLocation(player); BlockPos pos = loc.getBlockPos(); if(!player.dimension.equals(loc.getDim())) { if(Main.isDev()) { player.changeDimension(loc.getDim()); }else { TextUtils.err(player.getCommandSource(), "The ability to teleport between dimensions has been disabled until it can be fixed."); return; } } player.setPositionAndUpdate((double)pos.getX() + 0.5D, (double)pos.getY(), (double)pos.getZ() + 0.5D); } I feel like something I am doing must be the issue, it is normally the reason, but I was fairly certain that this would work.

Really... okay. I thought since it was related.....

Just followed these steps and made a new mob, it renders and behaves corruptly AI-wise, however it cannot be hit for some reason. Anyway I try to attack it, the mob is simply unfazed. Please help. SOLVED.

Since this is 1.14 you just do Item.Properties#setContainerItem

The registry system has been overhauled in 1.12, you need to use registry events. Forge's documentation explains them here. You can see some examples in my mod's init classes. Unlocalised names should not be used for anything except display/translation purposes, use the Item's registry name (IForgeRegistryEntry#getRegistryName) as the default model location (since it's the default model that vanilla loads for every Item). Use ModelLoader.setCustomModelResourceLocation/setCustomMeshDefinition rather than ItemModelMesher#register to register Item models. Do this in ModelRegistryEvent. The tutorial you followed is outdated and poorly written. None of this is new to 1.12; ModelLoader was introduced in 1.8, registry names were introduced in 1.8.9, IForgeRegistryEntry was introduced in 1.9, registry events were introduced towards the end of 1.10.2.

Can you? Absolutely. Should you? Avoid ASM like the plague. Better yet, avoid the plague like ASM.

You installed a bad version of chicken chunks.