Jump to content

[1.11.2] Block metadata questions


rinart73

Recommended Posts

So, if I understand correctly, saying in a more simple way, metadata is just a storage which is used specifically for block variants. So.. dye, block rotation e.t.c.

For more complex data the usual class properties can be used. They just can't be used normally to affect the visual stats of the block in the world. I mean, as I understand, they can, but then you'll need to override drawing for this block or something like that.

 

There is another question then. Is there any good tutorials for 1.11.2? Just simple block metadata that affects block variants. No terrifically big classes that are describing every aspect of the block and has other stuff.

Currently I'm learning using this series of tutorials (good one, actually), but it's for 1.8. I have to edit some thing to get it work. It's not bad actually, the real problem is that in some tutorials (like that one that described metadata) author creates some sort of workaround or something. It probably should make coding easier. But it's not, for me, at least.

 

So, please explain to me. I understand using of Enums I think, but the code that is related to ItemBlock and that stuff. Just.. a bunch of lines. And I had experience with programming before.

Link to comment
Share on other sites

21 minutes ago, diesieben07 said:

global for all occurrences of that block in the world

Thanks for explaining that.

 

As for specific questions, I can't ask. I just need a proper understandable example or tutorial. I can't ask about something if there is nothing I understood yet about this.

Link to comment
Share on other sites

7 minutes ago, diesieben07 said:

Well, I am not even quite sure what you are trying to achieve.

