Roboguy99

True. It would be stupid to port it yourself if the devs did it for you anyway. I just said it for the sake of saying it really.

https://github.com/CoFH/RedstoneFlux-API/tree/1.8 It is also very easy to port from 1.7.10, which I did before discovering the 1.8 version.

Fair enough, lesson learned. I'll try to ever avoid using them in the first place in future. I always fall down the trap of "I'll change those later" and don't until I stare at the code for a week wondering why I put a number where I did.

Kill me. public int getField(int id) { switch (id) { case 0: return this.processTimeRemaining; case 1: return TileOreProcessor.PROCESS_TIME; case 2: return this.energyStorage.getEnergyStored(); case 3: return this.energyStorage.getMaxEnergyStored(); } return 0; } public void setField(int id, int value) { switch (id) { case 0: this.processTimeRemaining = value; break; case 3: this.energyStorage.setEnergyStored(value); } } setField case 3 should be case 2 . Further evidence that magic numbers are hell. I'm changing them now.

Err...I'm going to say no, they did not...Perhaps you should explain what you mean by BlockState property enums more? That code is far from being finished and tidied, and yes, I know, the magic numbers do need to go ASAP. Hell, the whole class is a disgusting mess that needs splitting. The get/set field methods do sorta sync, but I guess that's not properly syncing between server/client? What *should* I be doing to sync then? And why does processTimeRemaining sync when the energy doesn't?

I'm trying to implement the RF energy API on a TileEntity. I'm having quite a bit of trouble with synchronizing the energy between server and client though. What confuses me most is that I am already synchronizing another variable, processTimeRemaining , without an issue. Replicating the same steps for energy has not worked. I thought perhaps I need a packet, but processTimeRemaining works without one, which confuses me. The exact issue is with a progress bar in the GUI not being synced correctly; investigation shows this is because the client/server show different values for the energy. As I said, this issue does not exist with processTimeRemaining . Code: TileEntity update TileEntity sync code (various methods as well as energy getters/setters until pretty much the end of the class) Container Gui I'm sure it's something stupid and obvious; it normally is. I've spent hours trying various things, and nothing has worked so far, and I am very confused. Any help is appreciated.

Got everything working now, thanks a lot everyone! If Item#onUpdate only fires when the item is in a player's inventory, is there any advantage to keeping the parameter as an Entity as opposed to a PlayerEntity?

Hmmm I wonder public void onUpdate(ItemStack stack, World world, "Entity entity", int par4, boolean par5) Ah! I forgot casting existed. I assumed that was related to the actual item rather than the player. Thanks. -- I know it may seem stupid to you, and I fully understand why you get annoyed, but perhaps a little less of the sarcasm please? People have to start somewhere...

Right - I've taken everything into account (and overall the code is a lot better), but I'm still getting the same issue (stack size 0). I think maybe this is because I'm using Minecraft.getMinecraft().thePlayer so the update is inevitably still client-side only, in which case how do I get the player from the server? Or is it something else (it normally is...)? Code here.

Ok I thought of that and dismissed it for some reason. NBT would probably be better due the number of variables I need to store. Is it safe/efficient to update NBT every tick?

Everything you just said made total sense and seems so obvious I feel really stupid. I saw Math.Floor earlier and thought "Oh I put /=, it doesn't matter I'm ignoring the return". One thing though: How would I store it on the ItemStack (principally as opposed to literally)? Is there an ItemStack tick method, or do I need a TickEvent or something else? At this point I've gone from stupid to blank. This is why you don't leave unfinished code for months...I started this method like half a year ago... Thanks for all the help so far.

