Jay Avery

An update: I found that the server-side container didn't have the EntityPlayerMP as a listener. Adding this seems to have fixed the above problems but now another one has started. When loading a saved world, the client doubles the player's inventory contents. So if the world is saved with a stack of sticks in the inventory, then when the world is loaded there will be two stacks. But this is only client-side, and as soon as any slot is clicked the extra items disappear and the inventory resets to the correct contents. It seems like the inventory is somehow being sent to the client twice, but I can't figure out where or why this happens. It's hard to track inventory stuff in the code because there are several sub-inventories and also several wrappers and they're all public and accessed in lots of different places. Can anyone help me understand where and how the player inventory is synced to the client when a world is loaded? Or suggest what might be going wrong with this new bug?

Bump!

Can you post your whole Block class?

If you're making your own block class, it's easiest not to use events. Everything you want to do can be controlled in the block class itself if you are writing it. If you want your block to be almost the same as an existing vanilla block, the very easiest thing to do is extend the vanilla class and only make the changes you need.

In my mod I replace the player's survival mode inventory container. It works almost perfectly, but I've had a long-running issue that in a very small number of situations, it doesn't synchronise properly. So far, the only situations it definitely happens are: Using the /give command Using JEI recipe fill What seems to happen is the client doesn't know the container has changed, so the slot still looks empty. But when the slot is actually clicked, the correct stack appears - items are never actually missing, just invisible. I've tried stepping through the debugger in as many places as I can think of, but the syncing code is really confusing and it's particularly hard to keep track of what happens on the different threads. The main mysteries to me are a) it only happens in such specific situations (it never seems to be a problem when clicking or moving items manually in the inventory - but isn't this all controlled by ultimately the same code?), and b) it only happens in my replacement inventory container, not any of my other custom containers like crafting devices. Mystery b) particularly makes me suspect it's something to do with the way the container is created in the first place - it not being properly linked to the GUI or something? But if that's the case, surely it would never be properly synced, rather than working almost perfectly except for a handful of particular cases? I'm really stuck on this, and it's frustrating because it's a comparatively minor issue that seems almost impossible to find or solve. Can anyone help? All the code is on github. Probably-relevant parts: GuiOpenEvent, where I replace the vanilla inventory GUI with mine. PlayerTickEvent, where I replace the vanilla inventory container with mine in survival mode (and change it back in creative mode). My container class. My GUI class.

Update: I figured out that the tabs are repopulated from scratch whenever the creative inventory is opened, so the approach I first tried is right. I just had to add a null check to skip over the world time when the world doesn't exist yet.

Oh thanks, that gives me some ideas. I'm not sure one birth time check would work though, because it's checked every time the item is drawn in a GUI (for the durability bar) - so the first time it was checked it would be updated and then subsequently it would have a 'valid' value and not be changed again. But maybe I can add a field to the capability to store whether it's in a creative tab (or somewhere else that needs it to be infinitely fresh), and if that's true then keep updating (or perhaps just ignore) the time.

I have in item with a decay capability, which depends on the total world time (the item stores its 'birth time' and then calculates the difference from the current world time to get its level of decay). At the moment the default behaviour is that the items in the creative tabs are all given a 'birth time' of zero, which means they end up all being already rotten if the world has existed for a while. I just experimented with using getSubItems to set the capability using the client world, but this is null when the creative tabs are worked out. Is there any way for me to set the item's capability data at the point when the creative inventory is opened, or when the item is picked up from it - rather than it being set at startup and never changing?

What exactly are you doing in getUpdateTag? You should just return an NBT compound with the tileentity's own data, I can't see any reason you'd need to access the world or blocks.

Your modid is a string, so it should be enclosed in quotes as a literal, or referenced as a field. This is again not a modding problem, it's a fairly basic Java problem.

getActualState should be called any time the block needs to be modelled - use the debugger and set a breakpoint to see whether the method is actually being called. I suspect the issue is actually that your tileentity is not synchronising with the client properly when it loads.

Where do you register your item models?

Post the latest log, it should contain texture/model errors.

I'm not an expert on using @ObjectHolder, but I think the declared type has to be Item and not a subclass of it?

Is the method definitely being called?

Where do you register your items?

Try it and see!

You need to assign a value to your world field - if you don't know what that means, you should probably focus on getting the hang of Java basics before working on a mod. There are also other issues with your code. WorldClient is a client-only class, which means referencing it in in your main class will crash on the dedicated server. In general, you should usually use a world instance that is passed to you in whatever context you're using it, rather than storing your own. In this case you should be able to use the EntityPlayer's world.

So, you never initialise TestMod1.world.

boop, talk to me about logging!

Alright! It sounds like the easiest solution might be to use durability/damage to store your 0-100 sharpness. (If you don't want the durability bar to show then override showDurabilityBar in your item class). Then you could use a property override to give the item a different texture for different ranges of damage. Take a look at ItemElytra and its models to see a vanilla example of using addPropertyOverride.

You're still not explaining what you actually want to do. Can you describe it in gameplay terms, without referring to data, NBT, or any code concepts?

Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register This approach is buggy and very outdated. Instead you should use ModelLoader.setCustomModelResourceLocation, in FMLPreInitializationEvent. Also, you should use the registry name, not the unlocalized name: new ModelResourceLocation(block.getUnlocalizedName(), "inventory")

There is a good chance that the log contains a hint about the problem... please just post it. Also, make sure your git repository is up-to-date if you want help with the latest issue(s).

If you want the different variants to have different ItemBlock models, you will need to specify those models using their metadata in setCustomModelResourceLocation.