[1.15.2] Override vanilla block and/or properties

[Asleep365]

How would I override vanilla block properties? For example, decrease obsidian blast resistance, make cobble a falling block, make wool inflammable, etc. Blocks.OBSIDIAN etc are final values and cannot be directly modified.

 

Also is it possible to modify wool and other colored block properties without manually entering each wool color in an array and parsing through etc?

[Luis_ST]

3 hours ago, Asleep365 said:

How would I override vanilla block properties?

you have to create a normal block but you have to register it with the minecraft id

public static final DeferredRegister<Item> VANILLA_ITEMS = DeferredRegister.create(ForgeRegistries.ITEMS, Minecraft_Id);

public static final RegistryObject<Item> SUGAR = VANILLA_ITEMS.register("sugar", Sugar::new);


package net.luis.cave.items.vanilla;

import net.minecraft.item.Food;
import net.minecraft.item.Item;
import net.minecraft.item.ItemGroup;
import net.minecraft.potion.EffectInstance;
import net.minecraft.potion.Effects;

public class Sugar extends Item {

	@SuppressWarnings("deprecation")
	public Sugar() {
		
		super(new Item.Properties()
				.group(ItemGroup.FOOD)
				.food(new Food.Builder()
						.hunger(2)
						.saturation(1.0f)
						.effect(new EffectInstance(Effects.SPEED, 300, 3), 1)
						.setAlwaysEdible()
						.build()));
	}

}

 

this is my overwriting of sugar, but it works also with blocks (you have to change ForgeRegistries)

[Asleep365]

I haven't been able to get this to work. A sample of my code is below:

 

public static final DeferredRegister<Block> VANILLA_BLOCKS = new DeferredRegister(ForgeRegistries.BLOCKS, "minecraft");

//Overwrite vanilla items
public static final RegistryObject<Block> DIRT = registerVanillaBuildingBlockWithDefaultItem(
        "dirt",
        () -> new NewDirtBlock());

public static final RegistryObject<Block> DIRTTEST = registerBlockWithDefaultItem(
        "dirttest",
        () -> new NewDirtBlock());

public static <T extends Block> RegistryObject<T> registerBlockWithDefaultItem(String name, Supplier<? extends T>blockSupplier)
{
    RegistryObject<T> block = BLOCKS.register(name, blockSupplier);
    ModItems.ITEMS.register(name, () -> new BlockItem(block.get(), new Item.Properties().group(ModItems.solidarityGroup)));
    return block;
}

public static <T extends Block> RegistryObject<T> registerVanillaBuildingBlockWithDefaultItem(String name, Supplier<? extends T>blockSupplier)
{
    RegistryObject<T> block = VANILLA_BLOCKS.register(name, blockSupplier);
    ModItems.VANILLA_ITEMS.register(name, () -> new BlockItem(block.get(), new Item.Properties().group(ItemGroup.BUILDING_BLOCKS)));
    return block;
}

 

NewDirtBlock():

public class NewDirtBlock extends FallingBlock {
    private final BlockState solidifiedState;

    public NewDirtBlock() {
        super(Block.Properties.create(Material.EARTH, MaterialColor.DIRT).hardnessAndResistance(0.5F).sound(SoundType.GROUND));
        this.solidifiedState = ModBlocks.MUD.get().getDefaultState();
    }
    ...
}

 

ModItems.VANILLA_ITEMS:

public static final DeferredRegister<Item> VANILLA_ITEMS = new DeferredRegister(ForgeRegistries.ITEMS, "minecraft");

 

