TrashCaster

I'm pretty sure you are supposed to add variants after the original register. Try swapping those lines.

It is working again. That's very strange. Oh well. I can just make my item unstackable.

Ok, for whatever reason, it stopped working. I have no idea why. It worked one time, and now it doesn't, and I haven't changed anything.

No, I just meant in the one call as a temporary list, so that I could iterate through all of them, and not write another "send" line to the active player. More of a code-style preference. But I will keep the rest in mind, thanks a bunch. It's always nice to get help on even the basics.

AWESOME! Thank you SO much. Maybe someone should submit a PR? I don't know why this was overlooked.

So to recap, resync on: Player join world Player start tracking Detect and send changes Because currently it syncs from everything but the "start tracking". I had to use an ArrayList to contain the tracking players, as well as the active player, since I suppose they don't track themselves (I tried just the Set returned by the tracker, and the active player never received the sync). I also unified the calls to a single method, just to reduce duplicate code that may stop working due to not changing all of the occurrences. It is working really well right now too. StartTracking event will basically be the occurrence that a player suddenly appears on a player's screen due to them being close enough, correct?

This is not at all what I was referring to. TEXTURES, not models. I am programmatically generating TEXTURES. And I want to bind GL textures I generate to a quad over top of the builtin/generated sprite. Making the quad is no problem. But the only way to get the texture to show up is to use the hokey methods provided using custom TextureAtlasSprites. If there's a way to stitch a GL texture into the Texture Atlas, using the texture key of a dummy texture, that'd work fine too, so long as you can pick the GL texture from the item stack's NBT.

I'm trying to fix an issue with the mergeItemstack method found in containers. The issue is that if you lower the max stack size of a slot, it does NOT get considered when merging the stacks. I aimed to fix that, only to be faced with no change. @Override protected boolean mergeItemStack(ItemStack stack, int startIndex, int endIndex, boolean useEndIndex) { boolean flag1 = false; int k = startIndex; if (useEndIndex) { k = endIndex - 1; } Slot slot; ItemStack itemstack1; if (stack.isStackable()) { while (stack.stackSize > 0 && (!useEndIndex && k < endIndex || useEndIndex && k >= startIndex)) { slot = (Slot)this.inventorySlots.get(k); itemstack1 = slot.getStack(); if (itemstack1 != null && itemstack1.getItem() == stack.getItem() && (!stack.getHasSubtypes() || stack.getMetadata() == itemstack1.getMetadata()) && ItemStack.areItemStackTagsEqual(stack, itemstack1)) { int l = itemstack1.stackSize + stack.stackSize; int maxStack = Math.min(stack.getMaxStackSize(), slot.getSlotStackLimit()); System.out.println("Max stack of slot "+k+" is "+maxStack); if (l <= maxStack) { stack.stackSize = 0; itemstack1.stackSize = l; slot.onSlotChanged(); flag1 = true; } else if (itemstack1.stackSize < maxStack) { stack.stackSize -= maxStack - itemstack1.stackSize; itemstack1.stackSize = maxStack; slot.onSlotChanged(); flag1 = true; } else { stack.stackSize -= maxStack; itemstack1.stackSize = maxStack; slot.onSlotChanged(); flag1 = true; } } if (useEndIndex) { --k; } else { ++k; } } } if (stack.stackSize > 0) { if (useEndIndex) { k = endIndex - 1; } else { k = startIndex; } while (!useEndIndex && k < endIndex || useEndIndex && k >= startIndex) { slot = (Slot)this.inventorySlots.get(k); itemstack1 = slot.getStack(); if (itemstack1 == null && slot.isItemValid(stack)) // Forge: Make sure to respect isItemValid in the slot. { slot.putStack(stack.copy()); slot.onSlotChanged(); stack.stackSize = 0; flag1 = true; break; } if (useEndIndex) { --k; } else { ++k; } } } return flag1; } The change I made is replacing occurrences of stack.getMaxStackSize() with a variable, and using Math.min to determine the lower stack max (either from the item type, or the slot max). This does not change a thing. I also added an additional else statement with a different operation to it. That didn't help either. How can I go about fixing this? Note: The purpose of this is because I want to limit the slots to 1 item per slot (which I have designated without issue), but allow shift clicking the items in, thereby allowing an inventory to fill up all the slots, if need be. The current effect is that it moves the itemstack to the slot, but only 1 (the maximum of that slot) is actually there. It should carry on through the other slots, filling them up, and then finally leaving any left over items where it was.

