jabelar

Interesting. However, I use sendToAll() in all my 1.8 mods and haven't seen such a crash before. But of course that doesn't prove there isn't some bug. Is it possible your netty code is old or buggy? Have you tried re-building your workspace? Also, does it happen on other computers as well?

Strange... What does your initialization of the snw field look like?

I usually put in console or logger statements such as System.out.println() and print out useful info. In this case you could print out the bounds of the bounding box and see it if makes sense considering where it is supposed to be in the world you're playing in.

Cool. Yeah it is hard to debug something when it is acting according to your own false assumptions. Glad you figured it out.

Hmmm, it looks correct to me. I'm wondering if maybe one of the values is null when you're trying to construct the message? I'd add some console or logger statements in the toBytes and fromBytes to confirm that the values are what you expect. Normally I expected to find that you had mixed up the order, or mixed up the types, or registered multiple with same ID, or forgot to make it threaded, but it seems that you've covered all that.

If you look in the EntityItem class there is a method called searchForOtherItemsNearby(). What is interesting is that it uses the getEntitiesWithinAABB() method to find other EntityItems. So it definitely should work for EntityItems. And regarding how players pick up items, the EntityItem has an onCollidedWithPlayer() method. So it is just a regular collision, triggered from the EntityItem side.

I believe it is, but it is one reason to try the other method that excludes entity. You can then print out the list of entities found and see if something is there that isn't the class you expect.

For your first question, the particleMaxAge field is protected so you could use Java Reflection technique to modify it. For your second question, the Block class has an addDestroyEffects() method you can call. I think each call creates a single particle so you may have to call it several times to create a "burst" of particles.

I think both methods should work. In both cases, if it doesn't work then it suggests that the aabb isn't correct. You should print out the values of the aabb to console to confirm they are where you expect. They will need to be world coordinates, not chunk coordinates and will have to be big enough to cover the actual area. Also pay attention to the Y-coordinate -- you might be searching on a layer above or below the entity item.

Like all modding you can usually figure this stuff out yourself by looking at similar functionality in the vanilla code. So you think where is the mod names displayed? Well if you aren't sure you look at the vanilla GUI classes. In the minecraft package there is the GuiMainMenu and if you look at the code there, it shows that when one of the buttons is pressed it calls a gui class at net.minecraftforge.fml.client.GuiModList. So then you look in that class and see how it gets the names. What you'll find is that it finds things of class ModContainer that are held in the Loader.getInstance().getModList(). So that looks promising. Then if you look at the ModContainer class you can check out if there are methods to get the mod name (there is getName()) and mod id (there is getModId()). So that should give you enough information to figure out names for a given mod name. You would just cycle through the Loaders mod list and check if the name of the ModContainer matches and if it does then also look up the mod id. Anyway, I didn't know this until I just researched it so that is why I'm explaining how to figure this out yourself next time. Most of us don't know the answers, we just are able to research them efficiently.

To be specific, prior to 1.8 the position of the bounding box on the client mistakenly had the eye level added to it -- you can see in your picture that the bottom of the bounding box is at eye level.

I agree that not knowing what the owner is on the client is likely theory. I think you can also explain the above if the ownership is set in the interact() method (which I believe runs on both sides) then the code would run on both the summoning player's client and on the server, so both of those would get the owner, but you would need to explicitly sync the other clients to also know the owner. Now it seems that's he's using datawatcher like wolf does so it should sync, but I'm just saying that it is quite possible for something that happens in the interact() method to be synced on the interacting player's client and server but not necessarily other clients.

But it might be rotated compared to your viewing angle. That is part of why the math is hard -- you need to find the intersection of a line going from your eyes to a plane that is angled away from you. It is certainly possible to calculate accurately, but the math will probably drive you crazy before you get it right.

Is the button enabled? I think you may need to set enabled to true. Otherwise please show the rest of your GuiScreen code.

I think you have to go about old-fashioned debug. Basically confirm that each part of your code is working as expected. I find this is easiest to do by adding console statements (System.out.println()) at judicious points in the code. For example, I would put statements in the constructor and the setDead() method for the entity and see how the statements compare on the server and client. You might also want to put a statement in the onLivingUpdate() method as well -- this will spam a lot of statements but it would be interesting if they stopped. It is also good to have some possible theories to guide where to look. You say that the entity still "works" but can't be seen by the other player after some point. That means that either the entity is dead on that client, that the rendering is doing something funny, or that the location of the entity has changed somehow to get out of sync and it is truly out of view. For example, to test idea that it is the renderer that is screwing up you might want to put console statements in the render() call to confirm that it continues to get called on the client even after the entity disappears.