When registered under "dirttest", the properties all function as intended. However, when registered under "minecraft:dirt" it only seems to have vanilla dirt properties (doesn't fall, convert to mud etc). What is wrong with the above code?

[Luis_ST]

7 hours ago, Asleep365 said:

When registered under "dirttest", the properties all function as intended. However, when registered under "minecraft:dirt" it only seems to have vanilla dirt properties (doesn't fall, convert to mud etc). What is wrong with the above code?

first my code example is from 1.16 but I think it works also in 1.15.2.

your code looks okay, unfortunately I can't tell you where the error is.

but i have an idea where the mistake is,

can you show your mod class constructor.

[Asleep365]

@Mod(Solidarity.MOD_ID)
public class Solidarity
{
    public static final String MOD_ID = "solidarity";

    private static final Logger LOGGER = LogManager.getLogger();

    public static IEventBus MOD_EVENT_BUS;

    public Solidarity() {
        MinecraftForge.EVENT_BUS.register(this);

        MOD_EVENT_BUS = FMLJavaModLoadingContext.get().getModEventBus();

        ModBlocks.BLOCKS.register(MOD_EVENT_BUS);
        ModItems.ITEMS.register(MOD_EVENT_BUS);
        ModTileEntities.TILE_ENTITY_TYPES.register(MOD_EVENT_BUS);
        ModContainers.CONTAINERS.register(MOD_EVENT_BUS);
        ModRecipeSerializers.RECIPE_SERIALIZERS.register(MOD_EVENT_BUS);

        DistExecutor.runWhenOn(Dist.CLIENT, () -> Solidarity::registerClientOnlyEvents);
    }

 

Removed comments to conserve space. Have a feeling you're probably right, I don't have a ModBlocks.VANILLA_BLOCKS etc. I'm guessing it'll need a different MOD_EVENT_BUS?

[Luis_ST]

10 hours ago, Asleep365 said:

Removed comments to conserve space. Have a feeling you're probably right, I don't have a ModBlocks.VANILLA_BLOCKS etc. I'm guessing it'll need a different MOD_EVENT_BUS?

you can use the normal one

[Asleep365]

It seems like replacing vanilla blocks causes the world generation to bug out. The world generation occurs like normal except all the dirt is invisible, solid, but cannot be punched. Lighting updates proceed as if they weren't there. Placing a block where there should be dirt has a no-texture block, F3 says it's "minecraft:air".

 

Strangely, it works fine in super-flat worlds, so I might have to overwrite the dirt generation to also to use the custom dirt.

 

EDIT: Leaving the area and coming back causes all glitched blocks to be replaced with normal, "real" air, no lighting glitches like above

EDIT2: NVM that was just my night vision potion, lighting still glitched, but not solid anymore

Edited February 14, 2021 by Asleep365

[Luis_ST]

10 hours ago, Asleep365 said:

I might have to overwrite the dirt generation to also to use the custom dirt.

I think yes, but I have no idea how you do it exactly.

what you can try is to creat a ore generate and use vanilla dirt as a filler block

 

Edit: what is also possible is to create a dirt block that extends the vanilla dirt (does not overwrite). which has your desired properties, and then generate them in the world instead of vanilla dirt

Edited February 15, 2021 by Luis_ST

[Asleep365]

From research it might be possible to replace the dirt after generation when loading new chunks. Something like this maybe: 

 

 

 

My problem however is a bit more complicated. In addition to changing the vanilla dirt properties, I also have "dirt ores" that replace dirt. If the vanilla dirt generation occurs in the RAW_GENERATION stage, and the "dirt ores" generate in the UNDERGROUND_ORE phase, there isn't much extra room to replace vanilla dirt with the custom dirt.

[Asleep365]

Okay, I got my replacement function working "correctly", in the sense that I can replace a block with another on world generation, using something similar to the one I linked. The problem now is that neither replacing Blocks.AIR or Blocks.DIRT replace the missing, glitched blocks. I'll try some functions to identify the "block type" of one of the glitched blocks

 

EDIT: System.out.println() says the block is "Block{minecraft:dirt}", but equality (==) comparisons of the block to Blocks.DIRT, ModBlocks.DIRT.get(), and Blocks.AIR all return false. Have no idea what the block really is

Edited February 16, 2021 by Asleep365

[Luis_ST]

9 hours ago, Asleep365 said:

Okay, I got my replacement function working "correctly", in the sense that I can replace a block with another on world generation, using something similar to the one I linked. The problem now is that neither replacing Blocks.AIR or Blocks.DIRT replace the missing, glitched blocks. I'll try some functions to identify the "block type" of one of the glitched blocks

I think the problem is you want to replace the minecraft dirt with itself I think the best and the most uncomplicated

would be you register the dirt with your mod id and then try to replace it again

I'm not sure because I'm not very familiar with ore generating, but I think minecraft checks whether the block is dirt instance of DirtBlock, which is not the case with you

[Asleep365]

The problem with having a separate block is that when grass dies, hoe'd dirt is trampled, and any modded recipes or interactions etc I need it to turn into the custom dirt. Even if I were to change every dirt related block I can't change the recipes in other mods.

 

Note that grass and other dirt variants not being replaced is intended behavior. I just need to find what the glitched blocks are an instance of, or be able to extract some unique property that only exists in minecraft:dirt

Edited February 16, 2021 by Asleep365

[Luis_ST]

7 hours ago, Asleep365 said:

Note that grass and other dirt variants not being replaced is intended behavior. I just need to find what the glitched blocks are an instance of, or be able to extract some unique property that only exists in minecraft:dirt

try minecraft:cave_air or minecraft:void

 

Edit: what is also possible is you overwrite the vanilla dirt block (the blockitem) so that every time you place vanilla dirt.

your dirt will be placed and every time you break down your dirt block it will drop vanilla dirt.

Edited February 16, 2021 by Luis_ST

[Asleep365]

I don't think cave_air would be practical since it would fill in all the caves with dirt. I could try void, but since I'm also planning on replacing cobblestone it wouldn't be a long term solution even if it worked.

 

Part of my reasoning for the falling dirt is 1. an additional environmental hazard, 2. being a fundamentally different material for construction. Replacing the item alone would only solve number 2.

 

Falling cobble is similar, biggest thing I need to worry about is the roofs of plains village temples and jungle temples.

 

If the System.out.println(block) or blockstate thinks it's dirt, there has to be some way to check in code whether it is dirt.

 

EDIT: Thought of an idea, if System.out.println() identifies correctly, what if I just use block.toString() and compare that to Block{minecraft:dirt}? Probably not the best solution, but it might work

Edited February 16, 2021 by Asleep365

[Asleep365]

Using string.equals() comparison works, as long as it occurs after all dirt is successfully generated. Will need a few modifications to instead generate mud in rivers and oceans, but for the most part doesn't have significant issues. I'll probably need to update Seagrass, and sugarcane to grow on mud also as mud doesn't have a solid topside. Going to leave kelp out since kelp attaches to rocks, and doesn't have roots.

 

Unfortunately I can't find any documentation on worldgen stages. I need a stage to generate the dirt that still has another stage after it to generate dirt ores. Should occur after UNDERGROUND_STRUCTURES preferably to ensure mineshafts generate correctly. Preferably not VEGETAL_DECORATIONS as that seems to prevent the spawning of seagrass and other plants. The generation stages are: VEGETAL_DECORATION, UNDERGROUND_DECORATION, UNDERGROUND_ORES, RAW_GENERATION, LOCAL_MODIFICATIONS, SURFACE_STRUCTURES, TOP_LAYER_MODIFICATIONS, UNDERGROUND_STRUCTURES. Setting it in RAW_GENERATION still results in some bugged blocks (presumably dirt generated after RAW_GENERATION). VEGETAL_DECORATION results in plants etc that would be generated on dirt don't generate.

 

Simplest solution would be if I could make a custom worldgen stage post-generation to replace all dirt, cobble, seagrass, sugarcane, and whatever else I may need (coral etc). After that, another worldgen stage to replace some dirt with dirt ores. If this is possible with a custom world type that would be acceptable as well.

 

EDIT: Plants actually generate correctly. Should potentially be fairly straight forward then, just need to make sure I don't miss any stages of generation

Edited February 17, 2021 by Asleep365

[Luis_ST]

7 hours ago, Asleep365 said:

I'll probably need to update Seagrass, and sugarcane to grow on mud

I'm not sure, but I think that is also possible with the tag forge:dirt

 

7 hours ago, Asleep365 said:

Unfortunately I can't find any documentation on worldgen stages.

I am unfortunately not familiar with that. Sorry I can't help you any further

 

if you need help with the world generation have a look in the forum or create a new topic