No, there are better ways to achieve the desired effect without screwing with gl shit. And the benefit of using a standardized atlas performance wise far outweighs your issues with it. Are there examples on how to achieve dynamic textures based on NBT? Note, I do not mean "change between a series of pre-done textures in the assets", I mean the ability to programmatically generate textures for items.

Like the title says, expand the MouseEvent to allow mod creators to cancel the mouse movement (zeroing the deltas). The main point to this would be to lock a player's rotation when they try to move their mouse. CameraSetupEvent only affects the camera's rotation, as the player can spin freely as they wish. That is a no-go. "Teleporting" the player back to a rotation looks hideous. It's jittery, and awful, and I won't be a part of that crowd. Alternatives include: Release the final modifiers on the delta x and y variables in the event, so you could just set them to 0 when the event is fired. Create a new PlayerRotateEvent, which fires on both client, and server, allowing flexibility on each end when either the mouse moves, or the server is about to rotate the player via yaw and pitch updates Opening this up would allow mod creators to do more immersive "cut scenes", or animations and renderings that look better when the player is not in turning. For example, when I was working on a hookshot mod, it looked really weird to fire it, and the player could turn around while holding it as the spike was pulling chain away from them. Locking the player rotation would help with effects like that. I would even be alright with a new EntityPlayer#setRotationLocked(Object mod,boolean locked). The purpose to having the mod instance would be to allow several mods to lock the rotation for their own purpose, but not unlock it later when another mod needs it locked.

The ability to override the GL texture would be nice too, using ItemStack as a parameter. This way you could use dynamic textures without having to stitch a dynamic TextureAtlasSprite. I've tried to make an item have dynamic textures the way a clock and compass do, and not only is that hokey, it's a pain in the ass that I couldn't get to work for me, no matter what I tried. So being able to re-assign a GL texture ID before the item is rendered would be awesome. Maybe even another parameter that identifies the current texture path of the render pass, so you can change the texture from both the NBT, as well as which texture layer to override.

Ok, so maybe I should invert the transform, and then re-apply it using the other player's transform? Like so: EntityPlayer p1 = Minecraft.getMinecraft().thePlayer; double x1 = p1.prevPosX + (p1.posX - p1.prevPosX)*event.partialTicks; double y1 = p1.prevPosY + (p1.posY - p1.prevPosY)*event.partialTicks; double z1 = p1.prevPosZ + (p1.posZ - p1.prevPosZ)*event.partialTicks; EntityPlayer p2 = event.entityPlayer; double x2 = p2.prevPosX + (p2.posX - p2.prevPosX)*event.partialTicks; double y2 = p2.prevPosY + (p2.posY - p2.prevPosY)*event.partialTicks; double z2 = p2.prevPosZ + (p2.posZ - p2.prevPosZ)*event.partialTicks; GL11.glPushMatrix(); GL11.glTranslated(-x1,-y1,-z1); GL11.glTranslated(x2,y2,z2); // Render GL11.glPopMatrix(); EDIT: Just tried this, and it does work. However, one issue is if a player adjusts their inventory, the old information is merged with new information. So basically, anything that became null isn't turning null on the client. So maybe upon receiving the packet (on the client), the player inventory should be cleared, and then have the NBT applied, since the packet won't send null information. EDIT 2: Just tried clearing it client side before the NBT gets loaded, and that fixed it. The only issue I have now is that upon joining the world, the player won't fetch the information from the server. Does the JoinWorldEvent fire on just the server, or on the client too? Cause my thought is to make the client send a request packet to the server, and the server responds with a sync packet. To elaborate on the above, here's another infamous representative scenario: Bob joins world. Doesn't see his items. He opens his accessory inventory, causing sync packet. Now he sees his items Jack joins world. Doesn't see his items, nor Bob's items. Jack opens his accessory inventory, causing a sync packet. Jack and Bob both see Jack's items. Bob opens accessory inventory again, and now Jack can see his items. For the join world I used tracking entities, as mentioned for the inventory changes being sent. Code for if you don't want to re-snoop my GitHub: if (event.entity instanceof EntityPlayer) { if (!event.world.isRemote) { EntityTracker tracker = ((WorldServer)event.world).getEntityTracker(); tracker.sendToAllTrackingEntity((EntityPlayer)event.entity, TSM.NETWORK.getPacketFrom(new SyncPlayerPropsMessage((EntityPlayer)event.entity))); Set<EntityPlayer> otherPlayers = tracker.getTrackingPlayers(event.entity); for (EntityPlayer p:otherPlayers) { TSM.NETWORK.sendTo(new SyncPlayerPropsMessage(p), (EntityPlayerMP)event.entity); } } } EDIT 3: I think it is to do with the data saving/loading on the server being iffy, and not sending proper information to the clients. I tried scheduling a sync in the update event to see if it does sync it, but it never does unless the players open their inventories. My GitHub is updated to the latest source, so if someone wouldn't mind looking through it to get me back on track with proper synchronizing, that'd be swell. It feels as though I tried to cover as many bases as possible, and have sync calls that are redundant, or wrong. I'd like to minimize the calls, while maintaining accurate synchronization between client and server.

