Matryoshika

You'd be better off creating a method in your proxies, that spawn a custom particle on the Client with Minecraft::addEffect() (as such, the CommonProxy's method would do nothing)

Use the entity's getNavigator().tryMoveToXYZ() method.

First and foremost: Making vanilla tools/items (also) use this logic, whilst not impossible, is much harder compared to using (only )your own items. I would recommend that you make use of Capabilities for this, like coolAlias suggests as well. In this capability, you would store XP, name and level. You'd be better off incrementing the XP when the tool lose durability (for vanilla/others items, you'd need a tick-counter and manually check every so often, and add XP as needed), instead of going after the LivingDeathEvent (as that fires when an EntityLiving dies (or equivalent of))

FML started the lowercase enforcement in 1.11, but has been strongly advising it since 1.7 at least. And it benefits everyone on Windows. (Or any non-Unix based systems, rather) While in the development environment (IDE), "FileOne.png" and "fileone.png" could point to the same file. However, when you create your JAR (which is really just a ZIP file with different name) the OS cannot find "FileOne.png" any longer, if it was called "fileone.png", or "FiLeOnE.png" or whatever you called it, because of the structure of the mentioned compressed system. As such, it would work inside your IDE, but not when you pack your mod. Countless of modders have had this issue, and reported this "bug". And it is in no way "outrageous". Naming conventions, even for simple file IO's, makes it so much easier to organize your own files, and work with other's projects.

Well, looking up what BiomeGenBase#getBiomeGenArray did, it returns an array of all biomes, indexed by biome id. I believe there is a simpler way of doing it, but cannot remember what it was, but in any case, you should be able to iterate over the REGISTRY field in the Biome class or, simpler, just call Biome#getBiomeForId, from 0 through 255 (max value in the underlying IntIdentityHashBiMap) and add each non-null biomes to your own array.

1) Server cannot have client-side mods 2) For future reference, 1.7.10 is obsolete, and Forge is no longer supporting it.

One can do this without the need of TESR's, by using a HUD (Heads Up display), and RayTracing. Create an EventHandler for the RenderGameOverlayEvent or RenderWorldLastEvent. The BlockPos can be gained from Minecraft::objectMouseOver. The player is always Minecraft::thePlayer, client-side. If the block/tile you are looking at is what you want, call a new method, from hereof called HUDBlock, passing the Minecraft instance. HUDBlock should of course extend GUI. In here, you can use GL however you want. Bind & render an image, draw strings on the screen etc.

Subscribe to GuiScreenEvent.PotionShiftEvent and cancel it. Voila.

There is a HashMap containing all FakePlayers located in the FakePlayerFactory class. Do note that it is private, so you will need to use Reflection to see it.

RenderGameOverlayEvent.Post should be suitable for most needs.

You'll have to learn OpenGL. What you seem to want, is called a HUD. (Heads Up Display). I have a very old example here. It is from the 1.7 days, but it should be mostly correct still. ScaledResolution only needs the mc instance now, the width & height is done for you. Do note, this involves Minecraft#getMinecraft() which is client-side only. As such, it must only be called client-side, as it will crash otherwise. (The example I linked, is meant to print the given string in the middle of the screen, fully centered) As Lhykos has states, you will need a timer. How you create that, is up to you.

Well, of course. If you kill the entity, you destroy the itemstack, Pretty hard to appear in one's hand if it does not exist. I also believe that the PlayerRespawnEvent happens before the player has respawned, as a signal that it is about to respawn. Try and switch it out for the Clone event instead. This is where everything gets transferred from the old entity to the new one. (getOriginal = old body, getEntityPlayer = new body)

Are you planning to use a custom block? If so, you only need to check if the multiblock is formed, when the block is placed, and check if the multiblock is no longer formed, when the block is broken.(thus, block placed = check if formed, block broken = check if malformed) As you state rectangular prism, I'm gonna guess and say that this is a solid body we are talking about? Have your custom blocks check for this one thing: How many neighbours (same blocktype) do I have? (you can put this in under random tick update) If a block finds that it has 3 neighbours, it can either mean that it is a corner block, or is placed in a yet-fully-finished body. Have the blocks with 3 neighbours (from now called corner blocks) convey their location to the "controller" you state you will use. If there are 8 corner blocks, and they all connect to 3 others along each axis, you have a rectangular cuboid. Now, either manually check if each block on the inside is there, or have the blocks on the inside convey their neighbour count to the "controller" (inside blocks should always have 6 neighbours, whilst edge blocks have 5)

