Leaderboard

Don't have empty variants. It isn't supposed to be empty anyway - if the X axis is the default one and the Z is rotated by 90 degrees on the Y axis then the Y variant should be rotated by 90 degrees on either X or Z axis. Here is my example of using a blockstate with rotation. This actually means that your block doesn't have the rotation property at all, since if it had a property that wasn't specified in it's blockstate file it would have a missing model since it's blockstate file is invalid. Either you are not relaying the correct information or you don't have the property in your BlockStateContainer. Show it anyway, you have some conflicting information here.

You can specify an alpha test function that would cut off pixels that are too transparent. GlStateManager.tryBlendFuncSeparate(GlStateManager.SourceFactor.SRC_ALPHA, GlStateManager.DestFactor.ONE_MINUS_SRC_ALPHA, GlStateManager.SourceFactor.ONE, GlStateManager.DestFactor.ZERO); This is not the blend function the vignette uses but I guess if it works for your texture just fine then you can keep it... Change the Z level to something big and negative. You can also remove the depth manipulations while you are at it. And change the event to Post instead of Pre. Also an important note - Pre and Post events fire for each HUD element! That means that you are rendering your overlay multiple times over and over again. You need to check the current element being rendered. In your case it would be ALL. if (event.getType() == RenderGameOverlayEvent.ElementType.ALL)

Also you are telling it to render an empty list of strings which is not very productive. It is supposed to contain the description of the item.

Your blend function is incorrect. The first parameter is supposed to be ZERO. Also blend isn't enabled by the time RenderGameOverlayEvent.Pre fires. You have to enable it first. Use GuiUtils#drawHoveringText. The one that takes an ItemStack as it's first parameter. Be aware that rendering the text disables blend and changes the state's color. So you will have to enable blend back and change the color to white after you are done.

First of all you can't do this This will crash the server because GuiScreen doesn't exist on the server. Why are you extending GuiScreen anyway? There is no reason to do so. This will never be false. The RenderGameOverlayEvent fires, well, when the overlay HUD is rendered. The player is never null by then. This will never be false. The player can't have a non-null inventory. This will never be false. The inventory will always have it's armor list instantinated. All of this can be replaced with one line of code: ItemStack helmet = Minecraft.getMinecraft().player.getItemStackFromSlot(EntityEquipmentSlot.HEAD); There, you are done. This does a lot of things to GL state which are not supposed to be there when the HUD is rendered, thus the game can't properly draw the rest of it and all you see is a black screen, hence the Don't call this method. It doesn't really work during the HUD pass anyway. GlStateManager.disableBlend(); GlStateManager.disableAlpha(); GlStateManager.enableDepth(); GlStateManager.color(1.0F, 1.0F, 1.0F, 1.0F); GlStateManager.tryBlendFuncSeparate(GlStateManager.SourceFactor.SRC_ALPHA, GlStateManager.DestFactor.ONE_MINUS_SRC_ALPHA, GlStateManager.SourceFactor.ONE, GlStateManager.DestFactor.ZERO); Why are you disabling blending? The rest of the HUD rendering expects it to be enabled. And if you are disabling it there is no logic in setting the blend function to something else afterwards. Same with the alpha. Don't disable it. In fact don't enable it in the first place, it is irrelevant.

What exactly do you not understand? World#playSound takes in a player that "initiated" the sound aka the one to not play the sound to on the server and the one to play the sound to on the client, the position of the sound, the sound itself(you can find all sounds in the game at SoundEvents class), the category(you can find all categories in SoundCategory class), the volume and the pitch. World#spawnParticle takes in a particle type to spawn(you can find all particles in the EnumParticleTypes class), the X, Y and Z position of the particle, the X, Y and Z motion of the particle and optional additional arguments for the particle(for example ITEM_CRACK takes an ID and the metadata of the item). Most particles do not have additional arguments.

As an ex-programmer, stuff does takes time. These guy's are doing the best they can, it's not like their being paid to do it. These people are taking time out of their busy lives to make something we all can enjoy, so please lay off when it's going to be done crap.

if NetEase needs Forge, they can easily spare some change to financially help the people who make it. Otherwise they are just leeching. Similarly if there are thousands of players on Minecraft China who can't wait for Forge, they can check out Patreon. Otherwise they can just wait.

Yes, it is definitely possible but as my long "essay" above notes it is rarely worth it. 1.10 to 1.11 was a rare transition with very little big things changing between them. Most versions are much more drastic. But imagine going from a version before blockstates was introduced to afterwards -- you'd need to like replicate the whole system of one of the two approaches in order to make them compatible. Or imagine going from a version before capabilities to one afterwards, and so forth. So like I said before -- you can do it but only if you "pick your battles". If your mod focuses on a specific thing like entities and that doesn't change much between versions then it might be worth a compatibility layer.

Actually I think we skipped the important thing, it’s pretty much no trouble to port a mod between versions if your code is easily readable and understandable.

The API approach mentioned above is logically sound, but practically it is more work than just doing the porting directly. Firstly, this all assumes that you will make a fair number of mods to be worth considering such generalizing. But if you do make lots of mods it is likely that each of your mods touches fairly different aspects of the game. Like one might add dimensions, another entities, another items and so forth. Sure there might be some cross-useful stuff, but generally modders end up making either a bunch of targeted mods or one comprehensive mod. So then making an abstraction layer beyond Forge itself doesn't make sense -- you'll be trying to generalize something that you only use a couple times and going through a number of hoops to accomplish even that. I also struggled for a while trying to figure out the best way to support porting multiple mods, because frankly it is a lot of work. At one point I thought that even branching my code would be useful -- like start a mod in 1.7.10 then branch for each additional version up to 1.12.2 or whatever. However, I found that the code changes so much between versions that even that was a waste of time! Honestly, with modding you have both the underlying Minecraft vanilla code as well as the Forge code both undergoing significant overhauls for each version. Heck even the upcoming 1.13 is going to be a huge rewrite! The best thing in the end is just to organize your code in a useful and familiar way and then just put in the work for the porting. One last tip: you need to pick your battles. For example, some things like Entities haven't really changed much through the various versions. But things like blocks have changed a lot with properties, blockstates, JSON models, and registry events all changing and now they are going to be "flattened"! So if you have a mod that focuses on Entities I would highly recommend trying to port it to as many versions as possible. But if you have a mod that focuses on Blocks I would recommend just concentrating on one or two suitable versions to support.

You should maybe edit your old post to provide new textures so we don't spam the Forum. Also it's better to provide the textures in an .zip folder which contains multiple textures.

Copious Fish skewer

Thanks. Will edit it a bit to get the normal stick into it. Will use what looks better. Removed it from the List.

Yes, they are … more or less. They don't do anything yet but I have them, working on the stunning thing. Make more damage already!