delpi

I saw a post a while back where someone did just what you are talking about. I can't remember the details though. Have you search for other's work? I think it had CD Player in the title.

stack.getItem().equals(Item.beef) or something like that.

Ah, thanks. I looked at that for a few minutes and my mind just wanted to read what it thought should be there and I couldn't see it.

I have no idea what or why you are doing all that. For a container and Gui look at the standard tutorials Need an inventory Need a container that utilizes this inventory and the player inventory to build Need a gui for the above. Need a guihandler What entity are you updating? Is this inventory in a custom entity you made or a tilentity? If its a customentity, you will need a packet to update the client. If its a tile, then setblockforupdate works fine.

There is an another way (probably will be disliked). 1st person view is a bit ugly, still working on that part. Create the render for the item as a modelbiped Extend a livingrender event (or whichever one you like) and only override the gettexture part In the json item model, set the scale for 3rd person to 0,0,0. (for a piece of armor, provide a texture that is empty) Watch the event for playerrender post If the player has the item in hand, pass the render details to your custom render above. Bam, item in hand. Full model. No need to figure out angles, ect. It just works. Can use this for armor, ect. I actually created a how render manager class of my own to track all this just for simplicity but overkill if doing one item. Now, should you do this if don't have a fair amount of experience? no.

It really sounds like you have something acting like a particle not a full entity. I would suggest not creating a full entity for them. Just create a client side render mechanism.

To 2nd Ernio's comment, I don't think you have the skill yet to do something like this. Try something simpler first. Now, the question is, what are you trying to do? why a seperate skin server? You want to be able to have different player models? Want HD skins? What? I'm struggling with why you would want this.

Those two look identical. What did you find?

java.lang.IndexOutOfBoundsException: Index: 47, Size: 45 The problem is called out right there.

clienthax, i might be reading the code wrong, but that just looks like a cache of who has been logged on since the server started, not all the players represented in storage. What has been your experience with it?

I was joking around. The ... meant my bad. Sorry you misinterpreted. Didn't mean to dodge my goof. For the record, I copy/pasted the wrong tab and didn't realize it. After it was pointed it out, I fixed it to avoid confusion.

Sorry you don't like my style, I program in a lot of different languages and on control systems and this is what I consistently see and use. Though you could be right with Java and bukkit influence. The additional check was from before. Left it in there just for reference. Not being called. On the NBT, why not. If i have my read/write statements correct, how is that going to hurt? Its a lot cleaner of a packet send. If there is something it will hurt, I'm very interested, I just haven't run into any issues. I originally wrote the packet to pass all the individual variables like I used to, but it had 20 different variables and it was a PAIN to adjust. I have a reason for storing a list of entities. I'm careful with it to make sure they are still real. The world wouldn't cut it because it is only a list of entities I've chosen. No automatic cut would return it. Is there another way to track that? I guess I could write a tag to all those entities an then cycle through them. Seems very inefficient in comparison.

No idea, they are not anywhere in my post. Take a look.....

Thanks Ernio, that was the ticket. Sorry if I stretched this topic, but I thought it was tied to it and would help the OP. For those that are out there looking for an example packet to update extendedentity data, here you go.

Thank you. Not what I was hoping for, but reality is what it is.

In the process of converting from names to UUID's I ran into a snag. I'm trying to get the name of an offline player. I get all the uuid's off the offline players from looking for the stored data files for the players. It worked well in 1.7 and it still works fairly well now, except for the name. From what I've dug through, I need to get the name from the GamerProfile. Its not stored in the players's data file. I'm using this to get the gamerprofile on the server GameProfile profile = MinecraftServer.getServer().getMinecraftSessionService().fillProfileProperties(new GameProfile(uuid, (String)null), false); It runs, but the name always comes back null. Tried it with true on forced authentification, but no luck. This is the same code used for skulls, so I'm unsure why it won't work. Is it possible because i'm in dev environment, its not talking to MOjang? If you try to trace out the code, it is ultimately in "YggdrasilMinecraftSessionService" in minecraft.

diesieben07, I implemented this but the onStartTracking method doesn't work. When i send my packet to client (entityId, and NBT data), the client says the entity doesn't exist yet. Sure enough, with checking my old code that watches for the client entity ID to update itself, this hasn't happened yet. The server has not informed the client yet of what its entityID should be by the time onStartTracking event has fired for the player on the server. Thoughts?

Do we post gradle compile errors here or in the gradle folder? the gradle folder doesn't seem to ever get answered.

I assume the 2nd one is shown as working and the 1st is not working. So, you started it up, worked fine. Shut it down. After restart, it never called the render again.

Gui - render background, text, whatever the heck - tile.getMana() oops, that returned zero or null Sync data from server to client. Wow, now the tile on client knows what server knows. This time when my gui looks, it gets real info. In your tile - make sure everytime you change a value, send the packet from server to client. I actually mark a flag on the tile and then on a periodic tick update the client, but if you only have a few fields, so be it. - make sure your variables is stored in NBT - make sure the packetreceived on client method in the tile updates right.

Again I will say, when the tile entity on the server changes, tell it to send a packet to the client updating its tilentity. markblockforupdate. Have your tilentity read/write the nbt data correctly. Let the GUI naturally update with the new data from your freshly updating tile. You don't need to worry about who has what opened.

Alright, something is changing your render/model somewhere for some reason. Let's find it. On your client, put print statements on your 'ItemRenderFullyBrockenBedrock' 'renderItem' method to print the current 'TileEntitySpecialRenderer render' and 'TileEntity entity'. Right after the glitch happens, close quick, go to your client logs and see if you can see what else happened right about then.

Jabelar, I tended to go your option 2, but I am finding updating to 1.8 is making me second guess that. It is annoying to go into each one and adjust it. With a master one, I could just fix it in one place.

Just off the top of my head, I would create extendedproperties for the player and track it all in there. If you don't want to do that, use the persistent NBT tag on the player to store it.

Thanks you. On a side note, I have a hard time reading the comments next to your post with the shaking dog image. It really pulls your attention away. Its epic.