Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Posts

  • Joined

  • Last visited

Everything posted by CJCutrone9

  1. What is at line 38 of your HarvestingEvents class? "at net.xxxxxx.events.HarvestingEvents.xxxxPick(HarvestingEvents.java:38)" This is saying that the error is on line 38, we'll need to see that line to know what's going on.
  2. I'm trying to render a sword model above a tile entity (it will be a dynamic item stack in the future, so hard coding the model in is not an option). I've looked at the item frame code, and older mods/tutorials, and I've gotten it to render the sword model, and I can even make out some features of the texture, but, it's an almost entirely black texture. My initial assumption is the light level, but having messed with the code and thousands of different options, I'm not so sure. Here's my code for the current render: @Override public void renderTileEntityAt(TileEntitySwordStand te, double x, double y, double z, float partialTicks, int destroyStage) { GlStateManager.pushMatrix(); GlStateManager.translate(x, y + 2, z); renderItem.renderItem(new ItemStack(Items.diamond_sword), ItemCameraTransforms.TransformType.FIXED); GlStateManager.popMatrix(); } Pretty self explanatory. I've added in this line of code: (modified from the Enderman's eye layer) int i = 61680; int j = i % 65536; int k = i / 65536; OpenGlHelper.setLightmapTextureCoords(OpenGlHelper.lightmapTexUnit, (float)j, (float)k); Which makes the light level work, but now the texture has an opacity of about 50%. (A neat affect I'll keep in mind for the future, but not what I'm looking for). And before anyone says "look at the item frame", I did. I looked at it, copied it, ate it, read it while using the bathroom, dissected it, resurrected it, rebuilt it, and updated my code to match, the result was a darkly rendered item. So, I'm not sure what's going on. If anything else is needed, I'll provide it, nothing to hide with this mess.
  3. Screenshot of what it does when you have all the rotations all the same at point?
  4. Wait, did you not set the rotation point for the models parts all in the same point? Or did you leave them wherever? (the little blue ball in techne is the rotation point)
  5. Okay, update, seems that the cave issue had nothing to do with being able to see the sky, it has to do with how close two chunk loaders are. If a chunk loader is within the player's chunk distance, it all boils down to which chunk loader gets update first (if they aren't in the same chunk of course), the other one is dropped out of the list. Not sure what's causing that either.
  6. Ah, this could be the problem: This is the code from the armor stand. public void setRotationAngles(float p_78087_1_, float p_78087_2_, float p_78087_3_, float p_78087_4_, float p_78087_5_, float p_78087_6_, Entity p_78087_7_) { if (p_78087_7_ instanceof EntityArmorStand) { EntityArmorStand entityarmorstand = (EntityArmorStand)p_78087_7_; this.bipedHead.rotateAngleX = 0.017453292F * entityarmorstand.getHeadRotation().getX(); this.bipedHead.rotateAngleY = 0.017453292F * entityarmorstand.getHeadRotation().getY(); this.bipedHead.rotateAngleZ = 0.017453292F * entityarmorstand.getHeadRotation().getZ(); this.bipedHead.setRotationPoint(0.0F, 1.0F, 0.0F); this.bipedBody.rotateAngleX = 0.017453292F * entityarmorstand.getBodyRotation().getX(); this.bipedBody.rotateAngleY = 0.017453292F * entityarmorstand.getBodyRotation().getY(); this.bipedBody.rotateAngleZ = 0.017453292F * entityarmorstand.getBodyRotation().getZ(); this.bipedLeftArm.rotateAngleX = 0.017453292F * entityarmorstand.getLeftArmRotation().getX(); this.bipedLeftArm.rotateAngleY = 0.017453292F * entityarmorstand.getLeftArmRotation().getY(); this.bipedLeftArm.rotateAngleZ = 0.017453292F * entityarmorstand.getLeftArmRotation().getZ(); this.bipedRightArm.rotateAngleX = 0.017453292F * entityarmorstand.getRightArmRotation().getX(); this.bipedRightArm.rotateAngleY = 0.017453292F * entityarmorstand.getRightArmRotation().getY(); this.bipedRightArm.rotateAngleZ = 0.017453292F * entityarmorstand.getRightArmRotation().getZ(); this.bipedLeftLeg.rotateAngleX = 0.017453292F * entityarmorstand.getLeftLegRotation().getX(); this.bipedLeftLeg.rotateAngleY = 0.017453292F * entityarmorstand.getLeftLegRotation().getY(); this.bipedLeftLeg.rotateAngleZ = 0.017453292F * entityarmorstand.getLeftLegRotation().getZ(); this.bipedLeftLeg.setRotationPoint(1.9F, 11.0F, 0.0F); this.bipedRightLeg.rotateAngleX = 0.017453292F * entityarmorstand.getRightLegRotation().getX(); this.bipedRightLeg.rotateAngleY = 0.017453292F * entityarmorstand.getRightLegRotation().getY(); this.bipedRightLeg.rotateAngleZ = 0.017453292F * entityarmorstand.getRightLegRotation().getZ(); this.bipedRightLeg.setRotationPoint(-1.9F, 11.0F, 0.0F); copyModelAngles(this.bipedHead, this.bipedHeadwear); } } You'll notice it doesn't call super.setRotationAngles (like you did), the reason for that is because super.setRotationAngles does nothing, it's an empty method. So in your implementation of it, you need to do what the armor stand did, rotation the model parts of your model according to the entity that wears it.
  7. Okay, so I changed the teleport code from: entityPlayer.setPosition(portals.get(i).posX, portals.get(i).posY +.5F, portals.get(i).posZ); to: entityPlayer.setPositionAndUpdate(portals.get(i).posX, portals.get(i).posY +.5F, portals.get(i).posZ); And that fixed the problems with it not rendering, but now I have 2 new problems ( I changed the topic title accordingly). First it seems like things get reeeaallly laggy when I place a chunk loader, I expect some lag of course, but loading new chunks by moving around and exploring drops FPS to like 10 or so. Should I move this code: if(!worldObj.isRemote){ if(ticket == null){ ticket = ForgeChunkManager.requestTicket(ModLights.instance, worldObj, Type.NORMAL); System.out.println("creating ticket"); } ForgeChunkManager.forceChunk(ticket, new ChunkCoordIntPair((int)posX/16, (int)posZ/16)); } out of the onUpdate method to another one, and if so, what? Second, it seems like saving and exiting the world, and then coming back in resets the chunk loader and I have to travel to that chunk to make it reload.
  8. It looks like the problem is with this line: this.modelPlayerBackpack.render(Minecraft.getMinecraft().thePlayer, 0.0F, 0.0F, 0.0F, 0.0F, 0.0F, 0.0625F); You aren't rotating the model at all (the 0's), you need to make one of those (not sure which one, experimenting should do the trick though) the player's Y rotation. I'm going to assume it's the second one though.
  9. What exactly is it doing? Is it not on the player's back? Or does it stay where you put it on, or does it not rotate with the player?
  10. Title pretty much sums up the issue I'm having. I've gotten the chunks to stay loaded (I know it's loaded because I set up a furnace to smelt a stack, got well out of chunk load range, easily +2000 blocks away, and when I tp'd back the stack of cobble was nearly smelted. That and I put a debug System.out.println to print "update" if the entity was updating, which can only happen if it is loaded.) My problem comes in when I teleport to this loaded chunk. The chunks around it don't appear to render until I walk around on them and break/place blocks. I don't fall through the world, and I can see the outline of the block I'm pointing at, but it doesn't look like it would had I not kept the chunk loaded and just tp'd out there. The second problem I'm encountering is that after I do this a few times, it seems that teleporting causes the chunk loaded in the chunk to "loose" it's ability to keep the chunk loaded. Here's the update method where the chunk loading is kept: public void onUpdate(){ this.worldObj.theProfiler.startSection("entityBaseTick"); this.ticksExisted++; if(!worldObj.isRemote){ Block block = worldObj.getBlockState(this.getPosition().subtract(new Vec3i(0, 1, 0))).getBlock(); if(!(block instanceof PortalSpawner)){ this.setDead(); }else{ PortalSpawner ps = ((PortalSpawner)block); ps.portal = this; } if(!worldObj.isRemote){ if(ticket == null){ ticket = ForgeChunkManager.requestTicket(ModLights.instance, worldObj, Type.NORMAL); System.out.println("creating ticket"); } ForgeChunkManager.forceChunk(ticket, new ChunkCoordIntPair((int)posX/16, (int)posZ/16)); } } this.worldObj.theProfiler.endSection(); } Yes, this is the same entity I was having trouble with earlier. Thanks for the help guys! -CJ
  11. With this nifty thing right here, found this one in TConstruct's source: Loader.isModLoaded("NAME_OF_MOD_HERE") The NAME_OF_MOD_HERE string needs to be the same thing that the mod uses for there Modid. Hope this helps!
  12. Okay, so I got rid of the color field and that fixed everything. And yes, the 16 colors should be enough, I didn't want that many different portals, but I wanted to provide a few different colors, and you can cycle through portals, so let's say you have 4 red portals, then you can teleport from portal to portal to portal. I can always change it from a byte to an int if I need to. Thanks a bunch Diesie!
  13. Hey all, I've gotten myself into a little problem I have absolutely no clue how to fix. Let's go down the issue shall we? So I wanted to create a "portal" entity that could teleport the player wherever there was another portal. I got that to work. Good. Then I wanted the player to be able to change the color of the portal to allow for multiple portals, that works, until the player logs out. Then the color would reset. So I did some looking up and found two ways to handle this issue, I could either use packets (which I found wouldn't be worth it due to the little bit I wanted to do) or I could use a DataWatcher like all the other entities seemed to use (thinking sheep). So I gave it a shot, and it seemed to work, portal teleportation stayed working, and the color still changed, but when I logged out and back in, it reset. After doing some digging I looked at the code and did some debugging to find that it seems that the DataWatcher doesn't seem to save everything properly, the data object that I was writing kept getting overridden. I'm not entirely sure I understand why either, I tried very many things, and then wound up copying the code from the sheep to get their color of wool, only to not have that work either. So here is the entire code for the entity, thanks for the help guys! tl;dr I have an int that I am using to store the color of an entity, it doesn't save. package id.cutrone.lights.entities; import id.cutrone.lights.blocks.PortalSpawner; import java.util.ArrayList; import java.util.List; import net.minecraft.block.Block; import net.minecraft.entity.Entity; import net.minecraft.entity.player.EntityPlayer; import net.minecraft.nbt.NBTTagCompound; import net.minecraft.util.DamageSource; import net.minecraft.util.Vec3i; import net.minecraft.world.World; import com.google.common.base.Predicate; public class EntityPortal extends Entity{ public List<EntityPortal> portals; public int color = 0; public EntityPortal(World worldIn){ super(worldIn); this.preventEntitySpawning = true; this.setSize(1F, 1F); } public EntityPortal(World worldIn, double p_i1713_2_, double p_i1713_4_, double p_i1713_6_) { this(worldIn); this.setPosition(p_i1713_2_ + 0.5F, p_i1713_4_ + 1F, p_i1713_6_ + 0.5F); this.motionX = 0.0D; this.motionY = 0.0D; this.motionZ = 0.0D; this.prevPosX = p_i1713_2_; this.prevPosY = p_i1713_4_; this.prevPosZ = p_i1713_6_; } public void interact(EntityPlayer entityPlayer) { setEntities(); int lastInChain = 0; int thisInChain = 0; int firstInChain = 0; for(int i = 0; i < portals.size(); i++){ if(portals.get(i) == this){ thisInChain = i; } } for(int i = 0; i < portals.size(); i++){ if(portals.get(i).color == this.color){ firstInChain = i; break; } } for(int i = 0; i < portals.size(); i++){ if(portals.get(i).color == this.color ){ lastInChain = i; } } if(thisInChain >= lastInChain && thisInChain != firstInChain){ entityPlayer.setPosition(portals.get(firstInChain).posX, portals.get(firstInChain).posY, portals.get(firstInChain).posZ); return; } for(int i = 0; i < portals.size(); i++){ if(i > thisInChain && portals.get(i).color == this.color){ entityPlayer.setPosition(portals.get(i).posX, portals.get(i).posY, portals.get(i).posZ); break; } } } /** * Called when the entity is attacked. */ public boolean attackEntityFrom(DamageSource source, float amount) { return true; } /** * Returns true if other Entities should be prevented from moving through this Entity. */ public boolean canBeCollidedWith(){ return true; } /** * Will get destroyed next tick. */ public void setDead(){ super.setDead(); } /** * Called to update the entity's position/logic. */ public void onUpdate(){ this.worldObj.theProfiler.startSection("entityBaseTick"); this.ticksExisted++; if(!worldObj.isRemote){ Block block = worldObj.getBlockState(this.getPosition().subtract(new Vec3i(0, 1, 0))).getBlock(); if(!(block instanceof PortalSpawner)){ this.setDead(); }else{ PortalSpawner ps = ((PortalSpawner)block); ps.portal = this; } } this.worldObj.theProfiler.endSection(); } /** * Returns true if this cart can be ridden by an Entity. * @return True if this cart can be ridden. */ public boolean canBeRidden(){ return false; } @Override protected void entityInit() { this.dataWatcher.addObject(16, new Byte((byte)0)); setEntities(); } @SuppressWarnings("unchecked") public void setEntities(){ portals = new ArrayList<EntityPortal>(); portals = worldObj.getEntities(EntityPortal.class, new Predicate(){ public boolean apply(Object obj){ return (Entity)obj instanceof EntityPortal; }}); } @Override protected void readEntityFromNBT(NBTTagCompound tagCompound) { color = dataWatcher.getWatchableObjectByte(16); this.setColor(tagCompound.getByte("Color")); } @Override protected void writeEntityToNBT(NBTTagCompound tagCompound) { tagCompound.setByte("Color", (byte)this.getColor()); } public int getColor(){ return this.dataWatcher.getWatchableObjectByte(16) & 15; } public void setColor(int color){ this.color = color; byte b0 = this.dataWatcher.getWatchableObjectByte(16); this.dataWatcher.updateObject(16, Byte.valueOf((byte)(b0 & 240 | color & 15))); } }
  14. Yeah, that video I made isn't perfect, I've been meaning to update it, because there are some flaws with it, like using switch statements instead of if statements, etc. So, your best bet would be TGG's blog for now.
  15. Yeah, I thought that might be what I needed done, but that produces another problem, if one side of a block stops rendering, and I slowly turn to look at it, only the underlayer renders..
  16. I am not sure what you want. Are you saying you want to render the item in a player's inventory out in front of them? Or are you basically asking how to render an item?
  17. It... Works... Kind of.... It is rendering the layers funny. The two textures are also fighting for control over who gets top layer. Did I do something wrong? @Override public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) { DummyBlockScrolls dummy = (DummyBlockScrolls)block; renderer.renderStandardBlockWithColorMultiplier(block, x, y, z, 1F, 1F, 1F); if( block instanceof DummyBlockScrolls ) { Tessellator.instance.setBrightness(240); Tessellator.instance.setColorOpaque(255, 255, 255); renderer.renderFaceYNeg(block, x, y, z, dummy.getUnderlayer()); renderer.renderFaceYPos(block, x, y, z, dummy.getUnderlayer()); renderer.renderFaceZNeg(block, x, y, z, dummy.getUnderlayer()); renderer.renderFaceZPos(block, x, y, z, dummy.getUnderlayer()); renderer.renderFaceXNeg(block, x, y, z, dummy.getUnderlayer()); renderer.renderFaceXPos(block, x, y, z, dummy.getUnderlayer()); Tessellator.instance.setBrightness(block.getMixedBrightnessForBlock(world, x, y, z)); } return true; }
  18. Your setting textureName to null.. so it is returning null. Give it a location here: That null, needs to be a texture name.
  19. Okay, so I found a slightly cheaty solution: @Override public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) { Tessellator.instance.setColorOpaque_F(1F,1F,1F); Tessellator.instance.addTranslation(0F, .01F, 0F); renderer.renderFaceYPos(block, x,y,z, block.getIcon(world, x,y,z, 1)); Tessellator.instance.addTranslation(0F, -.01F, 0F); renderer.renderFaceYPos(block, x, y, z, DummyBlockScrolls.getUnderlayer()); return true; } Essentially, you put one texture slightly over another. Works decent. But now I have another question (still related to this). I want to make the underlayer glow, but not the over layer. How would I stop the over layer from glowing? I know I can make them both glow by using: Tessellator.instance.setBrightness(brightness); If I set it at zero both texture become black, if I set it to say 200, both have the appearance of glowing. How would I get the top layer to be normal and the bottom layer to have that code added to it? I thought maybe a switch statement might work, but I couldn't figure out what to switch between...
  20. Cool! Thanks! EDIT: Okay, so I did some looking around, and figured I could just render the two textures, with one on top of the other. Only problem is, sometimes texture A like to get rendered before texture B. Is there a way to make sure that texture A get rendered before texture B and not the other way around? Here is the code I am using to render the block right now. @Override public boolean renderWorldBlock(IBlockAccess world, int x, int y, int z, Block block, int modelId, RenderBlocks renderer) { renderer.renderFaceYPos(block, x,y,z, block.getIcon(1, world.getBlockMetadata(x, y, z))); renderer.renderFaceYPos(block, x,y,z, block.getIcon(world, x,y,z, 1)); return true; } I am using an ISimpleBlockRenderingHandler, so this method is getting called. I just need it (as mentioned before) to render some textures before others. Sometimes it does, other times it doesn't. Thanks!
  21. Hey everyone, I've been looking around, and I couldn't find a tutorial for rendering the overlay on a block that worked for 1.7.2. I thought that maybe I could look in Mojang's code for this, but I couldn't find the specialRenderer for the grass block (which is what I assume they are using for rendering the side of the grass block). If anyone could point me to either of the two (I'd prefer the grass block so I could figure it out myself) that would be great. Thanks!
  22. I see this as one of two problems, either a, you are registering your renderer to early (do it in the load with your blocks in pre to see if that helps), or it could be this: renderTileEntity(te, null, 0, 0, 0, meta, Block.getBlockFromItem(stack.getItem()), type); First, you are returning the World as a null. Probably not the best. But where I see the immediate problem is the getBlockFromItem, in the (), just put the Item for example YourMainModClass.ItemYouWant.
  23. Okay this is the crux of your confusion -- of course you can get variables from other objects! Once you know the tile entity instance you can just use it's variables (assuming they're public variables). That's the point of object-oriented programming. The trick then is simply finding the tile entity instance to refer to. Like CoolAlias advises, instead of searching for the tile entities every tick, for performance reasons it is better to record them when they are added (and also update when blocks are deleted!). So you'll just do a search when the block is added and update the entity with variables of type TileEntityCog for cogToNorth, cogToSouth, etc. and also gearboxToNorth, etc. Then, in the code where you update the direction of the rotation you would simply check each direction and if it isn't null then pick up the rotation accordingly. For example: In that example, you can see how you can refer to the clockwise variable in the neighboring tile entities and the result in this case is that the last non-null neighbor would control the rotation, gearboxes would override regular cogs, and it would be set to be opposite that neighbor. So hopefully you're getting the idea -- make sure the variables in your entity are public so they can be queried from other classes. So what I think (double check with more experienced modders) you could do for your mod: 1) create block for cogs that extends ITileEntityProvider 2) create tile entity associated with the cogs 3) in the tile entity create public variables for boolean clockwise, boolean active, int rotatedByDegrees, tileEntityCog cogToNorth, etc. (note that tile entities should automatically get x, y, z variables, world object variable, etc) 4) in the tile entity's constructor (more experienced programmers can advise if this is the right place) you make sure to add the tile entity to your mod's array of cogs, also search surroundings (you can just have each tile entity “look around itself” for other tile entities using TileEntityCog tile = (TileEntityCog) world.getBlockTileEntity(i, j, k); and put in the position you want to check) for neighbors and set the cogToNorth, etc. to the found instances. 5) in the render method you would update either the model or the texture depending on how you're visually planning to implement the cog according to the entity's active, clockwise and the rotatedByDegrees variables. 6) make sure you put in code in the block destroy event to update neighboring cogs such that they no longer consider the destroyed block a neighbor. 7) add in similar stuff for the gearboxes don't forget to registers all your stuff, update lang file, texture assets, etc. (I'm using 1.7.2, so maybe different if you're on 1.6.4) Anyway, hopefully you're getting an idea of a proposed approach: - extend your blocks with tile entities to keep track of variables - implement variables in the tile entity that track its state and also instances of any neighbors - refer to variables in those instances to figure out how neighbors should affect each instance - render the effect of cog turning Thank you so much! The bolded words where the only things I didn't have, there it goes. Now to see if I can implement it. I'll post an update when I finish the code for these. Thanks man!
  24. Hmm.. that sounds good. Thanks! Perfect, this makes the requirements very clear. Okay, so first of all the cogs (and gearbox) should be tile entities, not standard blocks (although I guess you could use standard block with metadata if you really wanted). With tile entities, you can make some proper variables to hold information about the state of the instance. For example, you could have variables like a boolean clockwise variable to indicate direction of rotation, a boolean driven variable to indicate whether it is being driven by a gearbox or chain of cogs, and an int or float rotated_by variable to keep track of the amount of rotation. Then regularly (perhaps every tick, although if perf is concern maybe less frequently) you would scan the neighboring locations and implement the logic you described -- if there was a gearbox attached you'd pick up the boolean clockwise variable and set the opposite (since every cog would go in opposite rotation), and if there was no gearbox you'd look for other cogs starting in the order you specified "left to right". Hopefully you get the idea, and after you code it up please share and we can further give pointers if you need them. I think I do, in short you are saying I should tell it to count how many CW there are and then determine left or right? So, I look to see if there is a gearbox, if not, I would look to the left and see if there is a block, if there is, then I would look one more to left to see if there is, and so on, and so forth. If that is what you are saying, it actually doesn't work that well, after you place down a certain number of wheels, they start doing the disco... Is there a way for me to get a variable from another block's TileEntity?
  25. To be added in the build.gradle file: dependencies { compile fileTree(dir:'somedirectory', include: 'somedependency.jar') } And I assume the directory would be where it is located on my computer? Ah, I see. -Well, the way I want it to work, is that the normal cog won't just turn, you'll have to have it turned by another cog, I am going to eventually have a block that will work like a gear box, and will turn the cogs that are touching it. -If there is a conflict, I'd prefer it to work from "left to right" (west to east, and south to north) giving dominate control to the one on the left, and the ones on the right all changing and turning the direction need be, so if there is a conflict, the one on the left wins, and it sets the one on the right to the correct direction. - A Cog really should be turning on its own, but if someone does place two gearboxes next to each other and has the gears turn in the same direction, I guess I could have there be a mini explosion that just took out the cogs. - I intend to have the gear boxes always turn the cog in a given direction, but that shouldn't be too hard to accomplish. Correct me if I am wrong here, but the way I think this would need to work would be me setting a number in the instance of the block, that would be updateable? Or is there some obviously clear and simple way that I am just not seeing?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.