[1.16] Boson Modding Tutorial

[FledgeXu 1]

Hey Everyone, this is FledgeShiu.

I bring the 1.16.3 Modding Tutorial. This Tutorial is translated from my same name tutorial which written by Chinese.

I’m not a native English Speaker. So that, this tutorial may have a lot of grammar and words problems. If you find any problem please tell me.

If you have any question or feedback, welcome join my Discord Server .

 

Notice: It's still in translation.

Tutorial Link

 

1. 1. Introducation
2. 1. 1.1. What is Forge?
   2. 1.2. How Minecraft Works?
   3. 1.3. Development Model
   4. 1.4. Core Concepetion
3. 2. Development Environment
4. 1. 2.1. Setup Environment
   2. 2.2. Introduce Environment
   3. 2.3. Customize Mod Info
5. 3. Item
6. 1. 3.1. First Item
   2. 3.2. Model and Texture
   3. 3.3. Item and ItemStack
   4. 3.4. Item Group
   5. 3.5. Food
   6. 3.6. Sword
   7. 3.7. Tool
   8. 3.8. Armor
   9. 3.9. Item Property Override
7. 4. Localization
8. 5. Block
9. 1. 5.1. First Block
   2. 5.2. Block and BlockState
   3. 5.3. Block's Model and Texture
   4. 5.4. Block with BlockState
   5. 5.5. Not Solid Block and custom model
   6. 5.6. Render Type
10. 6. Special Model
11. 1. 6.1. Obj Model
12. 7. TileEntity
13. 1. 7.1. First TileEntity and Data Storage
    2. 7.2. ITickableTileEntity
    3. 7.3. TileEntity's Data Sync
14. 8. Special render
15. 1. 8.1. IBakedModel
    2. 8.2. TileEntityRneder
    3. 8.3. ItemStackTileEntityRenderer
16. 9. Event System
17. 10. Network
18. 1. 10.1. Network Packet
    2. 10.2. Network Security
19. 11. Entity
20. 1. 11.1. First Entity and Data Sync
    2. 11.2. Animal and AI
21. 12. Capability System
22. 1. 12.1. Capability from Scratch
    2. 12.2. Use Predefined Capability
    3. 12.3. Attach Capability provider
23. 13. WorldSavedData
24. 14. Gui
25. 1. 14.1. First Gui
    2. 14.2. Container
    3. 14.3. HUD
26. 15. Fluid
27. 16. World Generation
28. 1. 16.1. Ore Generation
    2. 16.2. Structure Generation
    3. 16.3. Customize Biome and World Type
    4. 16.4. Customize Dimension
29. 17. Data Pack
30. 1. 17.1. Recipe
    2. 17.2. LootTable
31. 18. Data Generator
32. 19. Command
33. 20. Advancements
34. 21. Configure
35. 22. Potion
36. 23. Paticle
37. 24. Sound
38. 25. User Input
39. 26. Compatibiilty
40. 27. Access Transformer
41. 28. CoreMod

Edited yesterday at 07:20 AM by FledgeXu

[ChampionAsh5357 113]

I guess I will do a review of this too and my opinion on what should be fixed.

--- 1.2 ---

Not particularly a great explanation on distinguishing the four sides. Also only reviews one of the few ways to ensure that you are on the correct logical side/thread.

--- 2.2 ---

build.gradle is glossed over again. You need to set information such as version, archivesBaseName, and group just for basic gradle building. This is not to mention it will not work with data generators.

--- 2.3 ---

You do not own boson.tutorial.com. The package name should be the reverse DNS of your site appended with the modid, which in this case would be 'com.v2mcdev.boson.tutorial'. Or actually the modid is boson so 'com.v2mcdev.boson.boson'.

For a personal note, a Utils class is not needed for this and will confuse users trying to understand as they will copy-paste. It's also a waste of an object currently as I'm updating this as I go along.

