Draco18s

Entities can be constructed and never spawned. But generally, yes.

EntityConstrcuting is fired during the Entity's constructor. EntityJoinWorld is fired when the Entity....joins the world.

The answer to your question is "yes." You just have to be aware that you're on the client side, not the server side. If the data is on the server, you'll need to transmit it with packets.

NBT files are not secure, by any means.

Yes, the question is: Why?

Downloading 1388... version = "1.7.10-10.13.3.1388-1.7.10"

Make sure you changed the complete version number. i.e. not "10.13.2.1388"

Item myItem = new Item().setUnlocalizedName("mymod:myitem"); does not equal Item myItem = new MyItem();

Gosh, probably because:

Fuck. Ing. Hell. I've said this like four times.

Still not converting from chunkCoords to blockCoords. Didn't print any useful information to the console, like the current coordinates checked or the block found...

A != A

regionX != chunkX != blockX rand(16) (NOT 15! 15 returns a value 0-14, which is one block shy of a full chunk, and doing it twice isn't any good because that generates a value 0-30, which is larger than a chunk) generates somewhere within a chunk, provided you convert the chunkX/Z into blockX/Z by multiplying by 16. You're still passing a Y value you're not using: int chunkY = world.getHeightValue(chunkX, chunkZ)+1; generate(world, random, chunkX, chunkY, chunkZ); -> public boolean generate(World world, Random rand, int x, int y, int z) { int chunkX = x + rand.nextInt(15); int chunkZ = z + rand.nextInt(15); int chunkY = world.getHeightValue(chunkX, chunkZ)+1; //int y is never used and is equal to chunkY, except you made the call to getHeightValue twice. }

Ok, two two four six things: 1) You're still adding a random value to your chunk coordinates twice. 2) Your chunk coordinates are never multiplied by 16 (meaning that you're generating around the world origin a lot) 3) One of your randoms is rand(15) for no explicable reason. 4) You generate a random Y value, which is then never used. 5) You have two functions with the same name, but which take different parameters 6) (new WorldGenOWBloodTreeSmall()) WHY ARE YOU MAKING A NEW INSTANCE! YOU HAVE ONE ALREADY, YOU'RE IN IT.

The single tree could have been due to luck picking an initial block that matched your conditions. Without updated code, I don't know what it is that you've changed or how. You can tell me you removed that, but as I can't see it, I don't know what else has changed or what effect it has had.

Based on a thread from a few weeks ago, your largest source of lag for generating your floating islands might be the lighting updates. The farther up the block is placed, the more blocks that need to be rechecked for lighting changes.

Block entities might be trickier, but there are ways to detect those too. If world#getEntitiesInAABB(<Class>) doesn't work, you can just loop through the blocks "in range" and see if any of them have a TE and what kind of TE. It's fast (0.6ms for a whole chunk worth of observation) but I still wouldn't do it very often.

...and then never set it back to true for the next loop iteration.

Ha, nice catch diesieben.

Ok, so, here's the thing. You need an object...er, Object that represents your hivemind and makes each Hive distinct from each other Hive. If there's only one Hive, that's ok too, all we need to do is have a class that represents the collective, whether it be One or Many. This object will be created on world load (or at the very least on startup, then have members inserted into it on world load and removed on world unload) and hold references to each currently active Entity within the Hive. That is, when a chunk unloads and the Entity is saved to disk, the Hive needs to forget that it exists, because it can't do anything to it, so you may as well free up the RAM. The point of this Hive Object is so that you have an upper level for your hive members to communicate through. "I see the player" is emitted from one member, up to the hive, and back down to each other hive member. "Can the hive see the player?" can then also be polled, asking the Hive and getting a response because the Hive Object stores those variables that you're interested in. The Hive can also have its own AI task list, goals, and such just like any other Entity, but instead of being an Entity itself, it's merely an Object that interacts with the world through its myriad member Entities. You can't just "create a hivemind" with entities and an AI task, you need to actually instantiate the hivemind as an object so that you can manage its goals, current tasks, and various members and provide a clean method of inter-member communication. The alternative is far more complicated, and involves creating a set of rules that two members interacting with each other follow in order to determine what task each is carrying out and what needs to be done. This is how real insect hives work: by statistical analysis of how many of its fellows its found performing a given task (indicated my pheromones*), an individual can discern what tasks are being under-performed and switch over to that task, maintaining a goal balance of workload. Figuring out what rules and signals you need is going to be far more work. *This can be observed in ants by coating a living ant in the pheromone that says "I'm a dead body" and watching other ants pick up its fellow and hauling it to the garbage pile. The victim ant will repeatedly attempt to clean itself and return to the colony only to get hauled back repeatedly (until the artificial scent is wiped clean again). It reeks very much of " " and shows off that each ant is actually unaware of what every other ant is doing, except by those pheromone signals and a small set of rules.

Me is braindead. Happens to all of us.

If the texture doesn't show, a message is printed to the log. You didn't include that bit. That said: Why do you bother doing this? this.blockIcon = iconRegister.registerIcon(Constants.MODID + ":" + "basaltStoneBrick"); The whole point of setTextureName is so that in the iconRegistration method the call is made to getTextureName(). setBlockTextureName(Constants.MODID + ":" + name); If later you do this

I think he meant which build. The recommended build is fine, there's several changes to liquids 1355 to 1364, so either get one before that, or one after that.