Leviathan143

There are several hundred of these changes. Fixing them manually is not an option.

Doesn't work unfortunately. I get this: java.io.IOException: Cannot run program "./gradlew.bat" (in directory "C:\Users\<User>\Documents\Modding Workspace\=Contributions=\betterbeginnings-MODIFIED"): CreateProcess error=2, The system cannot find the file specified at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) at net.minecraftforge.remapper.GatherModInfo.run(GatherModInfo.java:71) at java.lang.Thread.run(Thread.java:745) Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified at java.lang.ProcessImpl.create(Native Method) at java.lang.ProcessImpl.<init>(ProcessImpl.java:386) at java.lang.ProcessImpl.start(ProcessImpl.java:137) at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) ... 2 more gradlew.bat is definitely present in that folder. I'm running Windows 10 and Java 8.

I am in the process of updating a mod from 1.8.0 to 1.10.2. There are of course many errors. The majority of these are due to mapping changes. I found and built Forge's Remapper tool; on running it I discovered that had a host of errors. For example, the gradlew.bat could not be found until I hardcoded the full file path. Am I being stupid and missing something, or is this tool currently broken?

Will that delete the bin folder? I've had issues with the bin folder retaining old code before.

Cough, change in stack size, cough. *Cough* Look at the call hierarchy of IContainerListener#sendSlotContents() . *Cough* IContainerListener#sendSlotContents() is called if ItemStack.areItemStacksEqual() returns false. Changes in stacksize, damage value, contained Item or NBT will cause ItemStack.areItemStacksEqual() to return false.

No problem there. Removal or addition of ItemStacks causes IContainerListener#sendSlotContents() to be called, allowing you to sync the cap if the itemstack is being inserted. If it's being extracted, you don't care as it's now in an inventory which the player isn't looking at. The next time it's caps are synced is when the player opens the inventory it was extracted to.

Say...hoppers? I don't quite get your meaning here. Hoppers have a container.

PlayerContainerEvent.Open fires when a player opens a Container. If you just need to sync the cap on opening a container that should suffice. If you need to sync the cap while the container is open, you can attach an IContainerListener. On PlayerContainerEvent.Open attach an IContainerListener with Container#addListener() , on PlayerContainerEvent.Close detach it with Container#removeListener() . You can then override IContainerListener#sendSlotContents() to sync your capability. IContainerListener#sendSlotContents() is called every time an ItemStack in the container changes.

Blockstates only allow rotating models in increments of 90 degrees. Item/block models allow individual elements to be rotated in increments on 22.5 degrees.

but here's the catch, when you stood on it, it was not a log. when you looked at it, it was not a log. when you ran at it and stuck to the side of it... it was not a log. but it was a log? It could be any block for that matter though. But it still wouldn't be whatever it is. Actually it is a log, at least serverside, clientside it is air. The sticky behaviour is caused by the server and client disagreeing on where the player can go; the client says "There's air there, the player can walk inside that block", however the server says "There's a log there, the player cannot walk inside that block" and moves the player outside of the block. The client still thinks there is air there, so it continues to attempt to move the player inside the block, causing the server to move the player outside of the block again. This repeats until the client and server agree, either because the block has recieved an update or because the client has stopped attempting to move the player into the block. It looks like air because the client handles rendering and it thinks that the block is air. It is a bug, I know what I'm talking about. I can provide more proof that it is a log if you are still not convinced.

You need a null check for testBlock. Not all Items have a corresponding Block.

EntityPlayerMP does override Entity#setPositionAndUpdate() , so try changing this EntityPlayer player = (EntityPlayer) entity; to this EntityPlayerMP player = (EntityPlayerMP) entity; Currently you are actually calling Entity#setPositionAndUpdate() rather than EntityPlayerMP#setPositionAndUpdate() . This is becasuee the field player is of the type EntityPlayer, not EntityPlayerMP; EntityPlayer does not override setPositionAndUpdate() and neither does EntityLivingBase, so Entity#setPositionAndUpdate() is called.

It's a bug. I replicated the phantom block with the commands you provided and ran /testforblock on the position of one of the phantom block; as I expected, it was a log. What I think you have here is a block being placed without causing a block update, plus some client/server desync(Yes, there is still a client and a server in SP). If you close and reopen the world, you'll find that the phantom blocks will turn into whatever they're supposed to be. I've had this same issue when a mod hasn't broken a block properly. I specifically remember having this issue with iChun's PortalGun or GravGun.

It's almost certainly a bug, not a real block.

Pigmen have natural armor. Magma cubes, slimes, shulkers, zombies, and The Wither are other mobs that also have natural armor. Item#hitEntity() is called after the damage from items is done, so your implementation will do more damage than you expect. A better method to override would be ItemSword#getDamageVsEntity() .

Yes, ASM is possible. However, if you choose to use it you'd better know what you're doing, as you'll be on your own. We will not assist you. ASM should be a last resort, there are often ways to achieve the same thing without ASM. If you tell us what you need to do, we can help you find a non-ASM solution.

I can think of two solutions to this: 1. Use item/generated as the default model and specify oreflowers:flower as the model in each variant. 2. Create a separate item model .json. When Forge looks for an item model, it checks assets/<modid>/models/item first; if no model is found there, it checks assets/<modid>/blockstates. The MC wiki has a comprehensive article on block models, item models and blockstates here. Additionally you can look at the vanilla models.

Can you post the new blockstate .json please?

As far as I am aware, the forge blockstate format does not support variants that have two conditions. This is based on my understanding of the Forge Blockstate V1 specs. What you can do is use an IStateMapper to instruct MC to use a different blockstate .json under certain conditions. I would advise overriding StateMapperBase#getModelResourceLocation(IBlockState state) rather than implementing IStateMapper#putStateModelLocations(Block blockIn) . Once you have created the IStateMapper , you need to register it using ModelLoader.setCustomStateMapper() .

FMLServerHandler.instance().getServer() will return null on an integrated server. Use FMLCommonHandler.INSTANCE.getMinecraftServerInstance() instead, it works for both integrated and dedicated servers.

It will hit the piston and nothing will happen. This is not quantum computing, an object can only have one state. Nothing unusual will happen whatsoever, your pinball is just like any other entity in the game.

You can get around the second problem with an IStateMapper.

Sounds to me like Gradle mucked up for some reason. As Animefan said, there is only one copy of Forge per Forge version, so if that gets deleted somehow all projects will lose access to it. Though I think that would cause single error, something like "<project> could not be built because it is missing referenced library <library>",

In your current implementation each player has their own instance of Provider- this is the way it should be -however each player needs their own instance of the capability(IUUIDCapability), as your use case requires storage of data unique to an individual player. Your provider should have a field that stores an instance of IUUIDCapability, this field should be set to a new instance of IUUIDCapability in the constructor of the provider. In getCapability, return this field instead of calling player.getCapability().

Yes. If the player does not have the capability, getCapability() will return null; since you call a method on the return value, if the player does not have the capability an NPE is thrown. Use hasCapability() to check if the player has a capability.