ChampionAsh5357

Features are still registered the same way as any other forge registry.

BiomeLoadingEvent for pre-existing biomes and within the JSON itself for new ones. Then just grab the BiomeGenerationSettingsBuilder and call withFeature iirc.

https://mcforge.readthedocs.io/en/latest/conventions/loadstages/ This is either handled through a IRenderTypeBuffer with RenderTypes combined with MatrixStacks or RenderSystem depending on the situation. OpenGL has been isolated as much as possible. Not really afaik, they just have a brain now allowing for more complex AI tasks and behaviors.

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.