Draco18s

If you were using ISBRH before, the JSON model system will work just fine for you.

Jesus christ on a crutch.

Ok look. We're going to play black jack. I have dealt you two cards. They are a five and a three. <ChunkGeneratorEvent fired: five> <ChunkGeneratorEvent fired: three> Do you want a third? Here you go here is a third card. It is new and it is a seven. <ChunkGeneratorEvent fired: seven> Would you like another card? ...

Likely you will have to use fully qualified names

ChunkGeneratorEvent (of which there are 3 sub events, one of which is the PopulateChunkEvent which has its own 3 sub events) DecorateBiomeEvent (of which there are 3 sub events) which is involved in chunk generation OreGenEvent (of which there are 4 sub events) which is involved in chunk generation

If the chunk was just generated* then.... ...it will be a new chunk. *There are, of course, multiple stages of chunk generation and may not occur immediately one after the other...

It depends on what you want to do.

There's an event for it, but actually there's several events for it. That's why we want to know what you're doing, so we can point you at the most appropriate one.

http://www.baeldung.com/gradle-fat-jar

Chunks being generated happens so far away from the player that that behavior doesn't even make sense. What if the player is falling / flying at the time? Teleporting? Riding in a minecart or on a horse? In a boat?

Tell us what you want the player to see happen.

Use Java 8.

Find the correct string from the CSV file. It's a comma-separated-values file, open it in literally any spreadsheet program, ctrl-F. You're probably going to find more than one field named "rand" and you're just going to have to try each one until you find the right one.

This is horrible practice. Absolutely horrendous.

No. They shouldn't.

Who's ender chest inventory would that give you? Again, your proposal makes no sense. Recipes are simpler because there's exactly 1 copy of the recipe shared across all players. The same is true for blocks and items. Capabilities can have an infinite number of instances. NBT is for saving to disk only, it should never be used in any other circumstance. And "literally takes seconds" is fucking slow. No one would want to wait "seconds" for a hopper to extract an item from a chest or to push power down a wire.

The definition of the capability and its implementation need to be separate objects. Your proposed idea misses the fact that there may be multiple instances of the implementation, e.g. a chest inventory is a Capability<IItemHandler> and there may be hundreds of chests each with their own copy of an IItemHandler implementation. You can't just say CapabilityManager.INSTANCE.get(new ResourceLocation("forge:inventory")); and get anything sensible back. What would it give you? the Capability<T> or the T? It can't give you the T because of the aforementioned issue. Which means it must return the Capability<T> (which is a wholly separate object!), which, surprise, is already available, CapabilityItemHandler.ITEM_HANDLER_CAPABILITY. For other mods' capabilities, there's already the @ObjectHolder annotation.

This is true, I did skip over that possibility.

If you want to create a new capability, then yes, you do. You need an interface that describes your capability, then you need to implement it: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/interfaces/IMechanicalPower.java https://github.com/Draco18s/ReasonableRealism/tree/1.12.1/src/main/java/com/draco18s/hardlib/api/capability What you are looking at is a Generic. https://en.wikipedia.org/wiki/Generics_in_Java Capability<T> means "This is an object of type Capability of some subtype." It is not an array, an array is just another type of Generic. In order to provide a return from getCapability you need to cast to Type T: return (T)someObject; All of this is described in the docs: https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/

TileEntity already Implements ICapabilityProvider. You don't need to do anything but override those methods.

No. Does vanilla have a double-slab item? No it does not. You don't need one either.

For the life of me, I can't figure out why you should even care. If you check "this chunk" and then the 3 neighbor chunks at +X, +Z, and +X+Z (all of which are guaranteed to already exist, even if they have not yet been populated) then you should be fine. If they have been populated already, you don't cause further population. If the current chunk caused anything to appear in them, you find it. If they haven't been populated, you don't cause further population (because vanilla already expects cross-chunk-boundary placements to occur in this direction and not cascade population). If the current chunk caused anything to appear in them, you find it. If that chunk's own population would place it, but it hasn't populated yet, you don't need to care, because it will fire its own population event. ALL OTHER CHUNKS ARE IRRELEVANT

True, he does. But the stack trace doesn't say what went wrong, only where.

On top of that, print out "error" without saying what kind of error helps nobody. (Ironically a problem I've had working with the Oculus SDK lately: API fails to initialize for any reason? dll not found exception. Store transaction failed or was canceled by the user? Oculus.Platform.Model.Error)