Everything posted by Mr_Rockers
-
INSTANCE.sendToDimension Bug! [Build 1635 - 1.8.8]
Sure thing! A Git-Hub Repo with the slim-mod can be found here.
-
INSTANCE.sendToDimension Bug! [Build 1635 - 1.8.8]
Hello modder's support. (And Forge Support . Sorry about that) I have come across a bug within Build 1635 - 1.8.8 with the Netty's SimpleNetworkWrapper. When trying to send an IMessage through the Simple Channel, with .sendToDimension passing in a dimensionID as the second parameter (an Integer) then it doesn't work most of the time. It affects the packet's discriminator by setting it to -1, presumably because there's an error or something isn't getting set some place in the code. An example Stack-trace can be found here. It starts at around Line 112. You can recreate this bug by setting up a standard packet system using the SimpleNetworkWrapper like so: MOD Class: /* Let's presume that we have set-up a new message based off of the code example from diesieben07's tutorial-guide. This message will be called 'ExampleMessage'. This is based off the fact that the packet's direction is SERVER -> CLIENT*/ public class ExampleMod { //... public static SimpleNetworkWrapper INSTANCE; @EventHandler public void preInit(FMLPreInitializationEvent event) { INSTANCE = NetworkRegistry.INSTANCE.newSimpleChannel("exampleChannel"); INSTANCE.registerMessage(ExampleMessage.HANDLER.class, ExampleMessage.class, 0, Side.CLIENT); MinecraftForge.EVENT_BUS.register(new PlayerInteractEvents()); //... } //... } .sendToDimension Example Class: (The .sendToDimension snippet can be called anywhere that only the server has access and only when the game is running. i.e. not at the Minecraft-Title Screen. I make sure code is server-only by using a SideOnly.SERVER, using an if statement to check if the world is not remote or calling it from a Server Proxy.) /* Let's also presume we have a block called 'ModBlocks.ExampleBlock' registered... */ public class PlayerInteractEvents { @SubscribeEvent public void onPlayerInteract(PlayerInteractEvent e) { if(e.action != null && !e.world.isRemote) { if(e.action == Action.RIGHT_CLICK_BLOCK) { if(e.world.getBlockState(e.pos).getBlock() == ModBlocks.ExampleBlock) { ModNetworkHandler.sendToDimension(new ExampleMessage(), e.entityPlayer.dimension, e.world); } } } } } If this code is executed correctly (with necessary additions) then it will work, but it is incredibly sketchy. It can produce a bit of lag and 'force-disconnects' the client at what appears to be "random chance". I had taken a look at the .sendToDimension code and it eventually leads to this: @Override public List<NetworkDispatcher> selectNetworks(Object args, ChannelHandlerContext context, FMLProxyPacket packet) { int dimension = (Integer)args; ImmutableList.Builder<NetworkDispatcher> builder = ImmutableList.<NetworkDispatcher>builder(); for (EntityPlayerMP player : (List<EntityPlayerMP>)FMLCommonHandler.instance().getMinecraftServerInstance().getConfigurationManager().playerEntityList) { if (dimension == player.dimension) { NetworkDispatcher dispatcher = player.playerNetServerHandler.netManager.channel().attr(NetworkDispatcher.FML_DISPATCHER).get(); // Null dispatchers may exist for fake players - skip them if (dispatcher != null) builder.add(dispatcher); } } return builder.build(); } I am assuming that there is something fishy going on either in there or the SimpleNetworkWrapper class. Classes to check may be: SimpleNetworkWrapper class at line 220 FMLOutboundHandler class at line 144 For anyone with this error, an easy, fool-proof fix is available: public static void sendToDimension(IMessage message, int dimensionId, World world) { for(EntityPlayer player : world.playerEntities) { if(player instanceof EntityPlayerMP && player.dimension == dimensionId) { INSTANCE.sendTo(message, (EntityPlayerMP) player); } } } NOTE that the world passed in must be from a server, in this case. Do the checks that I mentioned above. This is not the *most* efficient way of doing things either, but it works. It appears that this bug has been in Forge for a while. (The earliest I can date back to is August.) Apparently it had been mentioned in the changelogs that this bug had been fixed a while ago but I still have managed to find it. There is also a chance that there is no bug and I just had bad-luck but I updated my forge to the most recent version and still, to no avail. I had diesieben07 and alot of other people that have been modding for a long time help me out on IRC by looking through my code and they couldn't find the solution either. I have only been modding for a month and Java coding for about half a year, so excuse my lack of understanding if something does come up. I am not new to programming, (I have been doing it for 3 to 5 years) but I am quite new to Java concepts and even modding concepts, if there are any. I am open for constructive criticism either on IRC or on this thread here if you think I am wrong about something or other. I just wanted to post this "bug" for it drove me around the bend for a week. That is all.
-
INSTANCE.sendToDimension(IMessage message, int dimensionID) [WRONG FORUM]
Apologies. This thread has been moved to modder's support.
-
Stopping Splash Particles? [Forge 1.7.10]
Bump. (Not sure if I'm allowed to do this but I'm quite stuck..)
-
Stopping Splash Particles? [Forge 1.7.10]
Hello! I'm creating a custom liquid and everything has *mostly* been setup. I have a custom item for picking it up and custom splash particles that work quite well. However, I have a problem stopping the splash particles that are created by... Well that's the problem. I can't find where the particles are being generated and there doesn't seem to be an event for the creation of particles or effects. I can't stop them or override their creation. Even overriding randomDisplayTick with my particle code doesn't do anything within that regard. I thought about using Minecraft.getMinecraft().effectRenderer.clearEffects(); but that clears all of the effects in all of the fxLayers and this isn't what I want at all. So now, all that happens is that the water splash particles spawn and then my particles spawn (but I don't want the default splash particles because my liquid is red and I don't want any "bubbles".) I'm thinking it's got something to do with Material.water but I can't be certain. Here is my code: package com.lyesdoesmods.fluids; import... public class MortalBloodFluidBlock extends BlockFluidClassic{ @SideOnly(Side.CLIENT) protected IIcon stillIcon; @SideOnly(Side.CLIENT) protected IIcon flowingIcon; public MortalBloodFluidBlock(Fluid fluid, Material material) { super(fluid, material); } @Override public IIcon getIcon(int side, int meta) { return (side == 0 || side == 1)? stillIcon : flowingIcon; } @SideOnly(Side.CLIENT) @Override public void registerBlockIcons(IIconRegister iReg) { stillIcon = iReg.registerIcon(ReferenceVariables.MODID + ":mortalBloodStill"); flowingIcon = iReg.registerIcon(ReferenceVariables.MODID + ":mortalBloodFlowing"); } @Override public boolean canDisplace(IBlockAccess world, int x, int y, int z) { if(world.getBlock(x, y, z).getMaterial().isLiquid()) return false; return super.canDisplace(world, x, y, z); } ArrayList<EntityPlayer> players = new ArrayList<EntityPlayer>(); @Override public void onEntityCollidedWithBlock(World world, int x, int y, int z, Entity entity) { if(entity instanceof EntityPlayer) { if(!players.contains((EntityPlayer)entity)) { if(entity.motionX != 0 || entity.motionZ != 0 || entity.motionY != 0) players.add((EntityPlayer)entity); } } } int tickB; @Override @SideOnly(Side.CLIENT) public void randomDisplayTick(World world, int x, int y, int z, Random rand) { tickB++; if(players != null && tickB > 5) { for(int i = 0; i < players.size(); i++) { double x1 = rand.nextGaussian() * 0.2D + players.get(i).posX; double z1 = rand.nextGaussian() * 0.2D + players.get(i).posZ; Minecraft.getMinecraft().effectRenderer.addEffect(new EntityBloodSplashFX(world, x1, players.get(i).posY - 1, z1)); } players.clear(); tickB = 0; } } @Override public MapColor getMapColor(int p_149728_1_) { return MapColor.redColor; } } Any help is appreciated!
IPS spam blocked by CleanTalk.