TheMasterGabriel

Hi, I'm currently attempting to make a sort of anti-torch (as in it makes the surrounding blocks darker, not lighter), and I've run into a bit of a problem. I can successfully make the surrounding blocks darker, but it induces a bit of a performance penalty. Basically, Minecraft is set to update the light levels of blocks with the time of day (and if other light-emitting blocks are placed), which is something I'm trying to avoid. Right now, I have a system where any light changes made to any of the blocks being affected by my torch are reset, the process goes something like this: Surronding light level changes --> block's light level changes --> torch recognizes light level change --> reset back to original light level I've managed to prevent infinite looping with this system (by checking if the current light level of the block was the previous light level of the block). However, the main problem is that the entire process happens after the initial light level change, meaning that whenever someone places a block or the sky light level changes, I get a huge lag spike (because Minecraft recalculates the light level twice: once for the initial change and once for the reset). That brings me to my question. Does anyone know if forge provides an event or something that I can use to prevent the light changes from happening in the first place? Preventing them entirely will bypass the whole reset system I described above. Perhaps there is an easier way that I am completely missing? Any help or info on the subject would be appreciated. -TMG

Where are you creating an instance of ClientTickHandler? I'm assuming you do it in one of the initialization states (pre-init probably), which means mc.thePlayer will be null. You can fetch the field from EntityPlayerSP in your constructor, but you cannot read it while not in-game.

I don't think you need a custom renderer. All the vanilla projectiles use RenderSnowball, which accepts your item as one of the constructing parameters. It pulls the texture from your item to render, rather than you having to supply it yourself. As for registering an entity registering handler, yes it has changed in 1.10. You no longer supply a raw Render instance. Instead, you need an instance of IRenderFactory. IRenderFactory has a method you must override (createRenderFor) to return your renderer (which should be RenderSnowball, as I said before).

Leashes are rendered by RenderLiving#renderLeash

The raytrace done every tick ignores entities that are not within 3 blocks of the player, as you suggested. Like Draco says, you're going to have to do a manual ray trace. However, entities provide a function for ray traces that takes into account rotation and eye height, so you don't have to do it manually. You can see how vanilla sets mc.objectMouseOver in EntityRenderer#getMouseOver, which uses the said ray trace method. If you just want to extend the range, I believe you only have to change 1 number

onCollideWithPlayer is called by EntityPlayer whenever the player intersects an entity (it's in EntityPlayer, line 619) You don't need to manually check if the entity positions are equal and if the player is a spectator, EntityPlayer already does this (in essence). Try removing the position checks and the spectator check. Also, you never reset the timer (timer=0) when the player collides with your entity for the first time, so your code will only run once.

this.mc.renderViewEntity is used by Minecraft to draw the actual world. You can't use it in the main menu because there is no reference world (which is why you were crashing, I'm assuming you got a NullPointerException). So you're going to have to draw the player model (ModelPlayer) manually, which also means you have to manually bind the player skin as well.

1. Don't compare the raw objects in actionPerformed, compare their IDs (button.id). 2. I believe that entities are spawned solely on the server, which is why your GUI won't show up (GUIs are client-side). You might be able to send a packet to the client, or use a different event that you can use to emulate a player joining the world. Here is a list of pretty much all (there may be a few missing) the forge events. One of them might be fired on both server and client (or just client) that you can use: https://dl.dropboxusercontent.com/s/h777x7ugherqs0w/forgeevents.html

I'm fairly sure there is a EntityStruckByLightningEvent that gets called whenever any entity is about to be hit by lightning. In an event handler, you can check if the entity is an EntityItem and holds the specific item(s) you want, cancel the event (if you want to prevent the items from being set on fire and despawning in the next few ticks), and then do whatever you whatever logic you want. (Checking item and transforming or checking if there are 2 items and transforming, etc)

Potions use nbt to differentiate between types. Unfortunately, I don't think vanilla recipes check an ItemStack's NBT data when checking if a recipe is valid, so you're probably going to have to make your own IRecipe class. (Although it shouldn't be that hard. Pretty much exactly the same as ShapedRecipe, just override ShapedRecipe#checkMatch to check for NBT data as well). Minecraft nicely provides PotionUtils, which has a method called getPotionFromItem that you can use to check a given ItemStack's potion type against the one you desire.

