Jump to content

Roboguy99

Members
  • Posts

    230
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    Some useless guy.

Roboguy99's Achievements

Creeper Killer

Creeper Killer (4/8)

2

Reputation

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. 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?
  8. 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...
  9. 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.
  10. 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?
  11. 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.
  12. 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
  13. 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.
  14. 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...
  15. EDIT: Ah, you picked it up before I did. I just didn't read your reply in time. Thanks again.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.