[1.10.2] Redstone-triggered particles

[Zane49er]

I am trying to make a mod with rifts, which are vaguely like Thaumcraft's aura nodes. One block which will interact with the rifts is a destabilizer, which will allow multiblock-like crafting. This block should draw a sphere of particles above itself when powered, but when it is unpowered, just a tiny ball at the center, and drop some items, depending on the area around it. Currently, I am testing this with the fire particle when unpowered. Any code that is commented out I have tried both with and without in every combination. No particles are displayed.

 

package zane49er.VolkiharEchoes.features;

import java.util.Random;

import net.minecraft.block.Block;
import net.minecraft.block.material.Material;
import net.minecraft.block.state.IBlockState;
import net.minecraft.util.EnumFacing;
import net.minecraft.util.EnumParticleTypes;
import net.minecraft.util.math.BlockPos;
import net.minecraft.world.IBlockAccess;
import net.minecraft.world.World;
import net.minecraftforge.fml.relauncher.Side;
import net.minecraftforge.fml.relauncher.SideOnly;

public class Destabilizer extends Block {

	public Destabilizer(String registryName) {
		super(Material.PISTON);
		setRegistryName(registryName);
		setUnlocalizedName(getRegistryName().toString());
		setHardness(3.0f);
	}

	//@Override
	@SideOnly(Side.CLIENT)
	public void updateTick(World worldIn, BlockPos pos, IBlockState state, Random rand) {
		//if(!worldIn.isBlockPowered(pos)){
			worldIn.spawnParticle(EnumParticleTypes.FLAME, (double)pos.getX(), (double)pos.getY()+5, (double)pos.getZ(), 0, 0, 0, new int[0]);
		//}
	}
	
	//@Override
	@SideOnly(Side.CLIENT)
	public void randomDisplayTick(IBlockState stateIn, World worldIn, BlockPos pos, Random rand) {
		//if(!worldIn.isBlockPowered(pos)){
			worldIn.spawnParticle(EnumParticleTypes.FLAME, (double)pos.getX(), (double)pos.getY()+5, (double)pos.getZ(), 0, 0, 0, new int[0]);
		//}
	}
	
}

It seems that the randomDisplayTick is never being called.

 

Also, I want to make the (fullbright) rifts change color based on their contents, but that's a future problem...

 

Finally, creative tabs are not being created, and I don't understand why.

Edited August 1, 2017 by Zane49er

[Choonster]

Are you definitely registering an instance of this class?

 

Post your registration code and the class that calls it. Also post the code where you create your creative tabs.

[Zane49er]

package zane49er.VolkiharEchoes.init;

import net.minecraft.block.Block;
import net.minecraft.client.renderer.block.model.ModelResourceLocation;
import net.minecraft.item.Item;
import net.minecraft.item.ItemBlock;
import net.minecraft.util.ResourceLocation;
import net.minecraftforge.client.model.ModelLoader;
import net.minecraftforge.fml.common.registry.GameRegistry;
import zane49er.VolkiharEchoes.features.Destabilizer;
import zane49er.VolkiharEchoes.features.Rift;
import zane49er.VolkiharEchoes.features.Stabilizer;
import zane49er.VolkiharEchoes.main.References;

public class ModBlocks {
	
	public static Block destabilizer;
	
	public static void init() {
		destabilizer = new Destabilizer("destabilizer");
	}

	public static void register() {
		registerBlock(destabilizer);
	}
	
	private static void registerBlock(Block block) {
		GameRegistry.register(block);
		ItemBlock item = new ItemBlock (block);
		item.setRegistryName(block.getRegistryName());
		GameRegistry.register(item);
	}

	public static void registerRenders() {
		registerRender(destabilizer);
	}
	
	public static void registerRender(Block block) {
		//Minecraft.getMinecraft().getRenderItem().getItemModelMesher().register(item, 0, new ModelResourceLocation(References.MODID + ":" + item.getUnlocalizedName().substring(5),"inventory"));
		//ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(new ResourceLocation(References.MODID, block.getUnlocalizedName().substring(5)), "inventory"));
		ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory"));
	}

}

Unless I have to initialize the updatetick separately, I don't know how I could mess that up. The block Is working fine, it just won't make particles. I also recently tried literally copy + pasting the code from torches, still no result.

 

package zane49er.VolkiharEchoes.features;

import net.minecraft.creativetab.CreativeTabs;
import net.minecraft.item.Item;
import zane49er.VolkiharEchoes.init.ModItems;

public class ModTabUseful extends CreativeTabs{

	public ModTabUseful(String name) {
		super("TabUseful");
	}
	
	@Override
	public Item getTabIconItem() {
		return ModItems.riftReader;
	}

}


package zane49er.VolkiharEchoes.init;

import net.minecraft.block.Block;
import net.minecraft.creativetab.CreativeTabs;
import zane49er.VolkiharEchoes.features.ModTabUseful;

public class ModTabs {
	
	public static CreativeTabs useful;

	public static void init() {
		useful = new ModTabUseful("TabUseful");
	}
}

This one has been giving me trouble since 1.7.

[Choonster]

I'm not seeing any obvious issues that would stop the particles from working. Create a Git repository for your mod, push it to a site like GitHub (if you haven't already) and link it here; I'll need to debug this locally to locate the issue.

 

I did notice that you have model registration code in a common class, which has the potential to crash the dedicated server. Model registration should be done in a dedicated client-only class.

 

I also recommend moving your Block/Item registration to the corresponding registry events and your model registration to ModelRegistryEvent. This will make it easier to update to 1.12+, where GameRegistry.register is private.

[Zane49er]

https://github.com/zane49er2/Volkihar-for-MineCraft-Mod

 

