alcatrazEscapee/TFC 1.15 Update Primer.md

## TFC 1.15 Update Primer.md

      
    Raw
  

              TFC 1.15 Update Primer.md
            
          
    TFC-TNG 1.15 Update Primer

This is not meant to be a comprehensive guide or outline of everything possible that needs to be done, but rather a series of guidelines on what things should be done during the port in order to improve the code base and take advantage of new systems such as data packs.
Overall Code Style / Organization


Package organization should be kept roughly the same as 1.12, where applicable. The exception is world generation, which is getting a top-to-bottom rewrite
Class names should follow standard Java and MCP naming conventions. This means moving from Suffixes to Prefixes (BlockFoo -> FooBlock), Interfaces prefixed with I, etc.
If a TFC class would duplicate a vanilla class exactly, then it's allowed to prefix the name with TFC, for instance TFCGrassBlock, or TFCBiomeProviderType. In general avoid prefixing things with TFC that don't require it.
Registry objects should use RegistryObject<T>, as they provide convenient implementations of what were existing Map<V, T> as part of block or item classes.

Summary of Major Changes

Blocks / Items


Where possible, we should use vanilla item / block classes for TFC added content.

Stuff that used to be in large "overarching" classes should be moved elsewhere. As an example:

IItemSize becomes json, so ItemTFC has no purpose and can be removed.
ItemPottery is just a provider of IItemSize, and IItemHeat, both of which are json, so it can be removed.
Map<K, Item> or Map<K, Blocks should be moved to TFCItems or TFCBlocks, and used in combination with registry objects to perform inline registration + reference storage.
ALL metadata references should be properly flattened into separate items, blockstates, or TEs as necessary (there are a few existing ones hanging around)

Registry Types (Rock, Rock Categories, Metal, Ore, etc.)

When updating registry types, there are a couple main goals:

TFC will perform NO conditional registration.
Addons are free to add new blocks or items using TFC classes (that means no TFC block / item classes that store enum types by class name)
Data packs are able to inform TFC of special blocks, items, or other properties.

How to implement this depends on the usage of the registry type. For instance, Rock Category can become an enum, with no extensions, as there's no reason for a mod to overwrite it.
On another hand, Rock can become an enum, but only used internally. TFC block or item classes shouldn't auto-add to Map<K, V>s on construction, or take enum constants as parameters, as that prohibits their use by addons.
On the far end, Metal becomes two things: An internal enum, which is used for block and item registration, but also a JSON reloaded object which can be used to add other metals to TFC, by specifying any required existing blocks and/or items

An example metal, defined in data/modid/tfc/metals/adamantium.json
In some cases, refer to existing blocks / items / fluids.

{
	"translation_key": "modid.metal.adamantium",
	"fluid": "adamantium",
	"etc": "...",
}
Basic rundown:

Rock -> json + backing enum
RockCategory  -> enum
Ore -> json + backing enum
Metal -> json + backing enum
Tree -> interface + enum / classes
Plant -> interface + internal enum + Flora json
Crop -> internal enum + interface
IFruitTree -> internal enum + interface + Flora json
IBerryBush -> internal enum + interface + Flora json

Capabilities

TFC provided capabilities should remain much the same way they are now, albeit changed to utilize LazyOptional<T>. However, their application should change:

For capabilities that define static data (i.e., nutrition values on IFood, or metal content in IMetalItem, these should be done via custom resource loader, which is built into a Map<Item, T> on reload. This then performs the function of allowing pack makers to specify properties of other items.
All of TFC's native capability objects should be defined in the above manner. This means NO IItemSize implementation on Blocks or Items, NO IMetalItem implementations, etc.

An example would be the following food definition:

In a file data/modid/tfc/foods/apple.json


{
	"ingredient": "#minecraft:apple",
	"nutrition": [0, 0, 1.0, 0, 0],
	"decay_modifier": 1.5,
	"etc": "..."
}
If an object requires a custom capability implementation, (for instance, small vessels), then it should provide that in initCapabilities, and thus override any attached implementations.
Recipes


Every recipe should be re-implemented as a custom RecipeType, with JSON based parsing.
NO direct craft tweaker integration should be added. Everything will instead be exposed via json or datapacks.
Consider re-using common json elements for multiple recipes. i.e. avoid defining special recipe types which perform a lot of hardcoded effects, unless absolutely necessary.
Recipes should be auto-generated using python scripts. Any recipes that are added by hand must NOT have the comment: this was autogenerated inserted in them, as that is used to automatically replace and update recipes via scripts.
Ore Dictionary is replaced with tags, everything here should be auto generated.
ANY item, block, or fluid reference that even has a chance to be customized should use a tag. These are very powerful. Use them.

World Generation

World generation is being completely rewritten. By the nature of the fact it is completely customized, there are obvious incompatibilities with other mods:

Any new biome mods are incompatible
Any new world generation / world type mods are incompatible

However, some changes are planned to be made to alleviate the differences between TFC and vanilla world generation, namely:

Biomes will have much more vanilla-style variants, which are determined by their TFC counterpart.
Small feature based world gen can be added through two json defined types: Flora, and Fauna
Ore generation is being rewritten to be much more similar to Realistic Ore Veins, and not rely on hidden TFC internals (so addons should be able to use the full ability of TFC ore generation, i.e. rock type blending, graded ores, etc.)

This is still heavily work in progress, so talk to AlcatrazEscapee about what needs doing.
Assets

Forge blockstates are gone (or, should be considered so). All models should be switched to using autogenerated files, vanilla format only. mcresources is the chosen tool of choice to do this with.
For Contributors


Pick small things to work on at a time, since a lot of things are interconnected and will require systematic changes.
Avoid work duplication - discuss in discord who is working on various parts.
Mechanics should be ported forward exactly as they are. Any exceptions need to be properly discussed first. (again, the obvious exception is anything world gen related)