Also, (and sorry for the double post, I sent the previous off without adding this bit, and don't want to get ninja'd), I moved the packet registration out of the proxies, and into the mod class, as you suggested. It looks like this: @EventHandler public void preInit(FMLPreInitializationEvent event) { NETWORK = NetworkRegistry.INSTANCE.newSimpleChannel("TSMnet"); NETWORK.registerMessage(Message.ServerHandler.class, Message.class, 1, Side.SERVER); NETWORK.registerMessage(Message.ClientHandler.class, Message.class, 1, Side.CLIENT); NETWORK.registerMessage(SyncPlayerPropsMessage.ClientHandler.class, SyncPlayerPropsMessage.class, 2, Side.CLIENT); PROXY.preInit(); } I took out the line: NETWORK.registerMessage(SyncPlayerPropsMessage.ServerHandler.class, SyncPlayerPropsMessage.class, 2, Side.SERVER); cause the server doesn't need to handle the packet, right? EDIT: So that crashed, cause I derped and let the server try to load client side code. I moved those lines back into the ClientProxy. To be honest though, I see no problem with having the server lines in the CommonProxy, since the ClientProxy extends it, and calls the super preInit anyways. EDIT 2: And when I removed the aforementioned line, it caused the client to disconnect. I added it back, and the client can connect. So the server still needs to register the handler and message, even if it doesn't do anything with it. And that wraps up the networking part. Back to square one, with potential optimizations. Now how about the RenderPlayerEvent issue?

Alright, and then because I'm sending the packet with the inventory changes (detectAndSendChanges), it should be like this: // New code if (!this.player.worldObj.isRemote) { EntityTracker tracker = ((WorldServer)this.player.worldObj).getEntityTracker(); tracker.sendToAllTrackingEntity(this.player, TSM.NETWORK.getPacketFrom(new SyncPlayerPropsMessage(this.player))); } as opposed to my previous // Previous code if (!this.player.worldObj.isRemote) { TSM.NETWORK.sendToAll(new SyncPlayerPropsMessage(this.player)); } Is that right?

Oh jeez, I missed that. Maybe they're using a "cracked" account, and are choosing to call it something else?

I think they mean the development system loading up the game with a name of 'Player', suffixed by a random number. The idea that you are using a "fake" account over a paid Mojang certified one.

Thanks for the quick reply. As far as packets from client to server, the only one I send from client to server is Message which tells the server that the player attempted to open the accessory inventory, which the server then submits to the GuiHandler. And for storing the inventory in a client side IEEP versus the hashmap, I did do that before, and didn't have the results I was expecting, so I thought changing this may be better, but only found it to have the same end result. I will switch back. I had followed your guides for all the inventory stuff, but the "sync packet" area was a little vague, so I put it into ContainerAccessories in the detectAndSendChanges method. I used the packet tutorial from diesieben07, so I may have to re-read that to see if there's something I missed, though it is already working perfectly fine for the messages. The reason why I used the HashMap instead was also because when a client receives the sync packet, they get the UUID of the player to update, and the NBT tag of the data (whether the be the whole IEEP, or just the inventory). And the client handler isn't able to track players from other worlds (dimensions). So I just wanted to let them be in sync too. But I guess that'll get corrected when they step through a portal, and fire off another EntityJoinWorldEvent, right? I just thought as seamless as possible would be best. So, correct me if I'm wrong when the client receives the sync packet, the handler should do the following: EntityPlayer player = Minecraft.getMinecraft().theWorld.getPlayerEntityByUUID(message.playerID); ExtendedPlayer.get(player).loadNBTData(message.tag);