I just need an example of using metadata. Something like in tutorial that I gave link to. Colors or directions + creative tab variants + saving them in item state (or something like that, I can't understand what is the purpose of ItemBlock code in the tutorial)

 

And by the way, I don't understand how complex blocks like furnaces or modded super-crafting tables work. They need to save a lot of info for a specific block, but we only can use 4 bytes.

Ok, I think there is a way to add an Inventory or crating grid to a block, but there are way more stuff that needs to be saved.

Edited by rinart73
Link to comment
Share on other sites

The basics of blockstates and metadata haven't really changed from 1.8 to 1.11.2, so old tutorials should cover the fundamentals well enough. The forge docs are a good place to start if you want to know how something forge-specific works. And the vanilla code itself should also become your best friend - look for blocks which have variants and states that work in the way you want, and see how they are coded. For blocks with more than 16 bits of data, you can use a TileEntity. This is what vanilla uses for furnaces, chests, signs, and other blocks which hold complex information.

Link to comment
Share on other sites

16 minutes ago, Jay Avery said:

The basics of blockstates and metadata haven't really changed from 1.8 to 1.11.2, so old tutorials should cover the fundamentals well enough. The forge docs are a good place to start if you want to know how something forge-specific works. And the vanilla code itself should also become your best friend - look for blocks which have variants and states that work in the way you want, and see how they are coded. For blocks with more than 16 bits of data, you can use a TileEntity. This is what vanilla uses for furnaces, chests, signs, and other blocks which hold complex information.

Thanks.

Unfortunately Forge Docs are not really informative in terms of examples.

It's a shame to admit, but I'm still fighting with ForgeGradle and IntelliJ IDEA to make them show me minecraft sources (not IntelliJ Idea decompiled code). And yes, I used 'setupDecompSpace' (or something like that) so I guess it should provide it.

I'll try to look for info about TileEntity in the future.

 

U.P.D: Found a problem. In 1.8 we can use something like this to register block:

GameRegistry.registerBlock(someBlock = new SomeBlock("block_properties"), ItemBlockMeta.class, "block_properties");

It's hard to explain, just look at the tutorial please. ItemBlockMeta extends ItemBlock and helps to get an item of the block that has metadata.

In 1.11.2, we don't have a way to specify that.

Edited by rinart73
found a problem
Link to comment
Share on other sites

19 minutes ago, rinart73 said:

Thanks.

Unfortunately Forge Docs are not really informative in terms of examples.

It's a shame to admit, but I'm still fighting with ForgeGradle and IntelliJ IDEA to make them show me minecraft sources (not IntelliJ Idea decompiled code). And yes, I used 'setupDecompSpace' (or something like that) so I guess it should provide it.

I'll try to look for info about TileEntity in the future.

 

Did you follow the Getting Started guide in the Forge documentation? It should explain exactly how to set up your ForgeGradle workspace and IDE project.

 

 

19 minutes ago, rinart73 said:

U.P.D: Found a problem. In 1.8 we can use something like this to register block:


GameRegistry.registerBlock(someBlock = new SomeBlock("block_properties"), ItemBlockMeta.class, "block_properties");

It's hard to explain, just look at the tutorial please. ItemBlockMeta extends ItemBlock and helps to get an item of the block that has metadata.

In 1.11.2, we don't have a way to specify that.

 

As of 1.9+, you now register the ItemBlock separately from the Block, like you would any other Item.

 

The Forge documentation explains how to register Blocks, Items and other IForgeRegistryEntry implementations using registry events here.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

4 minutes ago, Choonster said:

 

Did you follow the Getting Started guide in the Forge documentation? It should explain exactly how to set up your ForgeGradle workspace and IDE project.

Yes, I did. Still whenever I'm trying to look at the minecraft code, IntelliJ Idea just decompiles it on it's own.

 

5 minutes ago, Choonster said:

other IForgeRegistryEntry implementations using registry events here.

I read this and actually can't understand, is there only one SubscribeEvent that is related to the blocks/item registering - registerBlocks?

If not, why they're not in the Docs? And what's the difference between doing that stuff in preInit and using SubscribeEvents like registerBlocks?

Link to comment
Share on other sites

3 minutes ago, rinart73 said:

Yes, I did. Still whenever I'm trying to look at the minecraft code, IntelliJ Idea just decompiles it on it's own.

 

When you view a Vanilla or Forge class, does a yellow bar appear at the top of the editor saying "Decompiled .class file, bytecode version X.X (Java X)"? If so, click on the "Choose sources..." link and the Attach Sources window should appear with the directory containing the Forge JAR opened. Select the forgeSrc-<version>-sources.jar (the JAR containing the source code for Minecraft and Forge) in this directory and then click OK.

 

 

7 minutes ago, rinart73 said:

I read this and actually can't understand, is there only one SubscribeEvent that is related to the blocks/item registering - registerBlocks?

If not, why they're not in the Docs? And what's the difference between doing that stuff in preInit and using SubscribeEvents like registerBlocks?

 

The name of the method is irrelevant, what matters is the parameter type.

 

When you create a method annotated with @SubscribeEvent that has a single parameter that extends from net.minecraftforge.fml.common.eventhandler.Event and register the class/instance with the appropriate event bus (e.g. by annotating the class with @Mod.EventBusSubscriber), Forge will automatically call the method whenever that event is fired. The documentation explains events properly here.

 

RegistryEvent.Register<T> is fired once for each registry when that registry is ready to receive registrations. The type argument is the registry's type.

 

Subscribe to RegistryEvent.Register<Block> to register your Blocks, subscribe to RegistryEvent.Register<Item> to register your Items, etc.

 

 

Registering in preInit is the old way to do things, the registry events were introduced so modders can register their registry entries (Blocks, Items, etc.) at the correct point in the loading process without worrying about when that is. For example, RegistryEvent.Register is fired for most registries directly before preInit (in 1.10.2-1.11.2) or directly after preInit (1.12+); but in 1.12 it's fired for the recipe registry slightly later. Eventually, it's planned for recipes to be loaded at server start, so RegistryEvent.Register<IRecipe> will be fired then instead of between preInit and init.

  • Like 1

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

21 minutes ago, Choonster said:

Registering in preInit is the old way to do things, the registry events were introduced so modders can register their registry entries (Blocks, Items, etc.) at the correct point in the loading process without worrying about when that is. For example, RegistryEvent.Register is fired for most registries directly before preInit (in 1.10.2-1.11.2) or directly after preInit (1.12+); but in 1.12 it's fired for the recipe registry slightly later. Eventually, it's planned for recipes to be loaded at server start, so RegistryEvent.Register<IRecipe> will be fired then instead of between preInit and init.

Does it breaks/can break anything if I register most of the stuff in preInit? Because it's much more comfortable then just splitting everything into SubscribeEvents.

Edited by rinart73
Link to comment
Share on other sites

6 minutes ago, rinart73 said:

Does it breaks/can break anything if I register most of the stuff in preInit? Because it's much more comfortable then just splitting everything into SubscribeEvents.

 

It will work in 1.11.2 and probably in 1.12, but it may not work in future versions. Registry events are the recommended way to register things.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

6 hours ago, Jay Avery said:

For blocks with more than 16 bits of data, you can use a TileEntity. This is what vanilla uses for furnaces, chests, signs, and other blocks which hold complex information.

16 states. 4 bits.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

Well, I adapted 1.8 tutorial for blockstates and it kinda works. But as for the item part of the block - it's just purple block in player hands - for any state. And when I tried to use "ModelBakery.registerItemVariants", it's got even worse. Now it's flying in front of player and has text with the name of the block variant. I'm following tutorial, I have JSON models for every state in the "models/block" and "models/item" directories.

 

I'm going to ask for a tutorial again, because nor current tutorial, nor game code (which is actually different from what I see in the tutorials in the internet - for example it lack the using of ModelBakery.registerItemVariants and that stuff for blocks like carpets) helps me.

Edited by rinart73
Link to comment
Share on other sites

Use only ModelLoader.SetCustomResourceLocation

This should be called in PreInit or in the ModelRegistryEvent

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

Is there any way to have block with blockstates, but have it as ItemBlock in only one blockstate?

I mean, for example, I have a block that changes it's blockstate depending on the surrounding area. So it has 2 states: default blockstate and a blockstate when certain conditions are met.

But I want to have only default blockstate as an ItemBlock.

 

What do I need to change? Don't register ItemBlock for meta-s other than 0 in mesher? Or don't register other blockstates in ModelLoader? Or what?

When I'm trying to change anything, everything just breaks and I say hi to purple textures.

Link to comment
Share on other sites

Nevermind, it was my mistake.

 

I have other question now:

Tutorial says:

"If we want our block to have a property that is set not by metadata but by the surrounding blocks or other values, we have to override getActualState."

@Override
public IBlockState getActualState(IBlockState state, IBlockAccess worldIn, BlockPos pos) {
    return super.getActualState(state, worldIn, pos);
}

"This method allows us to modify the state which was calculated using the metadata. The calculated state is passed in as the argument "state". We can use .withProperty on this field to modify or add certain properties. For instance, we could add the property "sky" which is a boolean and true if the block has no other block above it."

@Override
public IBlockState getActualState(IBlockState state, IBlockAccess worldIn, BlockPos pos) {
    return state.withProperty(SKY, ((World)worldIn).canBlockSeeSky(pos));
}

 

So, if the block can see sky, it should have property SKY set to true. The thing is that it doesn't works. It seems that the game doesn't call getActuallState at all.

If I'll move this code to the updateTick() event and will enable randomTicks, it works fine.

But in the getActuallState it doesn't

Edited by rinart73
Link to comment
Share on other sites

16 minutes ago, Jay Avery said:

How do you know the property isn't being set to true? Where are you checking this? Have you tried setting a breakpoint in the method to check whether it gets called?

I know that it's not set to true because if it will be set to true, I will see the other blockstate of the block, which has other texture.

Also, I tried to log the value of 

((World)worldIn).canBlockSeeSky(pos)

every time this method is called. And it's not called during the game.

 

So I'm expecting block to change it's appearance according to if it's exposed to sky or not and it just doesn't change it, becuase this method isn't called by the game.

Edited by rinart73
Link to comment
Share on other sites

14 minutes ago, Jay Avery said:

What happens when you set a breakpoint at the method, does it get hit? Are you using the @Override annotation?

Nothing happens, breakpoint is not hit. As I said, the game doesn't call it. Yes, I'm using Override annotation.

Link to comment
Share on other sites

4 hours ago, rinart73 said:

the game doesn't call it

Try changing a neighboring block. Is it called then?

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

34 minutes ago, jeffryfisher said:

Try changing a neighboring block. Is it called then?

No.

And the thing is:

If I'll remove

this.setDefaultState(this.blockState.getBaseState().withProperty(SKY, false));

from the constructor, getActualState will be called by game. And the value can be false or true, but the block will ALWAYS look like the blockstate is always "true" for it. Also, there will be an ItemBlock with purple texture in CreativeTab. And it shouldn't be there.

 

If I'll keep this line. There is only ItemBlock with metadata 0 (how it was intended to) and getActualState won't ever be called by the game.

 

At this moment I just don't know why and how.

Edited by rinart73
Link to comment
Share on other sites

UPD: I managed to get the game to call getActualState. Have no idea how. There is only one problem left.

 

When I break blocks that don't see sky, they emit "no-sky" (dark) particles. And when I break blocks that're seeing sky, they emit "sees-sky" (white) particles. The only problem is that block that see sky are still having dark texture, that is weird.

 

UPD: Ok, as I understand, there is no built-in system that detects that the game should re-render block that changed it's blockstate? I tried to push block with piston and it changed color. So in order to change just the model of block, I should trigger a full block update. It doesn't seem to be performance-wise thing.

 

But since everybody's code works as intended (block model updates instantly) and mine is not, here is the code of my block's class.

https://pastebin.com/pqracKUs

Edited by rinart73
Link to comment
Share on other sites

On 7/29/2017 at 10:12 AM, rinart73 said:

getActualState won't ever be called by the game.

It's time to set breakpoints in related methods and then step through the breaking of your block in the test case that baffles you.

The debugger is a powerful and necessary tool in any IDE, so learn how to use it. You'll be able to tell us more and get better help here if you investigate your runtime problems in the debugger before posting.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.