jabelar

There is a chunkExists() method in the ChunkProvider class. So world.getChunkProvider().chunkExists(chunkX, chunkY) looks promising..

Well the Chunk class has an isLoaded() method. So what about world.getChunkFromChunkCoords(chunkX, chunkY).isLoaded()?

There are two events, ClientChatEvent and ClientChatReceivedEvent. i think the first one, if you handle it can do what you want -- give you a chance to process the message before being sent.

Minecraft is using normal Java, so just Google search for information on Java file functions. All of those are available to you.

Wait, what do you mean by not working? The event fires for every living entity attack, but you should be able to check if the entity was a player. Are you saying it doesn't work because it doesn't fire, or are you saying that you didn't like how it was firing for all entities?

I don't think the fillWithLoot(null) is really the right thing to do there. Vanilla generation just does the code I said -- sets the loot table. I think the fill with loot would happen later (probably when player actually opens the chest).

Wait, it should be pretty easy. This is your own custom structure, right. So you're the one that places the chest block. The StructureComponent class has a generateChest() method that takes in a loot table parameter. Or you can simply force the placement with something like: worldIn.setBlockState(blockpos2, Blocks.CHEST.correctFacing(worldIn, blockpos, Blocks.CHEST.getDefaultState()), 2); TileEntity tileentity1 = worldIn.getTileEntity(blockpos); if (tileentity1 instanceof TileEntityChest) { ((TileEntityChest)tileentity1).setLootTable(LootTableList.CHESTS_SIMPLE_DUNGEON, rand.nextLong()); } Of course you would adjust the loot to suit your needs.

Glad you solved it! The cascading world gen problem is one of those that requires specific knowledge of how Minecraft works and the idea of offsetting by 8 isn't obvious until you encounter it.

If you don't see anything in the log, it means your print statement isn't getting executed, which means the code where the print statement is is also not getting executed. Depending on where you put your print statement that would be a big problem. You need to put a print statement in every one of your methods and see if any of them get printed out. If they don't, or depending on which ones don't, you can track things down. The most important thing for you to do is to trace the execution and understand what it is actually doing. Print statements are good for that, but you can also use debug mode with breakpoints in Eclipse and step through the code. You need to check which parts of your code are being generated, and what it is trying to generate. If you are able to observe this, the problem (and solution) should become obvious.

Okay, makes sense.

JRedFox was agreeing with you. I'm not sure why you said WTF. You said use bit shifting and he said "okay I'll use bit shifting" then you said "WTF".

I agree. While I think his approach to invent a new format is unnecessary and therefore unadvised, there is nothing "dangerous" about what he's doing and it is his "loss" if he wants to face the extra effort and bugs. In case he or other people encounter this thread in the future, the general answer to "what is complete list of all saved block properties" is what both MamiyaOtaru and I said -- you have to do your own iteration through all the getMetaFromState() methods because the properties that are saved are hard-coded. There is no simple field in the property and no master map.

Not really, although up to you to navigate potential legal concerns. My (totally non lawyer opinion) is that Mojang actually supports modding for the most part, they won't care unless you actually make a lot of money or they actually suffer significant money loss that they feel is owed, and lastly copyright does allow for copying portions for new creative purposes (like remixing, comedy, etc.) as well as for educational purposes, and lastly in programming there are a lot of things that are not really copyrightable since they are standard practice -- like a for loop that iterates through a bunch of block locations. The part to be more careful about is the artistic assets (textures and sounds). They are more clearly copyrighted so re-distributing them as is could be a problem (although still there is provision for new creative purpose, comedy, educational purposes) so best is to not re-distribute but simply point to the existing assets if you want to use them. If you're really concerned about it, then don't copy directly but use their code as a general guide for what needs to be done. Note you can also call their code and that isn't copyright violation. Like if they have a method in their generator that you want to use you can just call it (use reflection if you have to if it is not public scope).

@Captain_Chaos We totally understand the context of your question. But you're not understanding our reservations in giving an answer. Firstly, the problem is that the decision on what properties gets converted to meta (and thus saved) is hard-coded in the source for each block in the getStateFromMeta() and the getMetaFromState() methods. I suppose someone somewhere might have generated a complete table but I haven't seen it. If you really wanted this, I think you'd have to do the following: Iterate through the registry to get all registered blocks. Take a block state instance and loop through all the valid values of all the valid properties. I'm not sure the exact methods, but I've seen them before and you seem good enough with coding to track these down. Print out the block and property values along with the getMetaFromState(). Identity duplicate meta values and infer that the property that changes does not affect meta there is not saved. I hope you understand what I mean. Basically you need to do a brute force dump because there isn't a simple mapping. That can give you the full list for the actually saved possible combinations for the current version. But the next problem is that there isn't necessarily a one-to-one or even a "closed form" (like a simple table) mapping between any two Minecraft versions. As an example, fences which currently use transient states for connecting visually are apparently moving to saved block states (or maybe even separate blocks) with the 1.13 flattening. So personally, I would rely on the Minecraft world save converter code (once available) as the definitive approach to converting. Presumably they will think through all the conversions and special cases.

It depends on how far you want to go with it. But basically you're creating your own custom world type and that would come along with everything else that a custom dimension might have, including custom chunk provider. Certainly you can copy most of the code from vanilla where it makes sense. But if you're really trying to do the "buffet" style you need to be able to do things like set the biome, control the noise generators and such.

Yeah, I'll need to look at that. Looks like the generic angle brackets are confusing it. Thanks for pointing it out.

Are you specifically want to avoid .lang or do you really mean you want to have the names to be dynamic? Like giving the players some sort of title based on status or something? Also, are you talking about player names or other types of names? For players there is a name format event you can handle where you can modify the name. Even there, if you're making dynamic names you should get the text from a .lang file since that is super easy and provides the proper and most compatible way of modifying text.

First of all, your assumption that vanilla block ids don't change is wrong. As mentioned above you need converters (and those come built-in) from older versions to newer versions. If you are worried about having your mod's users sharing older painted world files you can just run the same conversion code or copy it as a feature in your mod. Within a version, you should use registry name as the unique, guaranteed-to-work key for each block, both vanilla and modded. An important thing with any save / asset format is to have a versioning system. If you include the version of Minecraft used during the initial painting in your save file then it should be easy to key off that when your mod loads it. Alternatively, you can save the results as a normal world save and it will all just work out on its own. Do you really need your own file format?

You can replace any GUI you want by handling the GUI open event and opening your own instead. So you can make a class that extends the new chat GUI but with the modifications you want and open that instead.

Where exactly are you seeing these errors? When I look at it in my browser the code doesn't have the encoding issues you're showing, plus I have all the imports in the code so you shouldn't have to guess at any class.

Cool!

While you can create complex trigger criteria using the JSON, I found it easier to create the criteria in code and cause a simple trigger. To me this is more flexible and bypasses a lot of the hassle of JSON. If you're interested you can look at my tutorial: http://jabelarminecraft.blogspot.com/p/minecraft-modding-advancements.html

You didn't read my suggestions closely enough. Writing NBT is only really for server side and there is no syncing for that. You need to look at the TileEntity getUpdatePacket() and onDataPacket(). Some other methods that might be useful are getUpdateTag(), getTileData().

There are a number of classes such as the JsonToNBT, the CompressedStreamTools, and even methods in the NBTBase class that deal with various approaches to serialization of NBT. I haven't used them myself, but I assume they are close to what you're looking for. Just check out how they are used in vanilla.

What happens if you comment out the line where you place the block?