I didn't actually think I needed a packet, I just quickly made one to be 100% sure...The reason I left such a mess of code in was mainly to give people an idea of what I had actually tried. Anyway, to my understanding I was already doing that? I've tidied the code up: if(!world.isRemote) { Math.floor(stack.stackSize /= 2F); //Reduce stack size f(stack.stackSize == 0) stack = null; } But this doesn't run. After some investigation, though, I have discovered that this is due to the half-life tick system and lag/desync. I'm afraid I'm about to hijack my own thread a little bit here. Currently I am attempting to reduce ticksUntilUpdate every time the item updates, but the number does not decrease by 1 every time and the server and client threads are on different numbers (either that or IntelliJ has a problem keeping up with printing numbers so often?). As a result, the update code is never actually fired server-side. Is there a "proper" way of counting ticks/firing code every second? Code here

If you only want the GUI to be client-side, you can use the GuiScreen class instead of GuiContainer , and this way you won't need a server-side container.

I am trying to create an itemstack "half-life" system, in that every x number of ticks the itemstack halves in size. Then, when the stack is at a size of 1 and halves, I want the stack to be deleted. I am sure this is really simple, but I have tried everything I can think of and the stack does not delete properly. Instead, it displays with a stack size of 0 in red, and then as soon as you right click/drop/attempt to move in inventory it is instantly deleted (making me think it's an odd sync issue). This runs in the item's OnUpdate() method As you can see, there is a lot of things there, and I'm fairly certain everything there results in the same odd 0-sized stack. Here is the ItemDelete packet referenced in the above code (again, I've tried pretty much everything): Sorry the indentation is a bit off...

EDIT: Ah, you picked it up before I did. I just didn't read your reply in time. Thanks again.

Well I registered the ItemBlock and it worked perfectly. I then thought about why it crashed when I didn't register the block. I then realised the block is used as a creative tab icon, so it crashed. Whoops. -- Thanks for the help, I'll look at those two other things you just mentioned and change them accordingly.

I've commented the registry line out: https://github.com/JakeStanger/Chemistry/blob/master/src/main/java/roboguy99/chemistry/block/BlockCompoundCreator.java#L30 I'll try actually registering an ItemBlock still and see if that makes a difference still though. P.S. how do you get shortened GitHub links?

Hmm, I'm registering items rather than blocks, and just to make sure I've disabled all blocks from my mod. I am a little unsure with the new registry system though. Is this correct? this.setRegistryName(name); GameRegistry.register(this); (where this is a class extending Item ) The game launches correctly, but maybe it's the problem...?

Code is on GitHub, same link as before. https://github.com/JakeStanger/Chemistry/blob/master/src/main/java/roboguy99/chemistry/item/element/render/BakedModelElement.java Line 429 is if (stack.getItem().showDurabilityBar(stack)) Forge version 1.10.2-12.18.1.2011 just so you know.

Sorry to bring this up again after so long, but I haven't had the time to play around since you replied. I have (as far as I can tell) done what you said, and I'm still getting a NullPointerException. It is is a different place this time though: As far as I can tell, nothing from my BakedModel class is null, and it's quite difficult to put breakpoints in item render code due to how often it executes. I hope this is an easy fix and me being stupid, thanks for any help.

Ok that helps loads, thanks a lot. One thing: `if(!(model instanceof IBakedModel)) model = new IBakedModel.Wrapper(model, DefaultVertexFormats.ITEM)` The wrapper class no longer exists. What does this need to be, if this line needs to exist at all? Also, upon attempting to render the item the game crashes with a NullPointerException: I haven't got time to properly debug this at the moment, so is there anything obvious? My two existing theories are a) it's to do with the line above (I commented it out to test) or b) it's the bottom 2 methods in the class returning null (what should they be returning?)

So I've been porting my mod from 1.8.9 to 1.10.2, and for the most part I've been able to do so without an issue. There are a few things I've been unable to fix, however: 1) `Block#setBlockBounds()` apparently no longer exists. What is the replacement for this? 2) What is the purpose of the new return value on `TileEntity#writeToNBT()`? Is it safe to just ignore it? 3) (This is probably the larger question) `IFlexibleBakedModel` has gone. I previously wrote (with a LOT of help from Diesieben) rendering code so my item displayed using a different model in the player's hand compared to everywhere else. Is this an easy fix, and how would I go about updating this? See here for code. Any help is greatly appreciated. And just so you know my knowledge of the model system is pretty lacking.

The item there can be any item, as long as it's registered. I don't know why that method takes an Item argument, all it does is make sure the given model will be loaded & baked so it's useable in-game. Where do go from here: Put a breakpoint in your IPAM and check what it does. It should never return null nor itself. Make sure it does not! If it does, check why. Found it! Y'know those methods you said would never be called in the IBakedModel? Well RenderEntityItem calls getItemCameraTransforms , which returns null. To fix it, all I had to do was return ItemCameraTransforms.DEFAULT . It's all deprecated, so as to what the deal is with it, I don't know. It might be worth pointing that out to a Forge model dev or something though... And with that, everything works exactly as it should. Thanks a lot for the help and actually sticking with me. EDIT: I'm on Forge 1.8.9 - 11.15.1.1722 if that helps/matters in any way.

You're looking at an old version of the ClientProxy there. Try this. That might save a little bit of confusion. I'm still confused about the model-loop thing. Does that mean I could specify any item I liked in there? It requires an item to register, surely? So I need to give both models to every item, no? I didn't realise the "element_" models are actually rendered. In my head, out of sight out of mind.

Eh? Maybe if I explained a little better: -Textures switch correctly in the inventory or when the item is held. This works absolutely fine. There are no errors about missing models or anything. -The game crashes when I drop the item, and it becomes an EntityItem. In terms of the models: -In the first instance, every element's name starts with the "element_" prefix. That is the registered model, but it does not actually exist as a resource because its never rendered. -The second instance is checking that it's an element, because every element name starts with "element_" and so do all of the registered model locations. -The third instance, where I used "element-" is the model when it is displayed in the GUI, and it does exist. I understand it's pretty poor and confusing at the moment, and I am slowly going through and tidying everything up. Perhaps it's because one of the models doesn't exist, but surely that wouldn't crash the game, because it should either return one of the two IBakedModel models or display as if the model wasn't found? And the loop - I'm registering 118 different items; surely I can't register 118 different items without looping, and surely it's therefore not the same thing being registered twice?