Possible, yes. Exists already, and is ready for use, no. You'll need to create your own implementation of IRecipe, that can handle a world (or IBlockAccess as it boils down to) as a variable for the recipe. To go along with that, you will very likely need to create your own Crafting table etc, or substitute the normal Crafting Table's container for your new one, that can do these world-specific recipes, and all the normal ones as well.

No, stay with FolderResourcePack. It implements IResourcePack, which is what the list contains. Create a List<IResourcePack>, in a method in your client proxy (name the method registerResourcepack or whatever) and initialize it to null. I recommend you try either FieldUtils from Apache Commons Lang3 (already packed with Forge) or ReflectionHelper, which originates from Forge directly, and I've heard it is the best alternative with all of the obfuscation/deobfuscation/obfuscation happening. The two things I just mentioned are great tools to help you get fields (and more) that are private, or final, or really, "untouchable". Reflections really just "unlocks" the wanted thing, if it exists, though it is more demanding on resources compared to just getting a normal field.

Huh, that's odd... I was doing it during the RegistryEvent.Register<Block> event. Shouldn't that still work then, as it's been added before preInit? As your statement infers that Minecraft::refreshResources is called at the end/after preInit.

In 1.10 at least, Minecraft::defaultResourcePacks is private, last I checked, so he'll need to use Reflection to get it, add his own IResourcePack instance (the FolderResourcePack) and then, most importantly, refresh the resources with Minecraft::refreshResources. I'm doing it prior to block initialization, but could be done just prior to model initialization.

I believe this event that you are basing this on, fires once for each side (Server, Client) & once for each hand (Left, Right) the player has. As such, there are a maximum of 4 different outcomes (Server, Left)...(Client, Right) that can happen.

TheGreyGhost has an MBE tutorial project (Minecraft By Example) for this specific mechanic, however, it is for 1.10.2, so you may need to improvise a bit yourself. The tutorial can be found here: MBE04 | Dynamic Block Model

To view Forge/MInecraft classes, in Eclipse, either hover over any object, hold ctrl and left-click to open the associated class, to view it's code, OR you can press ctrl + shift + t, to search for classes. You can also highlight a method/field (mark it, as if you want to copy it) and press ctrl + shift + g, to find all the places where that method or field is called from. I believe we're having a small issue with communications. A) Can you debug it in Eclipse? Can you "play/test" your changes in Minecraft, from inside Eclipse? (What happens if you try to press F11 & shift+F11?) B) Or do you want to build your JAR, as in, create the final file where all of this code will reside, and have it ready for anyone to download and use with MInecraft?

Multiverse-Core is a Bukkit plugin. Last update was March 9, 2016. It would seem that you mean that Forge mods do not generate terrain/ores/scattered features, but as this is caused by Multiverse-core, it's on their end to fix, as you yourself infer that they work normally without this plugin. TL;DR Wrong forum, wrong people, wrong time.

To fix the Launch Configurations, click on Debug/Run configurations (Arrow next to debug/run) -> Main -> Project -> browse, and select the project you want this to run. You want to update your code? Update Forge, not "Minecraft". To do so, update your build.gradle file, and change version = "MCversion-xx.yy.z.nnnn" to the version you want. Forge versions can be found here: http://files.minecraftforge.net/ I also recommend that you read this through http://www.minecraftforge.net/forum/index.php?topic=14048.0

That method, will only work client-side, as you are using client-side only classes ( Minecraft::getRenderViewEntity etc) What you can do, is; get a list of all entities around the player, using World#getEntitiesWithinAABB Create the "cone" or rather, triangle, by assigning 2 points away from the player, at equal distance from the player#getLookVec Go over each entity in the list we got earlier, and calculate whether their position is inside the triangle, using Barycentric Coordinates

Hi. Another linux user here (Kubuntu) Did you ever run ./gradlew eclipse, after setupDecompWorkspace? Never had this issue setting up any projects (12 so far). Should just need those 2 lines, issued from the main folder where you un-zipped the mdk

You will probably want to look at Forge's MultiLayerModels. Some information, and examples, can be read here: WillieWillus : Forge Rendering Primer Scroll down to where he talks about Aura Cascade’s Fortified Blocks. Heavily recommend that you read the whole primer. It's good material to learn the system that has been used since 1.8 to render. Edit: seems the link in the primer to Aura Cascade's multi-layer example returns a 404; so here's a direct link