I think it is possible, but how difficult it is depends on the model of your entity and whether it moves much. In this case you're considering the player entity which is reasonably complicated and also can rotate and move some parts. Do you only want to check pixels on the main part of the body? Or also on head, arms, and legs. Because the way raytracing works is mostly just trigonometry. You know where the eyes are, then know the look vector but it is up to you to figure out which pixel is hit. For example, if the player was facing you, then based on the model you would know the position of the body and using trigonometry you could figure out the intersection of the look vector with the plane. However, as soon as the body turns it gets much more complicated to get the math right.

Well this is Java so what you do is create a custom world provider but just extend the vanilla one and just change the parts you want to affect. But I also think you can just use the setSkyRenderer() method on the vanilla world provider to point to your own renderer.

Cool, glad it worked.

I already explained to you how. You can put any textures you want by returning them from your own world provider and you can completely override the rendering by providing your own IRenderHandler classes for the sky renderer, cloud renderer, etc.

Did you try replacing the held item yourself? Like every player tick check if the held item is sugar and then replace with your own edible sugar item? And the other way is to fully replace the vanilla by removing it from creative tabs, changing recipes to create your version, and ensure that it doesn't generate in chests or get dropped. And yet another way would be to create your own system for eating those items. Like just count if it being used and decrement your own counter field (or NBT on the item stack).

Doesn't GalactiCraft already have API for that sort of stuff: http://forum.micdoodle8.com/index.php?threads/how-to-write-a-basic-moon-addon-1-7.4452/

I think many people do it as a resource pack using Optifine or MCPatcher. For example look at this one: http://www.minecraftforum.net/forums/mapping-and-modding/resource-packs/2286150-1-8-and-1-7-custom-sky-space-edition-optifine-or If you actually want to mod it, I believe that you want to create your own dimension. Then you can replace the sun and moon textures with code by overriding the getSunTexture() and getMoonTexture() in your world provider class. Looks like Draco has some experience with this: http://binarymage.com/forum/viewtopic.php?f=13&t=936 The WorldProvider class also has getSkyRenderer() and setSkyRenderer() methods, so I assume you could copy the vanilla sky renderer class and change it how you like and use that instead. There is also a getCloudRenderer() and setCloudRenderer() method. And there is also getWeatherRenderer() and setWeatherRenderer() method. I haven't done it myself, but I expect that should be enough to get you to what you want.

ticksExisted is used is several places in the code. If you ever want to understand how vanilla is using something you should use Eclipse to show you the "call hierarchy" for it. You'll see that it is used for things like experience gathering, despawning when no longer within tracking range, and so forth. It may be that none of those are critical for you entity, but better not to muck with it. Instead, what you should do in your entity is have a separate public int field and in your constructor set THAT to a random value. Then whenever your animation needs an index to its animation you can just add the value of the field to ticksExisted. In other words, don't change ticksExisted itself but instead have another field representing the randomness. In fact you could go all the way and not use ticksExisted but rather use your own field and increment that every tick instead. Basically create your own ticksExisted field that starts with some random offset. Regarding packets during the first few ticks, yeah it can be a problem. I've found you cannot send packets to affect entities that were created in the same tick because often the packet will get to the other side and not be able to find the entity. Some people use the entity spawn data to transfer that initial stuff, but I tend to delay a tick or two before sending any sync messages.

As a general strategy for making an energy delivery system, I would recommend the following. The cables should basically check around for any blocks next to it that are a generator, if there is a generator beside it then it should consider itself powered. Then cables should look for any cables around itself that are powered and if there are then consider themselves powered. You could leave it at that (it would create a power system) but it would have a couple issues. First of all, if you deleted a power source it would stay powered. So it could be better to calculate all the power system fresh each tick. In that case you need to iterate until you've propagated the power throgh the entire length of the cable. For example, you would keep cycling through all the cable blocks and check for if any adjacent block is powered, if it is then you power the block and then cycle again -- keep going until you don't find any new blocks that need power. Also, many power systems have a limit on how far the power can propagate. In that case you need to have a power level at the gen4erator and subtract some amount for each piece of cable. But generally the idea is still the same -- each block needs to check all surrounding blocks and propogate power where appropriate. Note that where I say blocks above you probably want to use tile entities since they can contain more complicated data fields and also process every tick.

By the way for Question #1, the client does sync some stuff to the server, namely key press and GUi container stuff. For example, even though you don't see it, if you use a GuiContainer when you take things from the slots and such that information does get synced to server. And of course if you move on the client the server needs to know that so it is synced for you. But as mentioned by CoolAlias, a large body of the functionality just runs in parallel and so is not explicitly synced.