mods.toml is completely glossed over just inputting parameters and not really explaining them. Also, not all variables listed are present in the default toml. You also seem to remove any dependencies within the toml. Although they are optional, they are good checks to make sure your mod is being run on a supported version.

--- 3.1 ---

Hardcoding parameters again instead of using the superclass instance. It's a waste of resources.

Explain the underlying structure of DeferredRegister and show multiple ways to achieve the same solution. You can also explain the usefulness of the extra layer of abstraction.

You seem to be leading up to hardcoding the same method reference multiple times. Store an object reference and pass that between every instance provided.

--- 3.2 ---

This is the old way of creating JSON files. Use data generators and template models.

Textures should be explained more thoroughly. They do not need to be one to one or preferably no larger than a specific size. It should be these reasons for how UV mapping is handled for 16x16 textures. However, that needs to be explained.

Personal note, should include differences in PNG saving formats in case people wonder why their alpha is rendering black.

--- 3.3 ---

Singletons and flyweight objects are the words you are looking for.

They are not really the same properties or default behavior. It's just what a singleton is.

Don't say to determine if an ItemStack is null. An ItemStack is never null. The item singletone it may be holding is null, declaring the stack being empty. That should be explained.

--- 3.4 ---

Static final variables should be in upper camel case.

Object creation is wasted again. Can just be used as an anonymous class without extending.

--- 3.5 ---

Should explain the reason of deferring the EffectInstance call.

Should not be private as other mods may want to use your food item as well.

Hardcoding parameter (3.1-1)

This could probably be covered all in one page as it is a property that could be reference in 3.1.

Data generator (3.2-1)

Upper camel case (3.4-1)

--- 3.6 ---

Copies vanilla implementation to a tea. No explanation provided.

Should explain the relevance of lazy variables. Although a Java topic, still a good review to those who are just used to algorithmic programming.

Hardcoding parameter (3.1-1)

Upper camel case (3.4-1)

Data generator (3.2-1)

--- 3.7 ---

Hardcoding parameter (3.1-1)

Upper camel case (3.4-1)

Data generator (3.2-1)

Once again, no explanation of parameters.

--- 3.8 ---

Copies vanilla implementation (3.6-1)

Lazy explanation (3.6-2)

Upper camel case (3.4-1)

Armor material name must be prefixed with mod id.

Bit of missed translation.

Needs to explain why a texture goes in a certain place.

--- 3.9 ---

Hardcoding parameter (3.1-1)

Upper camel case (3.4-1)

Data generator (3.2-1)

Choose one method to create listeners, not use multiple different ones.

--- 4 ---

Data generator (3.2-1)

--- 5.1 ---

Probably could use a better explanation between the relation of blocks and items.

Hardcoding parameter (3.1-1)

Store an object reference (3.1-3)

Upper camel case (3.4-1)

--- 5.2 ---

All blocks are blocks. It's not a good idea to think that all singletons are flyweight objects. Two distinct types. Each specific tile in the world is represented as a BlockState which holds the Block instance.

The BlockState does not store the position.

Not a clear explanation of states.

Position attributes are not unique to a block. A position is mapped to a BlockState.

--- 5.3 ---

Data generator (3.2-1)

Textures should be explained (3.2-2)

The loading process is highly oversimplified and personally not a good explanation.

--- 5.4 ---

A property should never be non-final or private. Otherwise, you will not be able to reference it outside of your current setting.

Personal note, a property should usually default to a non-initialized value (eg. boolean -> false, int -> 0). Enums are special cases.

Data generator (3.2-1)

Bit of missed translation (3.8-5)

--- 5.5 ---

No point in a static block.

VoxelShapes should be as simple as possible.

notSolid is used for a few other things as well including lighting.

They are completely explainable. The first method checks whether the block is being placed within a water fluid. The second method checks if the block is being updated with a fluid and if so schedule a fluid tick for that block. The third checks the fluid to grab from the block itself.

Upper camel case (3.4-1)

Data generator (3.2-1)

