[1.11.2] Block metadata questions

[rinart73]

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.

[rinart73]

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.

[rinart73]

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 July 26, 2017 by rinart73

[Jay Avery]

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.

[rinart73]

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 July 26, 2017 by rinart73
found a problem

[Choonster]

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.

[rinart73]

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?

[Choonster]

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.

[rinart73]

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 July 26, 2017 by rinart73

[Choonster]

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.

[Draco18s]

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.

[rinart73]

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 July 27, 2017 by rinart73

[Draco18s]

Use only ModelLoader.SetCustomResourceLocation

This should be called in PreInit or in the ModelRegistryEvent

[rinart73]

2 minutes ago, Draco18s said:

Use only ModelLoader.SetCustomResourceLocation

This should be called in PreInit or in the ModelRegistryEvent

Thanks, that worked.

[rinart73]

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.

[rinart73]

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 July 29, 2017 by rinart73

[Jay Avery]

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?

[rinart73]

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 July 29, 2017 by rinart73

[Jay Avery]

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

Edited July 29, 2017 by Jay Avery

[rinart73]

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.

[jeffryfisher]

4 hours ago, rinart73 said:

the game doesn't call it

Try changing a neighboring block. Is it called then?

[rinart73]

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 July 29, 2017 by rinart73

[rinart73]

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 July 30, 2017 by rinart73

[rinart73]

Bump.

Seriously, I have just one problem left. Anybody?

[jeffryfisher]

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.