Minecraft Forums

Heyhey!

Not an old-timer here, more a mid-timer at 26 years old. I'm looking to get back into multi-player and meet new folke after my LAN party group disbanded, and hope I'll be a good fit here.

I build close to others, and am quite fond of building towns / villagers and jamming them full of villagers.

I'm a redstoner (no, not a commmunist smoking weed, the other type) / builder. Predominantly I like to build minigames / theme parks and farms on request. I'm not on any other servers, and would likely be on for 1-2 nights a week (UK time), a few hours each session. That's for general play though, I'll absolutely jump at the opportunity for organised events. I can be reached on discord at: Cookiehook#1528

I'm re-acquainting myself with the 1.13+ changes to commands, and was a bit of a whizz at setting up command based minigames if that's of any interest to you!

Don't know about finding if they're sprinting, but here's the relevant code for adding a potion effect to a player:

entity.addPotionEffect(new PotionEffect(MobEffects.BLINDNESS, duration, amplifier, false, false));

entity = Whatever you named your entity at the top of the method call.

Duration and amplifier must be integers. The Boolean flags are for setting particles and "ambient" effect.

You could try overriding updateTick in your custom block's class, checking for lava in in neighbouring BlockPos' then updating the current blockstate to whatever you want.

The BlockMushroom class has enough of the method calls you'll need, I'd suggest looking at that. Note that this is for spreading mushrooms, but it still checks surrounding blocks then changes those blocks, which is close enough to learn!

New release for 1.12!
Now supports potions and armor from other mods.

Right, question time:

Do those other languages include C#, or heavy use of another OO language? If not, this task might be beyond your reach. Java's static / non-static and access modifiers can confuse a non-OO programmer, so you really need to know a language which has the same concepts.

For actually doing the update, here's how I think about updating my own mods.

Forge is essentially an API. That's a piece of software that's expecting you to make certain method calls and provide objects / resources in a particular way. The reason we need to update mods is due to Forge updating what it expects your mod to ask for, so you need to change your method calls / resources. That's what your 100 errors are, you're making calls to Forge methods or variables that no longer exist, so you'll need to find what their updated counterparts are (if they even exist).

I have two pieces of advice here:

• Don't try to port from 1.7.10 directly to 1.10, port to each major release a step at a time.
• Write your own mods, if you haven't already. Follow some simple tutorials on your version for creating an Item / Block / Entity. Once you've seen how it's done, you'll be able to see the parallels in the code your updating.

Coming out of 1.7.10 is tricky. A lot of hard-coded data and textures were moved out to .JSON files, and item registration changed to be event based shortly after. Feel free to keep asking for help with particulars here, I might be able to assist.

I believe this is your issue: Main._MODID+":"+item.getRegistryName() in registerItemModels.

getRegistryName also returns the domain as part of the string, so this line becomes "toybox:toybox:explmin". You've doubled up the domains. You can also see this in the screenshot, the resource thinks it belongs to "toybox:toybox:explmine#inventory". Remove The unnecessary "Main._MODID + ":" from your modelResourceLocation and you should be golden.

This sounds interesting, I'll give it a go

My current thought as to how it would work is:

• Void fog pool / ravines are generated underground, or in the End?
• Void fog is collectable and placeable with a bucket.
• The fog will spread in the dark, replacing air. Similar to grass / mycelium growing.
• Conversely, it will get burned away by high light levels.

I'm toying with the idea of having a liquid source block as a tar-like liquid, that the fog generates from. The fog itself could be burned away by light but the source block would never burn away. Doing it this way might be able to make the void "fog" act like air, having the permeable qualities you're looking for.

What do you think? Does this line up with your ideas?

Re-write and re-release of the mod has just happened!
Now supports versions .17 through to 1.12. See main post for download link.

Mod is done and being reviewed by CurseForge as we speak:

https://minecraft.curseforge.com/projects/liquid-enchanting

Keep checking back over the next few days for the approval, and then you'll be able to download and play!

Mod is done and being reviewed by CurseForge as we speak:

https://minecraft.curseforge.com/projects/liquid-enchanting

Keep checking back over the next few days for the approval, and then you'll be able to download and play!

Resolved in Forge Forums.

In summary, Minecraft code is obfuscated, so fields are named differently in the dev and compiled version. The fields I'm looking for when coding in my IDE are named "name" and "ArmorType". Once compiled, these are named something like "field_177856_a", so my reflection methods couldn't find them.

I've tweaked the code to also print the stacktrace when this occurs, result: https://pastebin.com/gCziedDe

More information (OP was pre-coffee):

The purpose of this getting of private variables is a workaround for using potion's NBT data in crafting recipes, which is not supported by the JSON format. On item initialisation, the ItemPotionArmor's material, slot and potion name are added to a dictionary, using these concatenated strings as a key, and the instance of the ItemPotionArmor as a value. This dictionary is later used by the ShapedArmorUpgradeRecipe crafting recipe class. Once it has confirmed that the right vanilla items are present in crafting grid, it takes the previously mentioned values from the vanilla armor / potions in the grid, concatenates them together, and retrieves the relevant ItemPotionArmor instance to pass back as a result.

The ModItems.getMaterialName is called during item initialisation, in the preInit stage of mod loading. You can see the exceptions being thrown and printed in the server logs at this time. It is also called again when the final item in the recipe is placed in the crafting grid. To test, I've been using standard fire resistance potions and any armor piece.

There's no stacktrace as there's no crash (it's a handled exception).

Here's the log from a server run: https://pastebin.com/NyBqL3ZU

I will be

Hello all,

I've written a couple of methods that use reflection to access private variables from ItemArmor, as their getter methods have been marked as ClientSide only, and don't work on dedicated servers. Line 96: https://github.com/Cookiehook/Minecraft-Liquid-Enchanting/blob/MC-1.12.2/src/main/java/com/cookiehook/liquidenchanting/init/ModItems.java

I'm writing my code using Jetbrains IntellliJ. When I run this code through the IDE, everything behaves as intended. Yet when I build the mod (using gradle build) and run the compiled JAR through a Forge server, I get NoSuchField exceptions thrown. I'm honestly baffled by this.

Can anyone help me understand why the two versions are behaving differently?

Cross-Post to Forge Forums: http://www.minecraftforge.net/forum/topic/67971-compiled-mod-throws-exception-yet-works-fine-from-ide/