ChampionAsh5357

I'm not complete sure on where you could do this, but each structure piece holds a unique identifier IStructurePieceType that you could use to get a single piece. As for where, I don't believe a generated structure stores which piece is in which part of the structure, just that the current area is a structure. This would mean that Corridor1 and Crossing would both just appear as Fortress instead of what their piece types are. It's seems unnecessary to need to store that information once generated.

If this is for a new dimension or biome, then you can just look on the internet for the breakdown of the JSON file or the source for how the codec is properly formatted. If you're talking about for pre-existing biomes, you would need to use BiomeLoadingEvent which has a javadoc that explains everything. Please give a more thorough explanation of your request so that we may know what problem you are trying to solve and what steps you have taken to get to the point you're currently stuck at.

You shouldn't need to set the data on the server. Those values are handled via AtomicInteger#incrementAndGet. Therefore, you know that the parts will have the next ids after your entity (e.g. if your main id is 23, then your parts will always be 24 and 25). All you really need to do is just set the entity id itself when you are reading the data with it's specified offset. Nothing needs to be sent to the client. This might be the error you are facing as you could be changing the id when the server already has a set value, but I'm not sure. However, you should try the above and see if it solves your issue.

Glad to know we are helping others correctly then. You came to the wrong place looking for a guide/tutorial. Read the documentation, ask questions, and don't troll and a douche to those who actively try to help people. Feel free to be as rude to me as you want though. I personally don't mind since all you guys want is an answer and you're annoyed we're trying to help you succeed rather than make it easy for ya. Have a wonderful day!

Problematic Code 11. If you would like example implementations, look at the Features class. You will notice that there are some helper methods for placements as there can be multiple assigned to the same feature. Therefore, you can have a placement that handles the amount generate, the spread across the chunk, the height level in the chunk, etc. Do note that their order is important. Second, do not use the above tutorial as a reference. It's outdated and uses terrible practices. It's better to just ask questions and infer from your own knowledge of Java than to follow someone else line by line.

General Issues 3. However, there are times this doesn't work as gradle is spaghetti at times.

I would say read the statements on the different kinds of sides prior to me explaining my reasoning. Even though all logic should be executed on the server side, sometimes it's less computationally heavy to execute the logic on both sides. For example, if your TE changes it's texture based on the amount of liquid it has, you might just want to send a boolean to client saying whether to increase the liquid or decrease it. It more or less depends on what information gets synchronized between the two sides. NBT data on an ItemStack is synchronized to the client when changed, so it should be logically sided within Item#onItemUse. Alternatively, Block#createTileEntity is called on both sides if we want to change how something like a TileEntityRenderer appears based on the stored data on the server. Same thing with entities except their spawning is sent through a packet to keep the same id. So, generally, all logic should be on the logical server unless you want to display something. Then, that information should be synced to the logical client. However, if it's sending a multitude of information every single tick, then the logic should be handled on both sides and synced via some value that switches both of their states. At least, this is my opinion.

Thanks for the compliment. Talking tends to help when I'm trying to convey my reasoning to another person. And yes, I will criticize bad practices or bad design to help point out issues in what could be done better. I even criticize my own videos due to their outdated code and inefficient practices, so I stopped making them. I'm here to help people improve what they are currently doing and not let them keep making the same mistakes. There is a difference between criticizing and back-talking, they're my own opinions and although you don't have to listen to me, quite a number of people share it including those in the Forge team. If you're looking for something that can walk you through without you applying any knowledge for yourself, then sure use the tutorials. However, you most likely will not learn the underlying concept trying to be explained and not be able to adapt your knowledge and think for yourself. I can use an example from TechnoVision's tutorial from his block state episode where they add the methods AbstractBlock#rotate and AbstractBlock#mirror. Anyone watching probably cannot tell me what either of those overrides do and why they should be added. Just adding those methods doesn't teach you anything if you don't know why you need to include them. I want to direct people towards accurate and standardized practices that should be used within Java and the Forge library. If you came here looking for an answer and expecting to put in no work (e.g. copy-paste), then you should really take the time to evaluate what you came here to do. We're here to provide you the tools to succeed and not the final product. Giving them a place where they can discover the answer is more powerful than giving them the answer itself. I've said this many times: the job of a programmer is to be able to adapt to a situation with no prior knowledge of what they will be working with. Asking for help to understand a specific portion of how to use a specific method or field is fine and provides you with insight. However, simply just going "tell me" will not teach you anything. So, to answer your statement, if they only care about the answer, then in my opinion they should choose something else to do. Otherwise, they will ask they same questions over and over again, copy-paste from others, and will fail in the long run.

You should specify the spawning packet as NetworkHooks#getSpawnPacket and use IEntityAdditionalSpawnData to send the ids of each multipart to the client so they may be synchronized.

Then sync the serverside ids to the client for each part.

Please give a better description of the problem. Your code looks fine, not sure about the loot tables though. What blocks are they supposed to break? They should all be at a level of iron tools for their specific tool type.

We've already went over that why it doesn't work. Then you're not saving the information in the TE and/or syncing it to the client on chunk load.

Your thread has already been closed once for talking about MCreator. Please don't open another one.

Yes, you got it.

MCreator is not supported on this forum. Get the files and read the docs. Not the place to ask.

Ah ok. Well then, read up on the IReordingProcessor used (71-80). It basically uses a simple transformation to convert an ITextComponent and renders via the FontRenderer passing in the stored information within the processor. The processor is used for different language support.

It tends to help to look if other threads have asked your question: Or maybe this one which asks a different question but has a working outcome of the problem:

It's called using JSON files now, so the lack of tutorials will persist until someone does something original and creates it. There is no need for a mod here if you plan on replacing one the vanilla dimensions. If you use a tutorial word-by-word, that is how it will be. Always take tutorials with a grain of salt as they usually promote incorrect code, bad practices, or just don't help you learn anything in the process. What? The Forge documentation is the documentation of using the Forge library. Figuring out how to write a JSON file is just as simple as looking on the internet for the file breakdown or looking at the source for the codec information. There is no "official" documentation.

Oh, Kotlin. Haven't seen that here before. That's quite a simple answer, you're checking to display the screen on the logical server instead of the logical client. You need to check if you're on the logical client and not logical server before calling that method. Also, you shouldn't call the method so directly and instead leave it in some sort of object reference as that piece of code cannot guarantee that it will be executed not on a physical server. Isolate your client only code somewhere else and reference via a DistExecutor.

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. This was mentioned in the tutorial, hence why I didn't mention it when I wrote the above statement.

No problem. Here are my reasons for those statements if you're curious: 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. 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. That's fair enough. If you ever need some grammar review or information checks, I'm happy to provide. 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.

All ITextProperties (which TextComponent extend) holds a method called getString which should do this for you iirc. If that doesn't work, you can always use one of the components that return an optional of the specific IStyledTextAcceptor passed in. However, you should look into using IReordingProcessor in some fashion similarly to FontRenderer for support in different languages. Worst case scenario, you get the JSON conversion of the specific text component and parse from there.

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?