This frame texture makes relatively no sense as it literally could've just drawn a cube with a hole in the center and wrapped the UVs around that.

--- 5.6 ---

Hardcoding parameter (3.1-1)

Upper camel case (3.4-1)

Client code isolation.

Multiple different calls to the same event with no change in priority.

Needs better explanation of concurrency.

--- 6.1 ---

Hardcoding parameter (3.1-1)

Upper camel case (3.4-1)

Data generator (3.2-1)

Details on object model mapping not present. Should explain more.

All models are centered around (0.5,0.5,0.5) and should be between (0-1) or their conversion to units (0-16).

 

Chapter 7 and onwards are empty. No review is applicable. I probably missed a few things as I glanced over them, but these should cover the necessary major changes. Please consider updating your post to include these.

[FledgeXu 1]

@ChampionAsh5357 ,Thanks very mush. 
The most of your advise is useful and your review is amazing. However, I want to explain some things in this tutorial.

1. The useless Class

I know these classes looks like useless for programmers who are experinced. But, as my practice I found that using separate class can help newcomers understand code better. So I will not change it.

2. The data generation

Actually, I will introduce the Data generation in one chapter. I believe if people can not write json by hand and they will not understand the Data generation. Besides, In some case, people still need write json by hand.

3. About Event registry and other things

The top consider for me is translation, I will add contexts and explains latter when I translated this tutorial.

4. About Code Styple.

This tutorial actually be written in very short time. I will do full check about the code style.

Anyway, Thank you for your advises.

Edited 17 hours ago by FledgeXu

[ChampionAsh5357 113]

No problem. Here are my reasons for those statements if you're curious:

1 hour ago, FledgeXu said:

I know these classes looks like useless for programmers who are experinced. But, as my practice I found that using separate class can help newcomers understand code better. So I will not change it.

However, regardless you should explain that these are not versions that should be used and are only there to aid the reader in understanding. You have to remember that the target audience is those with moderate to no experience in Java and that setting them up with bad practices only pushes them towards those in the future. I just rather you give people the ability to succeed with the tools required rather than fail based on bad knowledge even though it's purely visual.

1 hour ago, FledgeXu said:

Actually, I will introduce the Data generation in one chapter. I believe if people can not write json by hand and their will not understand the Data generation. Besides, In some case, people still need write json by hand.

Actually, there is no case where a JSON should be written by hand. All data can be made into providers and generated manually. My belief is that this is a decent entry-level barrier for those who want to get started in modding. It teaches people that they need a decently moderate level of understanding within Java to be able to mod it correctly. It will discourage those who think they can do it with no Java knowledge and entice them to take the time to learn before getting started. This is how I've been approaching my rewrite of the text tutorial explanations. We're not trying to cater to all audiences, just those who have the determination to see this through to the end regardless of the starting point. Making it seem easy to start and pick up in useful, but with little moderation to know there are standards.

1 hour ago, FledgeXu said:

The top consider for me is translation, I will add contexts and explains latter when I translated this tutorial.

That's fair enough. If you ever need some grammar review or information checks, I'm happy to provide.

1 hour ago, FledgeXu said:

This tutorial actually be written in very short time. I will do full check about the code style.

Fair enough. Code style is one of those things you seem to be consistent with so I wouldn't be too worried. Conventions are what need a bit of work.

[diesieben07 7395]

11 hours ago, ChampionAsh5357 said:

The item singletone it may be holding is null, declaring the stack being empty.

It's never null either. It would be AIR. To check if an ItemStack is empty use the isEmpty method.

[ChampionAsh5357 113]

4 hours ago, diesieben07 said:

It's never null either. It would be AIR.

It can be null if for some reason you decide to pass it in (which you should never do). However, any null value will be received as AIR due to the condition checks or serialized to AIR when writing. My bad on the miswording.

4 hours ago, diesieben07 said:

To check if an ItemStack is empty use the isEmpty method.

This was mentioned in the tutorial, hence why I didn't mention it when I wrote the above statement.