Hi, I'm not sure where I should post this, so I figured the general discussion tab would be the best bet. I recently tried to download the newest version of the forge MDK (1.10.2 - 12.18.1.2074), but when I went to the adfoc.us page, I was instantly redirected to a bunch of different redirects that eventually spat me out on some game website. (A chain of redirects would be the best way to describe it I guess). I'm trying to find the same ad again, but I can't really screenshot the adfoc.us page because of the instant redirect thing. (I know a screenshot is generally requested for this type of thing, so that's why I'm mentioning it). Here are the actual URLs that I was sent to if they help, in the order that I was redirected (I pulled them from my browser history). --EDIT--: Ok so I guess adfocus has detected that I've been trying to find the redirect ad (I guess it prevents users from spam-visiting adfocus links), so now it only shows the official Adfocus ad (the one with the audio that plays in the background). I'll try to find it again when I get normal ads appearing again (and I'll screen record it or something if needed).

In your container constructor, you are linking the slots to the player's inventory (not your tile entity), which is why the same items persist over different blocks.

I believe what you are looking for are item property overrides. Bows use these to change textures depending on how long you hold right click down. You can check out how to do it in ItemBow at the top of the file. You also have to add an override array in your item's json file, but you can look at the vanilla bow json to see how to do that as well.

Check out Item#getItemStackDisplayName. By default it uses the translator but you can override it with your config string (possibly).

I'm not sure why your code doesn't work, but I suspect that there is a Math.min call (or the if statement equivalent) somewhere after where Block#onEntityCollidedWithBlock is called. Not sure tho. However, I know for a fact you can move slower on a block because slimes cause the player to move super slowly when not bouncing. Perhaps you should check out BlockSlime to see how it's done there? I believe the motion changes are done in Block#onEntityWalk there instead of Block#onEntityCollidedWithBlock so that might have something to do with it

Always happy to help. That it a very strange bug, however, I'm not sure why it happens but it does. And it only seems to happen when you right-click a block, so there isn't a flaw in the teleportation code, but probably something MC tries to do after right-clicking a block. Anyway, glad you fixed it. (The mod looks cool btw)

My mistake, pesky lying javadoc. However, the procedure for checking if it's a new day is pretty much exactly the same. Instead of checking if World#getWorldTime() is equal to 0, check if World#getWorldTime() % 24000 is equal to 0. I pulled that straight from CommandTime#execute (which they actually updated it to incorporate a modulo operation in 1.9, Draco), so check that method if you want to know how to calculate other time stuff (like days and the age of the world). Using this method, however, will cause whatever you are planning on doing to fire as soon as the world first loads (which makes sense, because that's how maths work). So assuming you don't want it to fire immediately (which I'm guessing you don't), you should probably do another check to make sure that World#getWorldTime() does not equal 0 (which would be at dawn on the very first day).

World#getTotalWorldTime returns the total time passed in a certain world. Dividing that number by 24000 should return the number of days that have passed in a certain world. If you want the number of whole days, just round the quotient down. Keep in mind, however, that this number gets incremented even if 'gamerule doDaylightCycle' is set to false (which doesn't really make sense if you ask me). -EDIT: Actually thinking about it, don't do that if you only want to do something if a day has just started. If you only want to do something only when a new day starts, just check if World#getWorldTime equals 0.

So I recently encountered a similar problem. It has to do with how you are actually teleporting into your new dimension. In your block class, you check if the player is an instance of EntityPlayerMP and then proceed with teleporting with the methods in PlayerList. For some reason, this causes this problem when you teleport via onBlockActivated. (I suspect it's because you are teleporting the server player and not the client player, so the loaded chunk data gets all mixed up between the client world and the server world, but that's just a speculation). Anyway, try teleporting the player with EntityPlayer#changeDimension instead. If you need a reference, just look at BlockEndPortal. Keep in mind, however, that you still need to wrap the teleport code in a "!world.isRemote" if statement Wow Gabriel, this might be it! How could've I figured this out myself? My only problem is, that changeDimension() doesn't use my teleporter class, but the default one. What should I do about that? And...because for some reason the universe is trying to spite me, I can no longer reproduce the effect I don't know why, but it has just stopped. I'm afraid I'll be useless now . I haven't really worked with tons of dimensions, but you could try to create the portal before teleporting? Hopefully someone with more knowledge knows what's happening. Also, delving a bit deeper, it looks like EntityPlayer#changeDimension uses PlayerList#transferPlayerToDimension for EntityPlayerMP anyway, so I doubt changing it would have had an impact (although it appeared to have when I was having the same problem, so I honestly have no idea what was happening). Sorry I can't help more. I'll keep looking tho Minecraft is so weird :'( I'll appreciate any help given, I'll keep looking too OK! I think I found the problem! In your block activated method, only return true if !world.isRemote and return false otherwise. Try that and see how it works. In case you're wondering what coding im testing this on, here it is: public boolean onBlockActivated(World world, BlockPos pos, IBlockState state, EntityPlayer player, EnumHand hand, ItemStack item, EnumFacing side, float hitX, float hitY, float hitZ) { if(!world.isRemote) { if(player instanceof EntityPlayerMP) { /* do teleport stuff with PlayerList#transferPlayerToDimension */ return true; } } return false; } -EDIT: Also, I noticed that the orientation of your teleporter block thing isn't getting preserved across chunk loads. In your block class you are saving the direction it's facing to metadata, but not reading it back into your block state (you need Block#getStateFromMeta as well as Block#getMetaFromState)