Sorry this is so confusing on GitHub, this project folder includes previous versions so that I can pull models, textures, or planning from them,

[Choonster]

The root of your repository should be the root directory of your mod, i.e. where build.gradle is. The repository should include the buildscript (build.gradle and gradle.properties [if you have it]), the Gradle Wrapper (gradlew, gradlew.bat and the gradle directory) and your source code/resources (the src directory).

 

Look at my mod and its .gitignore file  for an example of the repository structure to use and which files to include.

[Zane49er]

https://github.com/zane49er2/VMC

Thanks, I've (probably obviously) never actually used git repositories. The new one still has the confusion, but maybe less.

[Choonster]

The creative tab and particles are working on my machine:

 

 

[Zane49er]

It's good to know that the problems I've been having in 1.10 aren't caused by my incompetence, but I don't understand what could be wrong here... Could settings in eclipse prevent things from working that aren't being carried over in the git? If I can't get it to work by messing with build paths and project directory by tomorrow I'll try just downloading my own mod.

 

edit: that was it! after resetting the build path, everything is working, and I feel like I can actually start to get things done. Also, I think I've gotten suggestions from you 3 times to change my registry method, which I thought I did... I'll try again, though.

Edited August 2, 2017 by Zane49er

[Zane49er]

Now I can see the particles, but I still don't know how to control them. this is one of the few blocks my mod will add that I don't want to have NBT or Blockdata, so I'd like to not use that, but using normal values doesn't seem to work. this may have to do with server and client. I also tried using the logic directly in the statement, which still didn't work.
 

Spoiler

 

 

Edited August 2, 2017 by Zane49er

[Zane49er]

I just tested the sphere effect, and it seems the size Is limited. I could render a radius of 1 or 2 blocks, but any higher than that and no particles are displayed. Edit: that was me being dumb and calculating a sphere twice, and only once dynamically. Now it works.

Also, I've changed my mind about the NBT, I'll use it since there are 4 planned sizes, times 2 states is 8, times 2 possible power sources (different color fluid) is 16.

Edited August 3, 2017 by Zane49er

[Zane49er]

 I've tried adding a GUI, and attaching it to the tome. Nothing happens on a right-click Edit: the game crashes if the server tries running it, else nothing happens. I feel like this is becoming less "I have a problem, what do I do?" and more "are these even real problems?" Oh well, I still have questions at least. Also, the original purpose of this post (Redstone) is still not finished.

Edited August 3, 2017 by Zane49er

[Choonster]

I think you'll need to store the powered state in the block state or the TileEntity and use that on the client instead of using World#isBlockPowered directly. Look at BlockRedstoneLight for an example of this (though it unnecessarily uses two Blocks instead of a property).

[Zane49er]

 Is there a way to make the particles spawn even when the player is slightly far away? I don't necesarilly need them when the nearest player is 50+ blocks away, but the point of it is that it outlines an area... I'd like them to render about 20 blocks away.

[Choonster]

10 minutes ago, Zane49er said:

 Is there a way to make the particles spawn even when the player is slightly far away? I don't necesarilly need them when the nearest player is 50+ blocks away, but the point of it is that it outlines an area... I'd like them to render about 20 blocks away.

 

Since particles only need to be spawned on the client, just check how far away the client player is from the block before spawning them.

[Zane49er]

Currently they immediately stop spawning at a certain distance from the block. I've already made the render not distance related, but the issue is spawning, I think RandomDisplayTick is the problem, but I think the only alternative is making it a TileEntity, which, as I said, are becoming an invasive element of almost everything I'm planning.

[Choonster]

13 minutes ago, Zane49er said:

Currently they immediately stop spawning at a certain distance from the block. I've already made the render not distance related, but the issue is spawning, I think RandomDisplayTick is the problem, but I think the only alternative is making it a TileEntity, which, as I said, are becoming an invasive element of almost everything I'm planning.

 

If you're spawning particles through the World/RenderGlobal methods, they'll only spawn within 32 blocks (exclusive) of the player unless you tell it to ignore the range (by using a vanilla particle type that ignores range or by calling one of the overloads with an ignoreRange parameter).

 

Block#randomDisplayTick will only be called for blocks that are within 32 blocks (exclusive) of the client player on every axis.

[Zane49er]

2 hours ago, Choonster said:

Block#randomDisplayTick will only be called for blocks that are within 32 blocks (exclusive) of the client player on every axis.

This is what I meant - I had already set the particles to not be distance-related, but the method is called at varying rates as the player moves further away. I found that standing 20 blocks away for a minute will eventually show the sphere, but it fades again and you have to wait. I don't know of any other client-side method that occasionally gets run for every block, so I might have to use another TileEntity?

 

The gold are 5 blocks apart.

[Choonster]

A ticking TileEntity or a TileEntity with a TESR are probably your best options here.

[Zane49er]

Alright, I think adding a tileEntity will solve all my problems with the destabilizer. I still have a problem with the GUI, and saving my new rift NBT.

The color (eventually it'll be the essences that determine color) is randomly generated, but should, for obvious reasons, only be generated once.

Instead, It seems to be determined twice, once when it is placed/generated, and one when it is loaded. This means that the first time you see one, it won't be accurate, but if you relog, no matter how many times, it will be.

Spoiler

Screenshot before relogs

Screenshot after 1 relog

Screenshot after a 2nd relog

edit: I'll prob. move this to another thread, since it is a separate and helpful topic to understand. I think the client isn't being updated about the blockata and is rendering its own randoms, but re-logging sends the correct value. This is supported by the fact that using /blockdata also causes the desync.

Edited August 4, 2017 by Zane49er