Defaults are:
-Dforge.logging.mojang.level=info (note that setting this to debug or trace will enable extra debug behavior which may slow things down or detect issues and crash)
-Dforge.logging.console.level=info
-Dforge.logging.file.level=info
-Dforge.logging.debugFile.level=trace
Usage: /forge gen <position> <count> [dimension] [notifications]
Position is in Block Coords, and can be relative to the player. These will be converted to chunk coords for you.
Count is the number of chunks to load. This is not a radius, actual total number of chunks.
Dimension is optional, you can use this to pregen other worlds.
Notifications is the chunk interval to inform you of the generating progress. This is optional and will be 5% or 100 whichever is higher.
Added new config option to modify vanilla world gen to fix various cascading issues. MC-117810 MC-114332 and more.
This WILL change block placement from vanilla world gen. So this is a opt-in value. Do not report differences in worlds with this flag enabled.
Moved Registry events to directly AFTER PreInit instead of before.
This allows modders to register handlers for it without @EventBusSubscriber.
It also allows you to register custom things needed before the construction of blocks or items such as Fluids.
TODO: Move Fluids to a real registry.
@ObjectHolder can now be used on private fields.
Reworked FMLModIdMappingEvent to include data for all registries.
Tile Entities are now registrable.
Tests do not run yet.
Things of note:
Removed the idea of substitutions, just register multiple items with the same name they will override each other like a normal map.
Decoupled Forge registries from vanilla classes. They now use bouncer classes. MODDERS SHOULD NEVER USE THESE
Introduced more stringent registry locking. As it sits things are only allowed to be registered during the RegistryEvent.Registry phases!
This is to force modders to split up their registrations, and pave the way for calling these functions multiple times during a single MC lifecycle.
ObjectHolder, Missing Mappings, etc... *should* now work for all registry types, nothing should be special cased to Blocks/Items anymore.
Added optional generic dummy factory to registries, to allow registry creators the ability to dummy more then just Blocks.
Re-worked the ItemStack transformer and applied it to ItemBlock and ItemBlockSpecial. Allowing us to cleanup reflective hacks in Block callbacks.
Registry onAdd callback is now only fired on the ACTIVE registry, fixing any issues of temp registries overriding active objects.
Some things to note:
Netty is screwy so currently can't join single player. @cpw
Crafting has been MAJORY reworked. The current GameRegistry functions are nooped, this is IN THE WORKS.
Just need to move the recipe list to a full class registry, and then re implement the in-code recipe registration.
Also, it IS advised that modders move to JSON, because ideally we'll see a S->C recipe syncing system in 1.13
which would allow servers to have custom recipes.
OreDictionary currently 1/2 works, need to write a better algorithm for replacing ingredients.
Please be patient
Rendering:
A lot of functions got a new float parameter, this is similar to partial ticks, needs more research
Allowing increased control of which enchantments can be put on an item over Vanilla's hard-coded item type checks.
Render enchantment buttons disabled when the item is enchantable but the enchantability requirement is not met on lower levels.
Each mod gets its own version number, mods SHOULD NOT rely on other
mod's fixers, just care about yourself.
Walkers can use IDataFixerData to retrieve their version.
Since the update to Minecraft 1.9.4 chunks were actually never loaded
asynchronously because a sync request was always made from the
PlayerChunkMap shortly after the chunk had been queued.
- PlayerChunkMapEntry now only loads chunks synchronously *after* the
chunk failed to load asynchronously.
- Fixed some minor bugs that caused "Attempted to dequeue chunk" messages
- Simplified ChunkProviderServer patch. loadChunk no longer generates chunks,
so there is no need to handle that.
- Moved loader and provider to ChunkIOProvider so there is no need for
"hashCode abuse"
Major things to note:
Class renames: https://gist.github.com/LexManos/44dd211f90f498ad4015279b103dff86
Tile Entities are now packed in the ChunkData packet.
Forge intends to work around this to better support large moded worlds, but for the time being modders should implement the new function carefully and only send what data they need to!
Minecraft's codebase now has annotations, these are directly from Mojang and should be adheared to!
Added support for package-info.java's containing @Nullable information for all MC code base.
Modders can now modify and reference internal elements of a loot table by name.
Editing can ONLY be done in the event and any external editing will cause a exception to be thrown.
See this gist for more information: https://gist.github.com/LexManos/77c983d67b9ad27010428478b66d50fd
Added detection of mods that rely on Java 8 and a graceful error screen.
The nag screen will be shown once a day. It can be disabled by editing the forge.cfg.
However it is HIGHLY recomended that user update to Java 8.
When combined with @Optional this should address all issues of soft dependancy on mods/apis.
This also addresses the issue of dynamic functionality in TileEntities/Entities.
Current capability providers: TileEntity, Entity, ItemStack
Also added INBTSerializeable, a generic interface for game objects that can be written to/from NBT tags.
Vanilla capabilities will be coming soon, mostly on request and review.
So start requesting capabiliteis on vanilla/Forge features.
Entry point: ModelLoaderRegistry
loader interface: ICustomModelLoader
custom model: IModel
ModelLoader is responsible for splicing into vanilla model system.
(you probably don't need to use it directly)
Interop with vanilla models isn't great yet
(vanilla models can't refer to custom ones as parents), will improve in
the future.
Includes loader for B3D models, with animation support
(net.minecraftforge.client.model.b3d).
Blender export plugin with compatible coordinate system:
https://github.com/RainWarrior/B3DExport
OBJ loader is being written, will be included at some point in the
future. For now you can convert OBJ to B3D via blender, or wait.
Some notes:
Almost all int x, int y, int z parameters have been changed to BlockPos class
ForgeDirection has been removed, replaced by net.minecraft.util.EnumFacing.
All FML classes have moved from packet cpw.mods.fml to net.minecraftforge.fml
Fluid Rendering has been disabled for the time being, to be re-evaulated and a test mod created for it.
Minecraft now uses a Model based system for rendering blocks and Items. The intention is to expand the model format to better suit modder's needed once it is evaulated.
As such, The model loaders from Forge have been removed, to be replaced by expanding vanilla's model format.
Metadata has been extracted out in Minecraft to IBlockState, which holds a list of properties instead of magic number metadata. DO NOT listen to the fearmongering, you can do EVERYTHING with block states you could previously with metadata.
Stencil Bits are disabled entirely by for the main Display, Modders must enable and recreate the FrameBuffer if they wish to use Stencil Bits.
* Added ability to AnvilUpdateEvent to alter stackSizeToBeUsedInRepair (vanilla behavior is now reproducable)
* Added AnvilRepairEvent, fired when the player removes an ItemStack from the output slot of ContainerRepair, and allows the chance to damage the anvil to be altered.
When a player triggers a chunk load via walking around or teleporting
there is no need to stop everything and get this chunk on the main thread.
The client is used to having to wait some time for this chunk and the
server doesn't immediately do anything with it except send it to the
player. At the same time chunk loading is the last major source of file IO
that still runs on the main thread.
These two facts make it possible to offload chunks loaded for this reason
to another thread. However, not all parts of chunk loading can happen off
the main thread. For this we use the new AsynchronousExecutor system to
split chunk loading in to three pieces. The first is loading data from
disk, decompressing it, and parsing it in to an NBT structure. The second
piece is creating entities and tile entities in the chunk and adding them
to the world, this is still done on the main thread. The third piece is
informing everyone who requested a chunk load that the load is finished.
For this we register callbacks and then run them on the main thread once
the previous two stages are finished.
There are still cases where a chunk is needed immediately and these will
still trigger chunk loading entirely on the main thread. The most obvious
case is plugins using the API to request a chunk load. We also must load
the chunk immediately when something in the world tries to access it. In
these cases we ignore any possibly pending or in progress chunk loading
that is happening asynchronously as we will have the chunk loaded by the
time they are finished.
The hope is that overall this system will result in less CPU time and
pauses due to blocking file IO on the main thread thus giving more
consistent performance. Testing so far has shown that this also speeds up
chunk loading client side although some of this is likely to be because
we are sending less chunks at once for the client to process.
Thanks for ammaraskar for help with the implementation of this feature.
This commit is based off the following :
Bukkit/CraftBukkit@b8fc6ab2c1Bukkit/CraftBukkit@85f5776df2Bukkit/CraftBukkit@0714971ca2Bukkit/CraftBukkit@7f49722f45Bukkit/CraftBukkit@53ad0cf1ab
Block placement/interaction
Tesselator crash due to wrong mapping
Missing isreplaceable check in world.canPlaceAt
Small foratting/logging cleanup
Temporarly commented out efficancy changes till I implement it.
cpw