So I recently encountered a similar problem. It has to do with how you are actually teleporting into your new dimension. In your block class, you check if the player is an instance of EntityPlayerMP and then proceed with teleporting with the methods in PlayerList. For some reason, this causes this problem when you teleport via onBlockActivated. (I suspect it's because you are teleporting the server player and not the client player, so the loaded chunk data gets all mixed up between the client world and the server world, but that's just a speculation). Anyway, try teleporting the player with EntityPlayer#changeDimension instead. If you need a reference, just look at BlockEndPortal. Keep in mind, however, that you still need to wrap the teleport code in a "!world.isRemote" if statement Wow Gabriel, this might be it! How could've I figured this out myself? My only problem is, that changeDimension() doesn't use my teleporter class, but the default one. What should I do about that? And...because for some reason the universe is trying to spite me, I can no longer reproduce the effect I don't know why, but it has just stopped. I'm afraid I'll be useless now . I haven't really worked with tons of dimensions, but you could try to create the portal before teleporting? Hopefully someone with more knowledge knows what's happening. Also, delving a bit deeper, it looks like EntityPlayer#changeDimension uses PlayerList#transferPlayerToDimension for EntityPlayerMP anyway, so I doubt changing it would have had an impact (although it appeared to have when I was having the same problem, so I honestly have no idea what was happening). Sorry I can't help more. I'll keep looking tho

So I recently encountered a similar problem. It has to do with how you are actually teleporting into your new dimension. In your block class, you check if the player is an instance of EntityPlayerMP and then proceed with teleporting with the methods in PlayerList. For some reason, this causes this problem when you teleport via onBlockActivated. (I suspect it's because you are teleporting the server player and not the client player, so the loaded chunk data gets all mixed up between the client world and the server world, but that's just a speculation). Anyway, try teleporting the player with EntityPlayer#changeDimension instead. If you need a reference, just look at BlockEndPortal. Keep in mind, however, that you still need to wrap the teleport code in a "!world.isRemote" if statement

You should post your solution so other people can find it. Basically, I actually sat down and thought about what I wanted to do and realized the answer was surprisingly simple. Minecraft already implements a block listener: the one used by entity pathing. I through the WorldEvent.Load event, I add a new instance of IWorldEventListener. IWorldEventListener provides a method called notifyBlockUpdate which gets called every time a block changes (at least for my purposes, only when it matters). Through that method, I get access to a world instance, block pos and block state. From that, I just fetch the world server instance of my dimension and setblock at the right position. I have to manipulate the flags parameter in World#setBlockState, however, to ensure I don't cause infinite notification loops. That will defiantly work for blocks, but it will not work for TileEntities don't know if you wanted that, but just to let you know. I'm not sure what you mean. If I place a crafting table or furnace down in 1 dimension, it gets placed in the other one as well. If you mean the tile entities aren't synced (like sharing a chest inventory), no that doesn't matter.

That's not a valid JSON file. You're missing a comma at the end of the "facing=east" line

It might be worth mentioning that EntityAnimal#getCanSpawnHere (which you invoke through the super call) requires that the light level of the checked spawn block be greater than 8, which in a cave doesn't really happen (unless it chooses a spot next to lava or a torch in a mineshaft), and that the entity must spawn on a grass block (which never happens in a cave).

You should post your solution so other people can find it. Basically, I actually sat down and thought about what I wanted to do and realized the answer was surprisingly simple. Minecraft already implements a block listener: the one used by entity pathing. I through the WorldEvent.Load event, I add a new instance of IWorldEventListener. IWorldEventListener provides a method called notifyBlockUpdate which gets called every time a block changes (at least for my purposes, only when it matters). Through that method, I get access to a world instance, block pos and block state. From that, I just fetch the world server instance of my dimension and setblock at the right position. I have to manipulate the flags parameter in World#setBlockState, however, to ensure I don't cause infinite notification loops.