So basically, what I'm doing is rendering accessories to the player (for testing purposes, these are just block items in my custom inventory). I have the inventory working properly, and the packets to synchronize the inventory to the clients (so they can display objects from the contents). But for whatever reason, when I'm trying to render to a player, it renders to only the local player, and it renders items based on all other players in view. For example, my current setup allows you to put block items into the inventory. When it renders the player, it will render the block item model at the player's location, with a vertical offset equal to 0.5 + the slot index, so as to make a "stack". So to explain what is currently happening, here's a representative scenario. Server has players Bill, and Jack Bill has a dirt block in his first slot Jack has an oak log in his second slot On Jack's screen, while in third person, he sees a dirt block near his feet, and a log in his torso. He does not see the log on Bill anywhere On Bill's screen, while in third person, he sees a dirt block near his feet, and a log in his torso. He does not see the dirt on Jack anywhere Bill turns away so that Jack isn't visible on his screen, and while in third person, he now sees his dirt block near his feet Jack now takes the log out of his inventory, and Bill turns back On Jack's screen, while in third person, he sees a dirt block near his feet On Bill's screen, while in third person, he sees a dirt block near his feet So what is happening? Well, simply put, each player on the server has their information in sync on the clients. The RenderPlayerEvent is supposed to fetch the correct inventory based on the player it is rendering. It does this. However, it never renders to that player. It simply renders to the local player. Is this something I can fix/work around, or is this something within Forge that needs fixing? Here's my GitHub repo: https://github.com/TrashCaster/TheStuffMod-2.0

Take a look at GuiContainer and look at the drawItemStack method. It should have you covered.

The problem with using an invisible light block is that it needs to be in the gridspace. If there are other blocks in the way, the block won't show up because it can't be placed. The hacky method used in Dynamic Lights doesn't need a block to be set.

In your place chest method, your isProtected method is redundant since it passes over to the placeBlock method which has the check. That's not why your problem is occurring, but I thought it's still worth pointing out.

You can make 3D items with Minecrafts model format. I'm not going to explain that since there are a dozen tutorials for that. If using voxels isn't your thing, then you can replace the model with a new IBakedModel. TheGreyGhost has a tutorial project for that kind of thing. Just search Minecraft by Example. Do note that if you use the IBakedModel method, you do have to use quads, not triangles. However, they don't need to be cuboid quad groups.

My custom "TextureCanvas" class replacement, or the base texture? My problem mostly is when I remap the entry at texture stitch time (I don't even know if I should be doing pre, or post. But I have done both) it never calls the update animation method. I tried doing exactly what the compass and clock do (empty animation in the mcmeta file) as well as mapping an extended class to the entry. Those entries are mapped to builtin/compass and builtin/clock. The JSON models for those have their parent set to those, respectively. I tried doing that with my canvas model, and I got the "broken model" issue (the black and pink textured cube/square). I try doing it in a texture field, and still the same. Literally the only thing that has made a dent for me is either to remesh the model with a smart model and each pixel is its own colored quad (kills fps), or to try and use the render player event to render an extra quad manually with the texture bound. The latter does work, but obviously is bad practice for the new system, as well as makes more work for myself (copying transforms and whatnot). I refuse to use render player event though, since I want this to apply to the item model so it could be used anywhere.

Still no solutions? The last thing I want to do is set up 4096 quads in a smart model for each pixel color. That's a lot. There needs to be a simpler and faster way to put the GL texture on the model.

Also, a nice way to use colors is to use java.awt.Color So in your class, you can have a Color field like so: Color lineColor = new Color(0,255,0,255); Then when you want to use the color integer, use lineColor.getRGB(); Though the method is getRGB, it will also return with the alpha bits. Doing so also helps make the code nice to read, and involves less guess work for the person viewing the code.