Draco18s

If by "more efficient" you mean "as there are more players, everyone fatigues faster." If you want to use world ticks, do world.getTotalWorldTime() % 200 == 0. The slight discrepancy of a player joining / leaving off-cycle will be pretty much unnoticeable.

WHY would you ever want to do this?

Well, you're clearly counting ticks as a global value, not a per-player value. This is bad. Imagine you have 200 players logged in... World ticks (time 1), all entities are ticked... Player1 ticks, ticks is now 1. Player2 ticks, ticks is now 2. Player3 ticks, ticks is now 3. Player4 ticks, ticks is now 4. Player5 ticks, ticks is now 5. Player6 ticks, ticks is now 6. ... Player198 ticks, ticks is now 198. Player199 ticks, ticks is now 199. Player200 ticks, ticks is now 200, Player200 is fatigued. World ticks (time 2), all entities are ticked... Player1 ticks, ticks is now 1. Player2 ticks, ticks is now 2...

Give gradle more RAM

Post your code.

You should use the direction you want to insert the items from. For chests, it doesn't matter, but for other containers (like the furnace) it does. If you want "everything" (e.g. a non-specific side) then pass null.

TileEntity chestContainer = worldIn.getTileEntity(po);

Where does this go? Show this code.

OH MY GOD. 1) use the ModelRegistryEvent to register your models (where are you even calling registerRenders()?) 2) use ModelLoader.setCustomModelResourceLocation(), ModelMesher has been the wrong way to do things for over a year. 3) use getRegistryName(), not getUnlocalizedName().substring(5), this has been the wrongest way to do things for almost two years. 4) this is client-only code and you have it in a common class, this will crash the dedicated server, this has been wrong since forever. What version are you even developing for? you should be using the RegistryEvent.Register<Item> event to register items, this has been true for a year. Also, use setRegistryName() instead.

No, use a Capability if you can. You can even attach one to the player. Your setup is fundamentally flawed. Areas that are unloaded cannot be accessed.

Well that's not helpful is it? "I have a problem with X, here's a log after I removed X." And, of course, you didn't tell us anything about why you can't connect to the server...

What you are doing is not supported by Forge.

AH HA, NOW WE KNOW WHAT THE PROBLEM IS. That is: your problem isn't teleporting, it's telling the two portals where to go. Here's the solution: you need to store the destination coordinates somewhere else. I don't me a reference to the TEs, I mean, the player says "this object needs to be a destination" and you store the location in an Item or a Capability, then when the player goes to the other portal, you read from that.

See. Here's the thing. It shouldn't bloody matter where the destination is. You send the player, bam, done, everything's golden. We're trying to figure out why the hell you need to get any data from the destination at all.

forge:forgebucket would be a internally constructed code-model. It won't exist in the assets at all (fluid block models are done the same way).

No?

https://bugs.mojang.com/browse/MC-9553

No, you're wrong. Did your inventory previously only have 1 slot? Are you reloading a world with a TE that had been previously saved?

Not only is the answer to that yes, but if the mods you're using use GlobalIDs, you can't fix that.

I thought that might be true when I posted, but I wasn't sure. 256 per mod was always "more than any mod will ever need." Even Mo'Creatures only adds fifty eight.

Cool, thanks Choonster. Shame the oredict isn't ready / populated when recipes get parsed or I could pass the oredict value straight to the constructor and skip over the getRecipeOutput and getCraftingResult overrides entirely.

HA! REPLICATED. Had it happen a minute ago and caught it before I posted (and with a post I didn't need to make because I forgot something dumb)

Pretty much. 256 entities per mod.

You have a couple of these: And then this: Plus, you haven't shown any code.