ChampionAsh5357

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.

No, it has to do with how anything works. Imagine you were trying to cast an instance of Object A to Object B (let's say Object A is LivingEntity and Object B is PlayerEntity). We cannot blindly cast one to the other as not all LivingEntities are PlayerEntities. Therefore, we have to insure that the entity is a player before casting using some sort of check. The same is true for an Optional. We have to verify that the instance our optional is holding is the same of that we are trying to grab. Since we cannot compare generics directly , the next best thing is to compare the two singleton capabilities itself as they are directly related to the instance they are holding. A lazy just defers initializing or calling a specific object until first access and then stores the result. It provides a way to grab a pointer to an instance of an object before it might be specifically registered. Lazily using objects is quite prevalent in Java itself as can be seen with how Streams work.

Can you please show the entire code block including that of your ItemGroup. To me, some of this code just seems a bit out context. For example: Why is this used as the namespace when you already have an instance of the namespace itself?

I'm pretty sure it has. That would be due to the placements. To make placements more versatile, they have been separated and allowed to chain on one another. This means that one placement might add more trees to generate, the other may spread them out, and another could change their height coordinate. Take a look at a tree ConfiguredFeature within Features to see what I'm talking about and replicate the chained placements. Note that their order does matter in how they decide to generate.

Why are you using a registry object if you just plan on grabbing the entry directly from the registry itself? For reference, the constructor only adds a handler to the object to populate the objects whenever they are frozen. However, since you are constructing after the snapshot occurs, they will never be populated. This can be circumvented by calling RegistryObject#updateReference, but there is simply no point as you can just grab the instance from the registry itself directly via ForgeRegistries.

You just ignored what I said. You're telling me an issue based on runtime testing and not on debugging. You can go all the way into Minecraft#clickMouse and put a breakpoint over the case where the RayTraceResult is an ENTITY and view what's getting called where and why. However, telling me the same problem without debugging the process like I mentioned above is just repetition and not solving the issue. So, follow the code from where the entity is clicked on all the way to it's final result. If you are in fact targeting an entity, it should be recognized by the resulting ray trace. You should even be able to verify that your mouse is hovering over the existing entity by simply opening the debug menu.

Well you have a block with six faces. Each face will connect to a different block on four sides. However, it will cover all six faces regardless. So, you will need a state per face (SixWayBlock has an example of this) to check what textures should be present. From there, the texture can be updated based on the corresponding states of the surrounding blocks. You should probably use a data generator for this.

First, this is taking in a registry object when it requires an entity type. Second, this looks like that the call in a parallel event will not be deferred, so defer it properly within a DeferredWorkQueue (assuming this is 1.15).

Yes, that is true. All entries have a registry key of some kind which can be obtained from the specific registry it's within. They are all singletons, so it doesn't particularly matter that the biome entry is referenced as a key. You can still parse the name of the biome into a registry key with some parent. The biome would still spawn. This is evident by their implementations across the versions. This can also be seen via Lex's comment on a post to reintroduce the BiomeManager. The only difference is that spawn biomes are specified in the spawn info of each biome itself instead in some list. So, this claim needs some base to be reviewed. Once again, read what I wrote above. You would need to create a json biome and probably attach the biome via it's registry key to the layer on server start and remove on server stop. A registry key is just a concatenation of the registry and the object registered. You can grab both of these.

You should probably put a breakpoint within your part class at attackEntityFrom and see whether it calls the statement as it looks like it should.

Yes, the console output is occurring only whenever you hit the parts. However, it will not cause any damage to the actual entity as that returns false. You need a better descriptor rather than 'it just doesn't work'.

The process doesn't change regarding Eclipse, IDEA, or VSCode. Any IDE can be used, some just require more work than others. You must import and run the gradle information and generate your runs. As for how to do this, you can probably google. Importing a gradle project into VSCode is within the internet, and then from there you would just need to generate the VSCode runs which is a provided task by Forge. Happy hunting!

All you need to do is register the config. The Load and Reloading events should be handled to setup any caching that might occur. Any server related config information that requires an instance of MinecraftServer can be handled initially within FMLServerAboutToStartEvent and then updated with some sort of invalidator. However, this information should be cleared whenever the server is stopping as it will not persist across worlds.

Look at how the end is generated. Then, replace the instances of end stone with obsidian and work from there.

Not true, no client synchronization nonsense is going on here. It's the same reason as it was last time when you replaced getSignMaterial within the TER. You are calling EditSignScreen which grabs the material via SignTileEntityRenderer::getMaterial which hardcodes to the vanilla asset library. So, create a custom screen that uses your entry instead of vanilla's.

Probably chain to your block properties Properties#notSolid or update your VoxelShape to the correct size via Block#getShape.

Code Style 6 That's called a capability that needs to be synchronized with the client.

People will respond when they can. Don't unnecessarily bump your thread. As for the answer, look into the IDE you use for hot swapping your current running instance. It's like you're trying to "debug" the process.

Nope, world generation is usually completely undocumented. Just look at the vanilla source for where they put dirt and/or farmland and you'll find what you need to change.

That's what a data generator is for. Instead of doing it all by hand, you just write an algorithm that makes it for you.

A data generator is a way to automate creating json files via providers. Current versions of the mdk have a base build.gradle set up so you do not need to edit anything. Then, I would suggest reading through the docs with their information and build off of there.

I'm going to guess the crash report says 'cannot cast ServerWorld to ClientWorld' or something like that. You need to check if you are on the correct side. Otherwise, it's a blind cast and will throw errors.

You need to make a custom feature for trees as they will always check if there is dirt or farmland beneath them before spawning.

Split it into multiple files. There should almost never be a reason to change different items using the same JSON file unless your item has dynamic storage that changes it's outlook. This would most likely be done via some kind of ItemOverrideList if you were to ignore my recommendation.

You never register your DeferredRegister to the mod event bus. Also, pick one method to register your objects and not two.